ZTF

ZTF, decentralised cross-chain bounty and crisis management protocol. aka On-chain CTF.

While audits and bug bounty are focus on bugs. We think damages from others risks should be cover too. Most of the security are based on code and some even in limited scope. (e.g. external integration are often out of scope)

There’re a lot of issues when crisis happened. The scope of impact might not be well define as the damage ripple out to others protocols. Even when the action have to be taken, privileged account holders are not available. Sometime time lock or others mechanic prevent timely interventions.

While a lot of lost are result of economic, external integrations, unforeseen states, etc. We want to add a solution that allow pre-plan action that can be trigger by both direct and indirect threat.

Our protocol go with more damage oriented bounty. we allow protocol to set up initial state and undesirable state. (flag contracts) This mean that protocol can setup any state real or hypothetical. e.g. what if the TVL is too high compared to liquidity. Then the flag can be anything that programable in solidity. e.g. loss of fund, value changed too much, etc.

On Whitehat side. Start with the initial state, send any amount of txs to move state to where the flag is captured. this is almost equivalence to normal EVM. (we strip out some feature to make it faster) Then use our CLI to generate PoV to claim the bounty

We also allow anyone to setup callback on bounties. This allow users to plan action on vulnerability. This action could range from pause protocol, withdraw, trade, etc. basically anything programable. And with Wormhole this support cross-chain call too.

Since the the main tech stack we used is zero-knowledge proof, we choose STARK from RISC-0 ZKVM for their flexibility on general purpose ZKVM, combined with Bonsai to make STARK to SNARK able to happen so we can use the proof to verify on-chain!

In the ZKVM we used revm + ethers stack to create a block and transaction simulation, and other utilities for setting up initial environment variables.

In the cli part we use Rust since its directly dependent on our ZKVM stack and Clap for cli's argument parsing.

In the smart contract part we use Foundry for our Solidity toolkit and Openzeppelin contracts for some of the modifiers.

In the frontend part we use Next.js, React, ChakraUI for components, Wagmi Hooks and Viem for blockchain interaction, and finally Web3modal for wallet connectors.