Philip DiSarro Reports Two Critical Flaws in Aiken’s CIP-113 Implementation

Philip DiSarro, founder and CEO of Anastasia Labs and author of CIP-143, said on July 24 that he identified two critical vulnerabilities while reviewing the Aiken implementation of Cardano’s CIP-113 programmable token framework. In the same thread, he released updated benchmarks comparing the Aiken codebase with the original Plutarch implementation developed by DiSarro and the Input Output team. The disclosure comes while CIP-113 remains at the Last Check stage and its implementation continues through security review.

Plutarch Records Lower Costs Across CIP-113 Benchmarks

The published benchmark file compares the two implementations under Cardano’s maximum transaction budget of 10 billion CPU units and 14 million memory units. Both Aiken and Plutarch ultimately compile into Untyped Plutus Core, the code executed by Cardano nodes.

Plutarch recorded lower total CPU and memory consumption in each of the five highlighted scenarios.

In the standard transfer test, Aiken used 1.19 times more CPU and 1.17 times more memory than Plutarch. The largest difference among the displayed scenarios appeared in the test combining a seizure action, an external script and 50 public-key inputs, where Aiken consumed 3.23 times more CPU and 2.36 times more memory.

Both implementations remained within Cardano’s transaction limits in the 16-swap $NIGHT DEX test. Plutarch used 6.66% of the available CPU budget and 11.68% of the memory budget, compared with 7.59% and 15.25% for Aiken.

DiSarro’s publication also included linear projections for how many elements could fit within one transaction. The estimates placed Plutarch at 658 inputs compared with 162 for Aiken, 472 outputs compared with 334, 36,489 tokens compared with 1,661, and 527 policies compared with 160. These figures are script-capacity projections derived from tested execution costs rather than measured mainnet throughput.

The compiled script comparison produced smaller Plutarch scripts in six of seven categories. The directoryNodeSpending script measured 331 bytes in Plutarch and 1,698 bytes in Aiken. The exception was programmableLogicGlobal, where Aiken produced a 3,157-byte script compared with 3,437 bytes for Plutarch.

CIP-113 Adds Programmable Rules to Cardano Native Assets

CIP-113 proposes a framework for adding programmable validation rules to Cardano native assets without requiring a ledger change or hard fork. Issuers could define conditions that execute during token transfers, minting and burning.

The rules can include allowlists, denylists, transfer restrictions, time locks and optional freeze or seizure functions. The framework is intended for stablecoins, tokenized securities and real-world assets that require controls around ownership and movement.

Under the proposed architecture, programmable tokens are held at a shared smart contract address, while ownership is represented through stake credentials. An on-chain registry connects each token policy with its transfer rules, issuance logic and any authorized third-party controls.

Wallets would need to resolve stake credentials to display balances correctly. Decentralized exchanges, indexers, explorers and other applications would also need to support the additional validation process before users could interact with programmable tokens through existing Cardano infrastructure.

Aiken and Plutarch provide different development approaches while compiling to the same on-chain code format. Cardano’s developer documentation presents Aiken as an accessible starting point with integrated testing and a purpose-built syntax. Plutarch is a Haskell-based embedded language that gives developers more detailed control over generated code and execution costs.

DiSarro authored CIP-143, Interoperable Programmable Tokens, and worked with the Input Output team on its original Plutarch reference implementation. The Cardano Foundation repository states that the current Aiken validators were migrated from that implementation and adapted for the broader CIP-113 framework.

His direct involvement in the original architecture and codebase places the new benchmark comparison within the project’s development history. CIP-143 is now marked as inactive after being incorporated into candidate CIP-113, which remains in the CIP editors’ Last Check review stage.

Two Reported Vulnerabilities Await Technical Disclosure

DiSarro said his review of the Aiken implementation uncovered two critical vulnerabilities that were missed during the audit process. His thread did not identify the affected code, possible attack paths, potential impact or remediation status.

The repository already contains public findings from the initial audit, including two closed issues labeled critical. Issue 56 described a path through which newly minted tokens could escape programmable custody during a third-party action. Issue 64 addressed the possible contamination of unrelated UTxOs through the same administrative function.

Those findings were reported during the initial audit and cannot be identified as the two vulnerabilities DiSarro reported finding afterward without further technical disclosure.

Security concerns have also been raised within the CIP-113 review discussion. A contributor said on July 20 that multiple high-severity vulnerabilities had been missed and that some proposed usability changes introduced additional security problems. During the subsequent CIP review, participants agreed that the next step should include a more comprehensive audit while the proposal remains at Last Check.

The Cardano Foundation repository states that findings from the initial audit and a follow-up re-audit have been remediated on the main branch. However, the final audit report remains unpublished, and the repository designates the implementation as unsuitable for production use with real assets until the report, broader testing and further expert review are completed.

Before the CIP-113 implementation can progress toward real-asset deployments, three concrete outputs remain pending: publication of the final audit report, disclosure and remediation of the two vulnerabilities reported by DiSarro, and completion of the broader security review requested during the CIP process. Those outputs will define which code and specification changes are incorporated before the proposal is merged and the implementation is considered for production use.