Search for projects by name or address
The chain deployment is permanently frozen after the team managed to find a bug in the PRT contracts.Read more
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.
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.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
Cartesi PRT Honeypot reached a fail-stop state
2025 Sep 24th
The chain is permanently frozen after the team managed to find a bug in the PRT contracts.
Users can self sequence transactions by sending them on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. There is no privileged operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades..
Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve.
All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..
Users cannot exit their funds as all deposits are considered donations.
Anyone can be a ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and propose new roots to the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..
Rollup operators cannot compromise the system, but being application-specific might bring additional risk.
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.
All executed transactions are submitted to an on chain smart contract. The execution of the rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain.
The genesis state comes from the Honeypot Cartesi Machine template included in the Honeypot v2 release. Alternatively, you can recreate it by following the build steps in the Honeypot GitHub Repository.
The information in the section might be incomplete or outdated.
The L2BEAT Team is working to research & validate the content before publishing.
After some period of time, the published state rootA cryptographic hash succinctly representing a state using a Merkle tree. is assumed to be correct. For a certain time period, usually one week, anyone can submit a fraud proofAlso referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system. that shows that the state was incorrect.
Funds can be stolen if there is no one that checks the published state. Fraud proofs assume at least one honest and able validator.
Discovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
| + | Status: CREATED |
| contract TopTournament (0x09114973AE4bf3Af3896E4e541082C73f224F8Aa) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract BottomTournament (0x18256941eC7B661F9F46C228b74e775b581e63f8) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MiddleTournamentFactory (0x2B3272E7Bcf06d36b9A902dfc0dD0d9384F2A4c4) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Application (0x4c1E74EF88a75C24e49eddD9f70D82A94D19251c) | |
| +++ description: Main dApp contract that escrows assets and executes the verified results (outputs) from off-chain computation. It relies on the eth:0x6CE590b9F0697327f18c601DF6f0baE4a0801B68 contract to validate outputs before releasing assets or triggering on-chain actions. The immutable template hash of the dApp is `0x615acc9fb8ae058d0e45c0d12fa10e1a6c9e645222c6fd94dfeda194ee427c14`. | |
| + | Status: CREATED |
| contract BottomTournamentFactory (0x4C7ab101e9B114A253475485b301E0D0c9e20647) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Cartesi Multisig (0x60247492F1538Ed4520e61aE41ca2A8447592Ff5) | |
| +++ description: None | |
| + | Status: CREATED |
| contract DaveConsensus (0x6CE590b9F0697327f18c601DF6f0baE4a0801B68) | |
| +++ description: Contract managing PRT fraud-proof tournaments, managing 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. | |
| + | Status: CREATED |
| contract TopTournamentFactory (0x71C6A5fF7f4f31451CcB5bE312Fa1C5F2a060d5c) | |
| +++ description: None | |
| + | Status: CREATED |
| contract CartesiStateTransition (0x772732EFbDE6559B2960327276ed33d707fF057f) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MultiLevelTournamentFactory (0xA31C2aCfF3464658866960c0fBD3d798310272D7) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract InputBox (0xc70074BDD26d8cF983Ca6A5b89b8db52D5850051) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract ERC20Portal (0xc700D6aDd016eECd59d989C028214Eaa0fCC0051) | |
| +++ description: Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps. | |
| + | Status: CREATED |
| contract CanonicalTournamentParametersProvider (0xcC0a49320891Bf35bca834aF1045ab89Ecd44c0c) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MiddleTournament (0xe49E4CB0Ab5c0E5792E762807329B420Cc4FF1AE) | |
| +++ description: Handles the intermediate stages of a dispute following the TopTournament targeting a more granular bisection game. | |
add cartesi multisig withdrawer permission.
add cartesi multisig withdrawer permission.
| + | Status: CREATED |
| contract Cartesi Multisig (0x60247492F1538Ed4520e61aE41ca2A8447592Ff5) | |
| +++ description: None | |
Initial cartesi fault proofs discovery.
Initial cartesi fault proofs discovery.
| + | Status: CREATED |
| contract TopTournament (0x09114973AE4bf3Af3896E4e541082C73f224F8Aa) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract BottomTournament (0x18256941eC7B661F9F46C228b74e775b581e63f8) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MiddleTournamentFactory (0x2B3272E7Bcf06d36b9A902dfc0dD0d9384F2A4c4) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Application (0x4c1E74EF88a75C24e49eddD9f70D82A94D19251c) | |
| +++ description: Main dApp contract that escrows assets and executes the verified results (outputs) from off-chain computation. It relies on the 0x6CE590b9F0697327f18c601DF6f0baE4a0801B68 contract to validate outputs before releasing assets or triggering on-chain actions. | |
| + | Status: CREATED |
| contract BottomTournamentFactory (0x4C7ab101e9B114A253475485b301E0D0c9e20647) | |
| +++ description: None | |
| + | Status: CREATED |
| contract DaveConsensus (0x6CE590b9F0697327f18c601DF6f0baE4a0801B68) | |
| +++ description: Contract managing PRT fraud-proof tournaments, managing 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. | |
| + | Status: CREATED |
| contract TopTournamentFactory (0x71C6A5fF7f4f31451CcB5bE312Fa1C5F2a060d5c) | |
| +++ description: None | |
| + | Status: CREATED |
| contract CartesiStateTransition (0x772732EFbDE6559B2960327276ed33d707fF057f) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MultiLevelTournamentFactory (0xA31C2aCfF3464658866960c0fBD3d798310272D7) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract InputBox (0xc70074BDD26d8cF983Ca6A5b89b8db52D5850051) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract ERC20Portal (0xc700D6aDd016eECd59d989C028214Eaa0fCC0051) | |
| +++ description: Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps. | |
| + | Status: CREATED |
| contract CanonicalTournamentParametersProvider (0xcC0a49320891Bf35bca834aF1045ab89Ecd44c0c) | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract MiddleTournament (0xe49E4CB0Ab5c0E5792E762807329B420Cc4FF1AE) | |
| +++ description: Handles the intermediate stages of a dispute following the TopTournament targeting a more granular bisection game. | |
There is no privileged entity that sequences transactions or produces blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. This activity is permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. and open to anyone.
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.
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 settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. occurs (min. every 7d 1h).

A Multisig with 3/6 threshold.


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 hashA fixed-length fingerprint of variable-size input, produced by a hash function. of the dApp is 0x615acc9fb8ae058d0e45c0d12fa10e1a6c9e645222c6fd94dfeda194ee427c14.
All supported tokens in this escrow are included in the value secured calculation.
Contract managing PRT fraud-proof tournaments, application epochs and input validation, as well as settlementThe mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proofs and allowing for withdrawals. and challenge periods. Dispute tournaments are started here and the final, verified computation result (as an outputsMerkleRoot) is recorded when they are resolved.
Serves as both the canonical log for arbitrary dApp inputs and a portal for depositing assets (one possible type of input). It ensures data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. and that all off-chain participants process the same inputs in the same order.
Represents the entry point and highest level of a dispute in PRT. Disagreeing validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier join this tournament to resolve conflicts over the entire computation trace through a bisection game.
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.
Onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.
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.
Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps.
Provides constant configuration data for the tournament system. It defines parameters like the number of levels (3), the minimum challenge periodIn optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until withdrawals gets enabled. of ~7d, and the size of computation segments at each stage of a dispute.
Handles the intermediate stages of a dispute following the TopTournament targeting a more granular bisection game.