Expiration, Invalidation, & Clawback
When a token-manager is instantiated, one or more invalidators can be assigned as the only public keys that can perform an invalidation. In the case of time invalidation or usage-based invalidation, a permissionless call can invalidate the token. Once this happens, any necessary payments are settled, and its lifecycle is complete.
The protocol has 3 built in invalidation mechanisms out of the box
- Time
- Issuer can set a duration, and whether that duration begins at issuance or at the time of claiming
- If current time is greater than expiration, it can be invalidated
- Usage
- Issuer can set a max number of usages; the holder can sign a transaction declaring a usage
- If the number of usages exceeds max usages, it can be invalidated
- Manual revocation via revoke authority
- Issuer can specify a revoke authority
- At any time, this authority can invalidate the certificate
The protocol also supports 3 different invalidation types which specify what happens following an invalidation
- Return
- Upon invalidation, the token will be returned to the issuer
- Invalidate
- Upon invalidation, the token will remain marked as invalid and can no longer be used
- Release
- Upon invalidation the token manager will be deleted and thus the tokens are released
Cardinal will manage a crank that will run constantly to ensure that time-based tokens are invalidated in a timely manner. The crank will collect rewards from invalidation by closing the PDAs and other dead accounts associated with the tokens' lifecycles.