Search for projects by name
Honeypot is an application-specific rollup designed to challenge the security of Cartesi Rollups. It provides a gamified battlefield to incentivize bug hunters to hack the application to obtain the funds locked in the rollup contract.
Honeypot is an application-specific rollup designed to challenge the security of Cartesi Rollups. It provides a gamified battlefield to incentivize bug hunters to hack the application to obtain the funds locked in the rollup contract.
The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.
The project will move to Others because:
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Learn more about the recategorisation here.
Currently the system permits invalid state roots. More details in project overview.
Users can exit funds at any time because contracts are not upgradeable.
Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
Ultimately, Cartesi DApps will use interactive fraud proofs to enforce state correctness. This feature is currently in development and the Honeypot DApp permits invalid state roots. Since Honeypot is immutable, this feature will not be added to the DApp.
Funds can be stolen if an invalid state root is submitted to the system by the configured Authority (CRITICAL).
No compression is used.
The genesis state is derived from the Honeypot Cartesi Machine template, which can be found within the Honeypot server Docker image at /var/opt/cartesi/machine-snapshots/0_0
. Alternatively, it is possible to recreate it by following the build procedure outlined in the Honeypot GitHub Repository.
The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
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.
The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization usually takes several days to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).
The Authority owner can submit claims to the Honeypot DApp.
CartesiDApp instance for the Honeypot DApp, responsible for holding assets and allowing the DApp to interact with other smart contracts. This contract can store any token.
Contract that receives arbitrary blobs as inputs to Cartesi DApps.
Contract that allows anyone to perform transfers of ERC-20 tokens to Cartesi DApps.
Simple consensus model controlled by a single address, the owner.
Contract that stores claims for Cartesi DApps.
Contract storing bounty funds.