Search
Search for projects by name
Cartesi PRT Honeypot
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... anyone who can break the system.
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... anyone who can break the system.
2025 Jun 10 — 17
The section shows the operating costs that L2s pay to Ethereum.
2025 Jun 11 — 17
The chart illustrates how "live" the project's operators are by displaying how frequently they submit transactions of the selected type and if these intervals deviate from their typical schedule.
2025 Jun 11 — 11
Cartesi PRT Honeypot deployed on Ethereum
2025 Jun 9th
Cartesi PRT Honeypot deployed to Ethereum mainnet.
Dave: decentralized, secure, lively fraud-proofs
2025 May 9th
Dave paper published on ACM DLT, a peer-reviewed journal.
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 L1.
Users can exit funds at any time because contracts are not upgradeable.
Cartesi PRT Honeypot is a Rollup operators cannot compromise the system, but being application-specific might bring additional risk.
Users can deposit (donate) CTSI tokens to the Honeypot. To request a withdrawal, they need to post an input to the InputBox with the application address and `0x` arguments as described in the Withdrawals section. Withdrawals are configured to go to a single address (not the user's).
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.
EthereumThe 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 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.
Funds can be stolen if there is no one that checks the published state. Fraud proofs assume at least one honest and able validator.
There is no central operator
There is no privileged entity that sequences transactions or produces blocks. This activity is permissionless and open to anyone.
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.
Ethereum
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.
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.
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.
- This contract can store any token.
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.
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.
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.
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.
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 period 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.
Value Secured is calculated based on these smart contracts and tokens:
Contract storing bounty funds.