A mint bound to a rule set enforces it twice: when tokens are issued and when they move. Both checks run inside the transaction, so tokens never reach a wallet that does not hold a live pass.
- TransferA holder sends a bound mint to another wallet's token account.
- Writ hook reads
- Config: not paused
- Mint binding and its rule set
- Receiver's credential: current epoch
- Verifier: active, same generation
- Receiver's rule pass: live
- SettlesAny failing read reverts the whole transaction; nothing moves.
On every transfer#
Token-2022 calls Writ's transfer hook for each transfer of a bound mint. The hook reads:
- Writ's config, which must not be paused,
- the mint's binding and the rule set it names,
- the receiving wallet's credential, for its current epoch,
- that credential's verifier, for its activity and generation,
- the receiving wallet's rule pass for the rule set.
If any of these fails, the whole transfer reverts. A mint bound with senders need a pass too reads the same three accounts for the sending wallet as well.
Wallets and venues that use Token-2022's standard transfer resolve these accounts on their own: the binding stores them as the mint's extra account list.
On every issuance#
Token-2022's mint instruction does not call the transfer hook, so binding takes the mint authority away from the issuer. From then on, tokens can only be issued through Writ's issue to an eligible holder instruction, which checks the recipient's pass in the same way before it mints.
What a bindable mint looks like#
Binding accepts a Token-2022 mint that:
- has a supply of zero,
- has exactly one extension, TransferHook, pointing at Writ, with no authority left to change it,
- has the issuer's wallet as its mint authority.
The app creates such a mint for you in the Issuer section. Binding writes the binding account and the hook's extra account list, and moves the mint authority to the binding.
Token accounts#
The sending and the receiving token account both need an owner that cannot change. Standard Token-2022 associated token accounts already have it, and the app opens one for a recipient who has none. Without it, an account could change hands without a transfer, and the hook would never see it.
Revocation at the hook#
Because the hook reads the credential and the verifier on every transfer, a revocation or a verifier deactivation takes effect at the next transfer. Balances already held stay where they are; moving them needs a live pass on the receiving side.