New programmable token design proves Cardano's freeze-and-seize capabilities

While the creativity of innovators is the only limitation to Cardano’s reach, its foundation in peer-reviewed research and scalable architecture makes it a leading blockchain for regulatory compliance, enhanced data protection, and privacy-focused applications.

‘Freeze-and-seize’ is a critical feature for building applications designed to meet regulatory and business requirements, particularly in finance and other highly regulated industries. This mechanism, which denotes an action where an institution has the authority to safeguard assets against malicious actors, is not new to Cardano, nor the blockchain ecosystem as a whole. However, to demonstrate that Cardano supports programmable tokens with full control over issuance, transfers, and payments, Input | Output and Philip DiSarro from Anastasia Labs have built a proof-of-concept (POC) for a regulated stablecoin with freeze-and-seize capabilities, known as Wyoming Stable Token (WST).

The full source code is available on Github. Alongside the freeze-and-seize functionality, the POC also implements CIP-0143, a standard that allows Cardano wallets and applications to automatically recognize programmable tokens.

CIP-0143: enhancing token programmability

The CIP defines a registry for token policies and an address format for storing CIP-0143-compliant tokens. Policies like WST can be added to the registry by entering their script hashes in an on-chain data structure. When a transaction involving WST or other tokens needs to be validated, the logic simply forwards all checks to the token-specific script.

Key features of CIP-0143

Flexibility

The CIP’s design is flexible and can be used to implement NFTs with royalty payments, or tokenized real-world assets that require off-chain checks before transferring ownership.

No hard fork needed

Since CIP-0143 is a collection of Plutus scripts with defined conventions, its implementation does not require a hard fork or changes to ada or existing native token policies.

Unified address system

One of the key conventions defined by CIP-0143 is its address format. Instead of requiring a separate address for each token, a single programmable token address is assigned to every regular wallet address, allowing it to receive any CIP-0143-based token. As a result, there is no need for a distinct WST address. All tokens following this standard can be managed under one address.

This programmable token address is derived directly from the regular wallet address by using its payment credential as the stake credential. This streamlined approach simplifies CIP-0143 integration into existing wallets, making adoption seamless.

WST: a programmable, compliant token

WST is an example of a CIP-0143-compliant token. Its main feature is the transfer policy, which checks every transaction that involves WST tokens to ensure that the sender’s address is not frozen. The transfer policy also allows the issuer of WST (the minting authority) to seize WST tokens from any address that holds them.

To support this, an on-chain linked list of frozen addresses is maintained using a single unspent transaction output (UTXO) for each frozen account. The list is lexicographically ordered by payment credential, and each UTXO includes both the current and the next entry in the list. Proving the sender’s unfrozen status always takes the same amount of time, regardless of the size of the freeze list.

Once the infrastructure for registering and checking policies in CIP-0143 was in place, building WST was straightforward. We could focus entirely on the business logic of checking the list of frozen accounts, and didn’t have to worry about bookkeeping and management functions to ensure that the policy will actually be called at the right time. The CIP took care of all this, and all tokens built on this CIP can reuse the logic.

Best practices and design patterns

Beyond proving that freeze-and-seize is possible on Cardano, the WST prototype also provides a useful example of Plutus design patterns and best practices.

These include:

• Using stake validators for transaction-level validation

  • UTXO spending validators yield to the stake validator script, by checking that the validator is executed as part of the transaction
  • Example: ProgrammableLogicBase, L. 166

• Using the redeemer to point to specific entries in the transaction’s list of inputs or outputs

  • Providing the index as part of the redeemer avoids costly searches in the on-chain code
  • Example: ExampleTransferLogic, L. 145

• Storing the list of frozen accounts as a linked list in the UTXO set

  • This allows us to verify membership and, crucially, non-membership in constant time (relative to size of list)
  • Example: LinkedList

• Unit tests with real ledger code and realistic ledger protocol parameters

  • By testing the scripts against the real ledger codebase and with current protocol parameters from mainnet, we ensure that the system works as expected and that we don’t run into issues related to minimum UTXO values, transaction and block sizes, etc.
  • Example: UnitTest module

• Dedicated UTXO for parameters

  • We store the protocol-specific parameters as an inline datum in a dedicated UTXO that we use as reference input. This makes the parameters discoverable to other users of CIP-0143, and avoids having to change the script hashes every time the parameters change.
  • Example: ProtocolParams module

• Comparing Data representations of expected outputs

  • In our Plutus scripts, when checking that certain required outputs are present, we construct the expected datum as a Data value that we compare for equality against the actual inline datum in the output. This ensures that no extraneous data is included in the inline datum, which could endanger the safety of the protocol (by opening the door for large datum attacks or similar exploits of the encoding)
  • Example: pIsInsertedNode in PTokenDirectory

User Interface (UI) and live demonstration

We also added a slick web application that shows how easy it is for end users to send and receive programmable tokens. The UI is based on next.js and uses lucid to sign and submit transactions.

Live demo

We recently demonstrated WST at the University of Wyoming, where Aijun Hall, an engineering student, executed the freeze and seize actions on the Cardano mainnet.

Here are some transaction IDs generated during the live demo in Laramie, Wyoming:

Transfer WST tokens between two wallets https://cexplorer.io/tx/d92651eaa48e9f825b5fb40d109dff9e74b7754f366dc86b8c9159738e14327f

Freeze an account https://cexplorer.io/tx/6b67f518e681964ac90574749745039cb20a8b190b1afb1c6e6c2fe620db3e11

Seize WST from frozen account https://cexplorer.io/tx/27a94541838d87e53b04ae510d5e5ab1ee344e83e2ba7cbc6b3fe2cc88e6c986

Conclusion

CIP-0143’s versatility supports many different token types while enabling easy integrations with wallets and other applications. A programmable token standard has been one of the most highly anticipated features since the early days of the Alonzo hard fork, and it’s really exciting to finally see convergence on such a powerful and elegant design.

For more information, check out the POC GitHub repo. We encourage you to start a discussion, file a bug report, open a pull request, and, most importantly, start building!

Amir Meyssami contributed to the writing of this article.