What actually moves when you sell a character
“The buyer gets the character” is the sentence every character sale is built on, and it is the sentence nobody can cash. A character is not a file. It is a specification, a reference set, source images, a pile of works, a history, and a name. When a deal goes wrong, it goes wrong in the gap between what the buyer thought that sentence meant and what actually arrived. This post walks through one assignment on the platform, file by file, so the sentence has a definition.
Before signature: a draft that names the object
A buyer opens a deal from the character's public page. The room contains a draft assignment agreement from the platform's template. Five fields are filled by the platform and cannot be typed over by either side: the registry number, the specification fingerprint, both platform handles, and the count of registered works. Everything commercial — price, payment method, acceptance window, governing law, optional clauses — is negotiable, and any clause can be rewritten. The other side's first view is not the contract but the redline against the standard template: every value entered, every clause changed.
One detail matters more than it looks. The works count is not frozen when the room opens. If the seller registers two more tracks while the draft is being negotiated, the contract updates to say so, the revision number ticks up, and any signature already given is cleared. The contract always describes the character as it stands at the moment of signing — never as it stood a week earlier.
At signature: two things freeze
Each party signs the SHA-256 of the text on screen. If the text changed in between, the signature is refused. When the second signature lands, the platform takes a manifest of the seller's character pack — every relative path and every file's fingerprint — and locks the pack. From that moment until the transfer completes or the deal is cancelled, the seller cannot edit the specification, delete a work, remove an image, add a channel or re-list the character. Those requests are refused by the server with a lock error, not discouraged by a warning. The seller sees the lock as a banner on the character page.
The manifest deliberately ignores two files: the pack's own metadata and the reference profile that the nightly anchoring job rewrites. Without that exclusion, every anchoring run would look like tampering and every transfer after midnight would be refused.
Payment: between the parties, recorded on both sides
The platform never holds funds. The buyer pays the seller by whatever method the contract names, then records “payment sent” in the room with an optional reference. The seller sees that report, checks their own account, and records “received”. That second click is the trigger; nothing moves before it, and the seller cannot be rushed into it by the platform.
Transfer: a move, not a copy
On the seller's confirmation the platform executes the assignment. This is what moves, in the order it moves:
- The whole pack directory — specification in every version, reference set, source images, per-platform delivery packs, every registered work and every evidence record — is moved from the seller's account to the buyer's. Moved on the same volume, which on the file system is a rename: near-atomic, and reversible by the same operation if any later step fails.
- Works registered at account level and bound only to this character move with it — file, authorship record and binding, with a transfer line added to the work's own history. The authorship record is not rewritten: it still names the original registrant, which is the point. A work bound to two characters stays where it is; it is not part of any one character's “whole pack”, and the public page says so before anyone opens a deal.
- The listing is cleared. The buyer decides whether and how to list it again. Nothing goes on the market in the buyer's name without the buyer choosing to.
- The registry number stays the same, and a transfer event — date, from, to, contract fingerprint — is appended to the character's record. The public page shows the transfer in the record history by platform handle. The number cannot be split off, sold separately or moved to a different character; it travels with the pack or not at all.
- The seller keeps a read-only deal record with no files in it: what was sold, to whom, when, under which contract fingerprint.
Then the platform compares three manifests: the one frozen at signature, the one taken just before the move, and the one taken just after it in the buyer's account. If the first two differ, something changed under lock and the transfer is refused before it starts. If the last two differ, something was lost in the move and it is rolled back. “Complete delivery” is the result of that comparison, not a promise in a message.
After transfer: the acceptance window
The buyer now has the pack in their own account and a window — 72 hours by default, negotiable in the contract — to check it. The machine comparison is shown to both sides: file count, and whether every fingerprint matched. Silence at the end of the window counts as acceptance. A dispute inside it freezes the deal for review, and a review can reverse the transfer: the pack goes back the way it came, and the reversal is appended to the record rather than erased from it.
What is anchored
Two fingerprints go into that night's on-chain batch: the signed contract text and the transfer event. Neither the contract nor the files are published. A buyer holding the deal record can, in five years, recompute both hashes and read them off the chain without asking the platform anything.
And the exclusive licence?
An exclusive licence moves less and marks more. The licensee receives a copy of the pack — specification, references, works — with no registry number of its own; the original stays with the licensor and is marked as exclusively licensed for the term, so it cannot be sold or licensed again while that lasts. The licence event, and later its expiry, are appended to the same record. When the term ends the copy is removed from the licensee's account and the mark is lifted.
None of this is complicated. It is just specified — which is the one thing “the buyer gets the character” never was.
賣掉一隻角色的時候，實際搬動的是什麼
「買家拿到這隻角色」是每一筆角色交易賴以成立的一句話，也是沒有人兌得了現的一句話。角色不是一個檔案，它是一份規格、一組參考圖、來源圖片、一堆作品、一段歷史和一個名字。交易出問題時，問題出在買家以為那句話的意思，和實際送到的東西之間的落差。這篇文章逐檔走過平台上的一筆讓與，讓那句話有一個定義。
簽署前：一份指名標的的草約
買家從角色的公開頁開一筆交易。交易室裡是依平台範本產生的讓與契約草約。五個欄位由平台填入、雙方都不能改：登錄編號、規格指紋、雙方的平台帳號、已登錄作品件數。所有商業條件，價格、付款方式、驗收期、準據法、選用條款，都可以談，任何條款都能改寫。對方第一眼看到的不是契約，而是對照標準範本的紅線：每一個填入的值、每一條改動的條款。
有個細節比看起來重要。作品件數在交易室開啟時不會凍結。草約協商期間賣家又登錄了兩首曲子，契約會更新成新的數字、修訂號往上跳、已經簽的簽名一律清掉。契約永遠描述簽署當下的角色現況，不是一週前的。
簽署時：兩樣東西凍結
雙方對畫面上文本的 SHA-256 簽名。文本中間改過，簽名就被拒。第二個簽名落下時，平台對賣家的角色包取一份清單，每一個相對路徑和每一個檔案的指紋，然後鎖定角色包。從那一刻到移轉完成或交易取消為止，賣家不能改規格、刪作品、移除圖片、新增管道或重新刊登。這些請求由伺服器以「已鎖定」拒絕，不是用警告勸阻。賣家在角色頁會看到一條鎖定橫幅。
清單刻意略過兩個檔案：角色包自己的中繼資料，以及夜間上鏈作業會改寫的參考輪廓。少了這個排除，每一次上鏈都會像是竄改，午夜之後的每一筆移轉都會被拒。
付款：雙方之間直接進行，兩邊都留紀錄
平台從不代管資金。買家用契約寫的方式付款給賣家，然後在交易室記錄「已付款」，可以附參考號。賣家看到通知、查自己的帳戶、記錄「已收到」。那第二下點擊是觸發點：在它之前什麼都不會動，平台也不能替賣家按下去。
移轉：搬走，不是複製
賣家確認後，平台執行讓與。以下是搬動的東西，照搬動的順序：
- 整個角色包目錄，每一版規格、參考圖集、來源圖片、各平台交付包、每一件登錄作品和每一筆佐證紀錄，從賣家帳號搬到買家帳號。在同一個磁碟卷上搬，在檔案系統裡就是一次重新命名：近乎原子，而且後面任何一步失敗，都能用同一個操作復原。
- 登記在帳號層、只綁這隻角色的作品跟著角色走：檔案、著作紀錄、綁定一起搬，作品自己的履歷多一行讓與。著作紀錄不改寫，上面仍是原登記人的名字——這正是它的價值。綁了兩隻角色的作品留在原地：它不屬於任何一隻角色的「整包」，公開頁在開交易之前就標明了。
- 刊登被清除。要不要、怎麼重新刊登，由買家決定。沒有任何東西會在買家沒選擇的情況下，以買家名義出現在市集。
- 登錄編號不變，一筆移轉事件（日期、從誰、到誰、契約指紋）附加到角色的紀錄上。公開頁在紀錄履歷裡以平台帳號顯示這次移轉。編號不能被拆出來單獨賣，也不能移到另一隻角色；它跟著角色包走，否則哪裡都不去。
- 賣家保留一份唯讀的交易紀錄，裡面沒有檔案：賣了什麼、給誰、什麼時候、依哪枚契約指紋。
接著平台比對三份清單：簽署時凍結的那份、搬移前一刻取的那份、搬移後在買家帳號取的那份。前兩份不同，代表鎖定期間有東西被改了，移轉在開始前就被拒；後兩份不同，代表搬移中遺失了東西，就會回滾。「完整交付」是那次比對的結果，不是一則訊息裡的承諾。
移轉後：驗收期
買家現在在自己的帳號裡有了角色包，以及一段檢查期，預設 72 小時，契約可以談。機器比對結果對雙方顯示：檔案數，以及每一枚指紋是否相符。期滿沒有意見就視為驗收。期內提出爭議，交易凍結、交付審查；審查可以把移轉復原，角色包原路搬回去，復原也會附加到紀錄裡，而不是從紀錄裡抹掉。
什麼被上鏈
當晚的上鏈批次會納入兩枚指紋：簽署的契約文本和移轉事件。契約和檔案都不公開。手上有交易紀錄的買家，五年後可以重算這兩個雜湊、直接從鏈上讀回來，不必問平台任何事。
那專屬授權呢？
專屬授權搬得少、標得多。被授權人拿到角色包的一份副本，規格、參考圖、作品，沒有自己的登錄編號；原件留在授權人手上，在授權期間標記為已專屬授權，期間內不能再賣、也不能再授權。授權事件和之後的期滿都附加到同一份紀錄。期滿時副本從被授權人帳號移除、標記解除。
這些都不複雜，只是被明確規定了；而這正是「買家拿到這隻角色」這句話從來沒有的東西。