# Cartesi PRT Honeypot Markdown version of https://l2beat.com/layer2s/projects/cartesi-prt-honeypot ## Summary **Warning:** This project is archived and no longer maintained. **Warning:** The chain deployment is permanently frozen after the team managed to find a bug in the PRT contracts.[Read more](https://x.com/cartesiproject/status/1970902442259685855) - Total Value Secured: $572.65 (+3.51% compared to seven days ago; canonically bridged $572.65, natively minted $0.00, externally bridged $0.00; 0.00% with additional trust assumptions compared to the tokens involved and the Stage assigned to the project's canonical messaging bridge) - **Warning:** The CTSI token associated with Cartesi PRT Honeypot accounts for 100% of the TVS! (sentiment: bad) - Stage: Stage 2 - Type: Optimistic Rollup - Purpose: Bug bounty - Host chain: Ethereum ### Risks - Sequencer failure: Self sequence (sentiment: good) - State validation: Fraud proofs (INT) (sentiment: good) - Data availability: Onchain (sentiment: good) - Exit window: Not applicable (sentiment: neutral) - Proposer failure: Self propose (sentiment: good) ### About Cartesi PRT Honeypot is an application-specific Stage-2 rollup that stress-tests Cartesi Rollups’ security. Protected solely by Cartesi’s PRT (Permissionless Refereed Tournaments) fraud-proof algorithm, it turns its locked funds into an open bounty for anyone who can break the system. Users should not deposit unless they are willing to donate their funds to the Honeypot. ## Value Secured Shown as an interactive chart or widget on [the HTML page](https://l2beat.com/layer2s/projects/cartesi-prt-honeypot#tvs). - [TVS chart (JSON)](https://l2beat.com/api/scaling/tvs/cartesi-prt-honeypot) - [TVS breakdown by token (JSON)](https://l2beat.com/api/scaling/tvs/cartesi-prt-honeypot/breakdown) ## Onchain costs Shown as an interactive chart or widget on [the HTML page](https://l2beat.com/layer2s/projects/cartesi-prt-honeypot#onchain-costs). ## Liveness Shown as an interactive chart or widget on [the HTML page](https://l2beat.com/layer2s/projects/cartesi-prt-honeypot#liveness). ## Milestones & Incidents - 2025-10-21 (incident): [Cartesi PRT Honeypot postmortem](https://cartesi.io/blog/prt_honeypot_postmortem/). Postmortem of the fail-stop incident. - 2025-09-24 (incident): [Cartesi PRT Honeypot reached a fail-stop state](https://x.com/cartesiproject/status/1970902442259685855). The chain is permanently frozen after the team managed to find a bug in the PRT contracts. - 2025-06-09: [Cartesi PRT Honeypot deployed on Ethereum](https://etherscan.io/address/0x4c1e74ef88a75c24e49eddd9f70d82a94d19251c). Cartesi PRT Honeypot deployed to Ethereum mainnet. - 2025-05-09: [Dave: decentralized, secure, lively fraud-proofs](https://dl.acm.org/doi/10.1145/3734698). Dave paper published on ACM DLT, a peer-reviewed journal. - 2024-11-13: [The Dave Algorithm](https://youtu.be/dI_3neyXVl0). Devcon 2024 presentation introducing the Dave algorithm. - 2023-09-26: [Honeypot Authority launch](https://x.com/cartesiproject/status/1706685141421047982). Honeypot Authority launched on mainnet. - 2023-04-11: [Honeypot Authority announcement](https://medium.com/cartesi/cartesi-ecosystem-update-2023-124b384401cc#:~:text=Honeypot%20DApp%20on%20Mainnet). Honeypot Authority first announced to the community. - 2022-12-23: [Permissionless Refereed Tournaments](https://arxiv.org/abs/2212.12439). PRT paper published on arxiv. ## Risk summary **Warning:** The challenge protocol can be subject to delay attacks. ### Funds can be stolen if 1. there is no one that checks the published state. Fraud proofs assume at least one honest and able validator. ## Risk analysis **Warning:** The challenge protocol can be subject to delay attacks. ### Sequencer failure Self sequence (sentiment: good) Users can self sequence transactions by sending them on L1. There is no privileged operator. ### State validation Fraud proofs (INT) (sentiment: good) Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. ### Data availability Onchain (sentiment: good) All of the data needed for proof construction is published on Ethereum L1. ### Exit window Not applicable (sentiment: neutral) Users cannot exit their funds as all deposits are considered donations. ### Proposer failure Self propose (sentiment: good) Anyone can be a Proposer and propose new roots to the L1 bridge. ## Stage Cartesi PRT Honeypot is a Stage 2 Optimistic Rollup. ### Scope of assessment #### In scope - Ability to deposit and withdraw CTSI by the permissioned address - L1 core contracts - Derivation logic spec - Permissioned Withdrawal logic in the offchain application #### Not in scope - Published offchain Cartesi Machine source code - Cartesi Machine source code to onchain template hash mapping Users can deposit (donate) CTSI tokens to the Honeypot. The funds can only be withdrawn by the Cartesi Multisig to its own address. The appchain has the very specific purpose of a bug bounty on the proof system, incentivizing security researchers to break it and claim the deposited funds. ### Stage 0 - [x] A complete and functional proof system is deployed. - [x] There are at least 5 external actors who can submit fraud proofs. - [x] The project calls itself a rollup. - [x] State roots are posted to Ethereum L1. - [x] Inputs for the state transition function are posted to Ethereum L1. - [x] A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code. [View code](https://github.com/cartesi/dave/tree/main/cartesi-rollups/node) ### Stage 1 - [x] Principle: Compromising ≥75% of the Security Council is the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window. ### Stage 2 - [x] Fraud proof submission is open to everyone. ## Data availability ### All transaction data is recorded on chain All executed transactions are submitted to an on chain smart contract. The execution of the rollup is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain. **References** - [InputBox.sol#18 - Etherscan source code, addInput function](https://etherscan.io/address/0xc70074bdd26d8cf983ca6a5b89b8db52d5850051#code#F1#L18) ## State derivation ### Node software The source code for the Cartesi node software is available [here](https://github.com/cartesi/dave/tree/v1.0.0/cartesi-rollups/node). ### Genesis state The genesis state comes from the Honeypot Cartesi Machine template included in the [Honeypot v2 release](https://github.com/cartesi/honeypot/releases/tag/v2.0.0). Alternatively, you can recreate it by following the build steps in the [Honeypot GitHub Repository](https://github.com/cartesi/honeypot/tree/v2.0.0?tab=readme-ov-file#building-the-application). ### Data format The reference implementation for ERC20 deposits can be found [here](https://github.com/cartesi/rollups-contracts/blob/v2.0.0/src/common/InputEncoding.sol#L38). To learn about the withdrawal request format, please refer to the documentation [here](https://github.com/cartesi/honeypot/wiki/Requesting-withdrawals). ## State validation ### Fraud proofs After some period of time, the published state root is assumed to be correct. For a certain time period, usually one week, anyone can submit a fraud proof that shows that the state was incorrect. **Risks** - Funds can be stolen if there is no one that checks the published state. Fraud proofs assume at least one honest and able validator. **References** - [Permissionless Refereed Tournaments](https://arxiv.org/abs/2212.12439) - [MultiLevelTournamentFactory.sol#L37 - dispute resolution factory](https://etherscan.io/address/0xA31C2aCfF3464658866960c0fBD3d798310272D7#code#F1#L37) - [DaveConsensus.sol#L149 - application consensus](https://etherscan.io/address/0x6CE590b9F0697327f18c601DF6f0baE4a0801B68#code#F1#L149) ## Updates Shown as an interactive chart or widget on [the HTML page](https://l2beat.com/layer2s/projects/cartesi-prt-honeypot#updates). ## Operator ### There is no central operator There is no privileged entity that sequences transactions or produces blocks. This activity is permissionless and open to anyone. **References** - [Honeypot Docs - Running a validator node](https://github.com/cartesi/honeypot/wiki/Running-a-validator-node) ### Users can force any transaction Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. ## Withdrawals ### No user withdrawals No address apart from the Cartesi Multisig can trigger a withdrawal and deposits are considered donations to the Honeypot. If a withdrawal is requested by them, all funds in the escrow are withdrawable to the permissioned address as soon as the next settlement on L1 occurs (min. every 7d 1h). **References** - [Requesting withdrawals, Honeypot Wiki](https://github.com/cartesi/honeypot/wiki/Requesting-withdrawals) ## Permissions ### Ethereum #### Actors ##### Cartesi Multisig Addresses: [0x60247492F1538Ed4520e61aE41ca2A8447592Ff5](https://etherscan.io/address/0x60247492F1538Ed4520e61aE41ca2A8447592Ff5) A Multisig with 3/6 threshold. * Can interact with Application * withdraw the entire balance in the escrow ## Smart contracts ### Ethereum #### Application Addresses: [0x4c1E74EF88a75C24e49eddD9f70D82A94D19251c](https://etherscan.io/address/0x4c1E74EF88a75C24e49eddD9f70D82A94D19251c#code) Main dApp contract that escrows assets and executes the verified results (outputs) from off-chain computation. It relies on the DaveConsensus contract to validate outputs before releasing assets or triggering on-chain actions. The immutable template hash of the dApp is `0x615acc9fb8ae058d0e45c0d12fa10e1a6c9e645222c6fd94dfeda194ee427c14`. * Roles: * **withdrawer**: Cartesi Multisig #### DaveConsensus Addresses: [0x6CE590b9F0697327f18c601DF6f0baE4a0801B68](https://etherscan.io/address/0x6CE590b9F0697327f18c601DF6f0baE4a0801B68#code) Contract managing PRT fraud-proof tournaments, application epochs and input validation, as well as settlement and challenge periods. Dispute tournaments are started here and the final, verified computation result (as an `outputsMerkleRoot`) is recorded when they are resolved. #### InputBox Addresses: [0xc70074BDD26d8cF983Ca6A5b89b8db52D5850051](https://etherscan.io/address/0xc70074BDD26d8cF983Ca6A5b89b8db52D5850051#code) Serves as both the canonical log for arbitrary dApp inputs and a portal for depositing assets (one possible type of input). It ensures data availability and that all off-chain participants process the same inputs in the same order. #### TopTournament Addresses: [0x09114973AE4bf3Af3896E4e541082C73f224F8Aa](https://etherscan.io/address/0x09114973AE4bf3Af3896E4e541082C73f224F8Aa#code) Represents the entry point and highest level of a dispute in PRT. Disagreeing validators join this tournament to resolve conflicts over the entire computation trace through a bisection game. #### BottomTournament Addresses: [0x18256941eC7B661F9F46C228b74e775b581e63f8](https://etherscan.io/address/0x18256941eC7B661F9F46C228b74e775b581e63f8#code) Referees the dispute over a single contested Cartesi machine step as the final stage of arbitration in a dispute. It calls the CartesiStateTransition contract to get a definitive on-chain ruling and identify the winner. #### CartesiStateTransition Addresses: [0x772732EFbDE6559B2960327276ed33d707fF057f](https://etherscan.io/address/0x772732EFbDE6559B2960327276ed33d707fF057f#code) Onchain verifier that can execute a single, disputed instruction of the Cartesi machine. It is the ultimate arbiter that BottomTournament calls to determine which party's claimed state transition is correct. #### MultiLevelTournamentFactory Addresses: [0xA31C2aCfF3464658866960c0fBD3d798310272D7](https://etherscan.io/address/0xA31C2aCfF3464658866960c0fBD3d798310272D7#code) Responsible for creating and orchestrating the multi-stage dispute process. It instantiates the correct tournament contract (Top, Middle, or Bottom) depending on the current stage of the dispute game. #### ERC20Portal Addresses: [0xc700D6aDd016eECd59d989C028214Eaa0fCC0051](https://etherscan.io/address/0xc700D6aDd016eECd59d989C028214Eaa0fCC0051#code) Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps. #### CanonicalTournamentParametersProvider Addresses: [0xcC0a49320891Bf35bca834aF1045ab89Ecd44c0c](https://etherscan.io/address/0xcC0a49320891Bf35bca834aF1045ab89Ecd44c0c#code) Provides constant configuration data for the tournament system. It defines parameters like the number of levels (3), the minimum challenge period of ~7d, and the size of computation segments at each stage of a dispute. #### MiddleTournament Addresses: [0xe49E4CB0Ab5c0E5792E762807329B420Cc4FF1AE](https://etherscan.io/address/0xe49E4CB0Ab5c0E5792E762807329B420Cc4FF1AE#code) Handles the intermediate stages of a dispute following the TopTournament targeting a more granular bisection game.