Deposit and redeem

Deposit

deposit checks, in order:

1. The card's collection is in the vault's accepted list.
2. The attestation has not expired.
3. The card is a Core asset, its owner is the depositor, and its update authority is that collection.
4. The attestation matches this deposit exactly. See Attestation.

Then:

1. A Core transfer moves the card to the vault PDA. Core itself refuses a frozen card.
2. A copy record is written at the end of the class's queue, with the card, its record hash, its grader cert number, the depositor and the time.
3. A held marker is created for the card at ["held", asset], so one card can never back two copies.
4. The class counts one more card held.
5. The vault mints 1,000 card tokens to the depositor's token account.
6. The class's backing flag is refreshed. A deposit fails if the class would still be short of backing after it.

Donating a card

A deposit with donate set adds a card of backing and mints nothing. It is how a class that is short of backing is made whole again.

Redeem

redeem takes the copy at the head of the class's queue, which must be held. It then:

1. Burns 1,000 card tokens from the redeemer.
2. Transfers the card to the redeemer, signed by the vault PDA.
3. Marks the copy redeemed, closes its held marker and moves the head to the next copy.
4. Refreshes the class's backing flag.

Redemption is first in, first out. There is no way to choose a copy. A redeemed card can be deposited again later, under a new place in the queue.

Keeping the queue moving

redeem only takes the head copy, so three permissionless instructions keep the queue from getting stuck.

requeue fails when nothing is frozen. A card's own unfrozen permanent freeze delegate overrides a frozen collection, as Core lets it.

Copy statuses

The rest of this path