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.