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.
- 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.