Search

Search for projects by name or address

Cartesi PRT Honeypot logo
Cartesi PRT Honeypot

The chain deployment is permanently frozen after the team managed to find a bug in the PRT contracts.Read more

Badges

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...



Badges

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...


Total
Canonically BridgedCanonically Bridged ValueCanonical
Natively MintedNatively Minted TokensNative
Externally BridgedExternally Bridged ValueExternal

ETH & derivatives
Stablecoins
BTC & derivatives
Other

The section shows the operating costs that L2s pay to Ethereum.



Total cost
Avg cost per L2 UOP
Avg cost per day

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.


Avg. tx data subs. interval
Avg. state updates interval

Cartesi PRT Honeypot postmortem

2025 Oct 21st

Postmortem of the fail-stop incident.

Learn more

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.

Learn more
The challenge protocol can be subject to delay attacks.
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Self sequence

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..

State validation
Fraud proofs (INT)

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

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..

Exit window
Not applicable
Bug bounty Appchain: The single hardcoded address can withdraw all funds.

Users cannot exit their funds as all deposits are considered donations.

Proposer failure
Self propose

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..

Cartesi PRT Honeypot
Cartesi PRT Honeypot is a
Stage 2
Appchain
Optimistic Rollup.

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.

Note:
We're still in the process of formalizing how to properly integrate appchains in the Stages framework.

Learn more about Stages
Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

All transaction data is recorded on chain

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.

  1. InputBox.sol#18 - Etherscan source code, addInput function
Learn more about the DA layer here: Ethereum logoEthereum
Node software

The source code for the Cartesi nodeA software client that participates in the network. software is available here.

Genesis state

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.

Data format

The reference implementation for ERC20 deposits can be found here. To learn about the withdrawal request format, please refer to the documentation here.

Under Review

The information in the section might be incomplete or outdated.
The L2BEAT Team is working to research & validate the content before publishing.

Fraud proofs

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.

  1. Permissionless Refereed Tournaments
  2. MultiLevelTournamentFactory.sol#L37 - dispute resolution factory
  3. DaveConsensus.sol#L149 - application consensus

Program Hashes

Name
Hash
Repository
Verification
Used in
0x615a...7c14
Code unknown
None
Cartesi PRT Honeypot logo
2025 July 14, 12:44 UTC
14changes

Discovery rerun on the same block number with only config-related changes.

New and verified contracts

+ 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.
2025 June 18, 07:22 UTC
1change

add cartesi multisig withdrawer permission.

New and verified contracts

+ Status: CREATED
contract Cartesi Multisig (0x60247492F1538Ed4520e61aE41ca2A8447592Ff5)
+++ description: None
2025 June 17, 15:28 UTC
13changes

Initial cartesi fault proofs discovery.

Initial 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 central operator

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.

  1. Honeypot Docs - 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.

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 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).

  1. Requesting withdrawals, Honeypot Wiki
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Actors:

Cartesi Multisig0x6024…2Ff5

A Multisig with 3/6 threshold.

  • Can interact with Application
    • withdraw the entire balance in the escrow
Used in:
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner
A diagram of the smart contract architecture
A diagram of the smart contract architecture

Ethereum

Application
Escrow
0x4c1E…251c

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.

  • Roles:
    • withdrawer: Cartesi Multisig

All supported tokens in this escrow are included in the value secured calculation.

DaveConsensus0x6CE5…1B68

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.

TopTournament0x0911…F8Aa

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.

BottomTournament0x1825…63f8

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.

CartesiStateTransition0x7727…057f

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.

MultiLevelTournamentFactory0xA31C…72D7

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.

ERC20Portal0xc700…0051

Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps.

CanonicalTournamentParametersProvider0xcC0a…4c0c

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.

MiddleTournament0xe49E…F1AE

Handles the intermediate stages of a dispute following the TopTournament targeting a more granular bisection game.

Program Hashes

Name
Hash
Repository
Verification
Used in
0x615a...7c14
Code unknown
None
Cartesi PRT Honeypot logo