Philip DiSarro Report Two Critical Flaws for Aiken CIP-113 Implementation

Philip DiSarro, founder and CEO of Anastasia Labs and author of CIP-143, talk on July 24 say im spot two critical vulnerabilities as im dey review the Aiken implementation of Cardano CIP-113 programmable token framework. For the same thread, im release updated benchmarks wey compare the Aiken codebase with the original Plutarch implementation wey DiSarro and the Input Output team build. This disclosure land as CIP-113 still dey for the Last Check stage and im implementation still dey go through security review.

Plutarch Record Lower Costs Across CIP-113 Benchmarks

The published benchmark file compare the two implementations under Cardano maximum transaction budget of 10 billion CPU units and 14 million memory units. Both Aiken and Plutarch finally compile into Untyped Plutus Core, the code wey Cardano nodes dey execute.

Plutarch record lower total CPU and memory consumption for each of the five scenarios wey dem highlight.

For the standard transfer test, Aiken use 1.19 times more CPU and 1.17 times more memory pass Plutarch. The biggest difference among the scenarios wey dem show appear for the test wey combine seizure action, external script and 50 public-key inputs, where Aiken consume 3.23 times more CPU and 2.36 times more memory.

Both implementations still dey inside Cardano transaction limits for the 16-swap $NIGHT DEX test. Plutarch use 6.66% of the available CPU budget and 11.68% of the memory budget, compared with 7.59% and 15.25% for Aiken.

DiSarro publication still include linear projections of how many elements fit inside one transaction. The estimates put Plutarch for 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 numbers na script-capacity projections wey dem derive from tested execution costs, no be measured mainnet throughput.

The compiled script comparison produce smaller Plutarch scripts for six out of seven categories. The directoryNodeSpending script measure 331 bytes for Plutarch and 1,698 bytes for Aiken. The exception na programmableLogicGlobal, where Aiken produce 3,157-byte script compared with 3,437 bytes for Plutarch.

CIP-113 Add Programmable Rules to Cardano Native Assets

CIP-113 propose framework to add programmable validation rules to Cardano native assets without need ledger change or hard fork. Issuers fit define conditions wey go execute during token transfers, minting and burning.

The rules fit include allowlists, denylists, transfer restrictions, time locks and optional freeze or seizure functions. The framework target stablecoins, tokenized securities and real-world assets wey need controls around ownership and movement.

Under the proposed architecture, programmable tokens go dey for one shared smart contract address, while ownership go dey represented through stake credentials. One on-chain registry go connect each token policy with im transfer rules, issuance logic and any authorized third-party controls.

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

Aiken and Plutarch provide different development approaches but both dey compile to the same on-chain code format. Cardano developer documentation present Aiken as accessible starting point with integrated testing and purpose-built syntax. Plutarch na Haskell-based embedded language wey give developers more detailed control over generated code and execution costs.

DiSarro author CIP-143, Interoperable Programmable Tokens, and im work with the Input Output team on the original Plutarch reference implementation. The Cardano Foundation repository talk say the current Aiken validators migrate from that implementation and dem adapt am for the broader CIP-113 framework.

Im direct involvement for the original architecture and codebase put the new benchmark comparison inside the project development history. CIP-143 now mark as inactive after dem incorporate am into candidate CIP-113, wey still dey for the CIP editors Last Check review stage.

Two Reported Vulnerabilities Dey Wait Technical Disclosure

DiSarro talk say im review of the Aiken implementation uncover two critical vulnerabilities wey audit process miss. Im thread no identify the affected code, possible attack paths, potential impact or remediation status.

The repository don already get public findings from the initial audit, including two closed issues wey dem label critical. Issue 56 describe one path wey newly minted tokens fit take escape programmable custody during third-party action. Issue 64 address the possible contamination of unrelated UTxOs through the same administrative function.

Those findings dem report am during the initial audit and we no fit identify dem as the two vulnerabilities wey DiSarro later report without further technical disclosure.

Security concerns don also show for inside the CIP-113 review discussion. One contributor talk on July 20 say multiple high-severity vulnerabilities miss and say some proposed usability changes introduce extra security problems. During the next CIP review, participants agree say the next step suppose include more comprehensive audit while the proposal still dey Last Check.

The Cardano Foundation repository talk say findings from the initial audit and follow-up re-audit don get remediation for the main branch. But the final audit report never publish, and the repository mark the implementation as no suitable for production use with real assets until the report, broader testing and more expert review complete.

Before the CIP-113 implementation fit move go real-asset deployments, three concrete outputs still remain: publication of the final audit report, disclosure and remediation of the two vulnerabilities wey DiSarro report, and completion of the broader security review wey dem request during the CIP process. These outputs go define which code and specification changes dem go incorporate before dem merge the proposal and consider the implementation for production use.