Max bounty$100,000 in USDCHow do bug bounties work on C4?

Renegade Bug Bounty

  • Until TVL exceeds $25M
    • Max Critical Payout: $100,000 USDC
    • High Severity Payout: $20,000 USDC
  • After TVL exceeds $25M
    • Max Critical Payout: $250,000 USDC
    • High Severity Payout: $20,000 USDC

Background on Renegade

What Is Renegade?

Renegade is a new type of decentralized exchange, an on-chain dark pool.

Current DEXes are completely transparent: Anyone can see your balances and trade history. In contrast, Renegade gives users universal trade privacy. That means that trading activity is completely obscured from all third-parties, both before and after a trade is filled. No one except the trader can learn the details of her balances or trades.

Renegade is also oracle-free: distributing the matching engine means that prices may be agreed upon and authorized rather than imposed upon traders from an oracle. This allows Renegade's matching engine to build around a "bring your own price" model, which obviates the need for an oracle.

In all, Renegade provides users guaranteed best execution at the real-time Binance midpoint with full pre-trade and post-trade privacy.

How Does It Work?

Renegade makes two fundamental steps to achieve pre- and post- trade privacy: <br />

  1. Renegade decentralizes the order book -- each user alone knows their balances and orders. The matching engine is then run on distributed state and its execution made input-private by encoding the matching engine logic in a secure two party computation, based on SPDZ. This gives the system pre-trade privacy; no party learns another's state as guaranteed by the 2PC. <br />
  2. Renegade Merklizes the exchange state and stores the tree in a Stylus smart contract. The leaves in this tree are opaque, blinded commitments to user "wallets" that contain balances, orders, etc. The smart contract is equipped with a PlonK verifier, which allows the contract to enforce predicates representing match settlement, user state updates, etc on any commitments inserted into the Merkle tree. The commitments & zero-knowledge proofs attesting to their validity provide the exchange with a secure, post-trade private settlement layer.

Lastly, to take part in MPCs the user must be "online" at all times. This is an unrealistic assumption, so we introduce relayers; actors in the system that manage the state of user orders and shoulder the computational burden of the PlonK prover. Relayers can be grouped into clusters to enable horizontal scaling, with each relayer in a cluster having identical permissions to manage its share of the overall state.

Note: When a user delegates its wallet to a relayer, the relayer may only match orders, it may not update state: placing/cancelling orders, depositing/withdrawing balances, etc. This protection is encoded in a wallet's keychain, which is only partially shared with the relayer, and which the smart contract uses to authenticate state updates.

The following figure shows three relayer clusters interacting with the smart contract; including a "Public Gateway" managed by Renegade.

Further Technical Resources & Links

  • zkSecurity Audit (@zksecurityXYZ): An audit of our circuits and smart contracts with a great system overview enriched with helpful diagrams. [Link]
  • Renegade Circuit Spec: A specification of our system and the types, invariants, and constraints used in our circuits. [Link]
  • Renegade Docs: Our system documentation, subject to change. [Link]
  • Renegade Whitepaper: The whitepaper our current instantiation is based off of. Note that the implemented system diverges from the whitepaper's description in significant ways. [Link]
  • Renegade Website: https://renegade.fi
  • Twitter: @renegade_fi
  • Discord https://discord.gg/renegade-fi

Scope & Severity Criteria

Severity: Safety versus Privacy

We delineate the critical versus high severity of a finding based on safety versus privacy respectively. That is, a critical finding must demonstrate high likelihood of being exploited and with impact that results in the theft or freezing of user funds.

A finding that does not place user funds at risk but demonstrates a high likelihood of being exploited with impact that results in the leaking of user balances or open orders will not be classified as critical, but may be classified as high.

Scope

Relayer Codebase

Note that at launch, MPC matches are disabled -- all state is managed by the Renegade cluster, which will rely solely on its internal matching engine. So findings in the context of the MPC matching engine are out of scope until MPC is enabled.

As such, the relayer codebase is scoped down to those sources relevant to the safety of user funds and the privacy of user state in a single-cluster setup. These are, in particular: the circuit types, circuits, gadgets, and the relayer's API server -- through which state is accessible.

As the system decentralizes, this scope will expand to include sources relevant in the multiparty context.

Sources found here: Github

FileSLOCPurpose
circuit-types/src/merkle.rs38Merkle tree circuit types
circuit-types/src/order.rs193User order circuit types
circuit-types/src/srs.rs267The structured reference string used in our PlonK setup
circuit-types/src/transfers.rs81The transfer circuit type for deposits/withdrawals
circuit-types/src/lib.rs463Circuit type definitions
circuit-types/src/note.rs72The note type, used to pay fees out of a balance
circuit-types/src/fixed_point.rs841A circuit type for fixed point representation in finite fields
circuit-types/src/balance.rs87User balance circuit types
circuit-types/src/match.rs106The match tuple circuit types -- the result of a match
circuit-types/src/wallet.rs152The user's wallet circuit type
circuit-types/src/errors.rs77Errors for circuit types
circuit-types/src/elgamal.rs253ElGamal encryption types
circuit-types/src/keychain.rs396User keychain circuit types
circuit-types/src/traits.rs1132Traits for interacting with circuit types
circuits/src/zk_circuits/valid_fee_redemption.rs826The circuit for valid fee redemption
circuits/src/zk_circuits/valid_commitments.rs1007The circuit for valid commitments
circuits/src/zk_circuits/valid_wallet_update.rs1445The circuit for valid wallet update
circuits/src/zk_circuits/valid_reblind.rs628The circuit for valid reblind
circuits/src/zk_circuits/valid_wallet_create.rs299The circuit for valid wallet create
circuits/src/zk_circuits/proof_linking.rs753Proof linking implementation
circuits/src/zk_circuits/valid_offline_fee_settlement.rs828The circuit for valid offline fee settlement
circuits/src/zk_circuits/mod.rs391Module definitions for circuits
circuits/src/zk_circuits/valid_match_settle/multi_prover.rs479The multi-prover circuit for valid match settlement
circuits/src/zk_circuits/valid_match_settle/single_prover.rs456The single-prover circuit for valid match settlement
circuits/src/zk_circuits/valid_match_settle/mod.rs912Module definitions for match settlement circuits
circuits/src/zk_circuits/valid_relayer_fee_settlement.rs1085The circuit for validating relayer fee settlement
circuits/src/zk_gadgets/merkle.rs338Gadgets for Merkle tree operations
circuits/src/zk_gadgets/arithmetic.rs167Gadgets for arithmetic operations
circuits/src/zk_gadgets/wallet_operations.rs530Gadgets for wallet operations
circuits/src/zk_gadgets/bits.rs347Gadgets for bit operations
circuits/src/zk_gadgets/note.rs79Gadgets for note operations
circuits/src/zk_gadgets/fixed_point.rs298Gadgets for fixed-point arithmetic
circuits/src/zk_gadgets/mod.rs18Module definitions for zk gadgets
circuits/src/zk_gadgets/comparators.rs650Gadgets for boolean comparison operations
circuits/src/zk_gadgets/select.rs132Gadgets for selection operations
circuits/src/zk_gadgets/elgamal.rs197Gadgets for ElGamal encryption operations
circuits/src/zk_gadgets/poseidon.rs384Gadgets for Poseidon hash function operations
workers/api-server/src/websocket/price_report.rs114Handles websocket communication for price reporting
workers/api-server/src/websocket/handler.rs89Main websocket message handler
workers/api-server/src/websocket/task.rs123Manages websocket messages for relayer tasks
workers/api-server/src/websocket/wallet.rs74Handles wallet-related websocket operations
workers/api-server/src/websocket/order_status.rs64Manages order status updates via websocket
workers/api-server/src/auth/admin_auth.rs126Implements authentication for admin users
workers/api-server/src/auth/helpers.rs49Helper functions for authentication
workers/api-server/src/auth/mod.rs84Module definitions for authentication
workers/api-server/src/auth/wallet_auth.rs134Implements authentication for wallet users
workers/api-server/src/error.rs72Defines error types and handling for the API server
workers/api-server/src/lib.rs20Main library file for the API server
workers/api-server/src/worker.rs144The main event loop for the API server
workers/api-server/src/compliance/client.rs46Compliance client for the API server
workers/api-server/src/compliance/mod.rs5Module definitions for compliance-related functionality
workers/api-server/src/websocket.rs404Main websocket implementation and routing
workers/api-server/src/http/price_report.rs63Handles HTTP routes for price reporting
workers/api-server/src/http/task.rs156Manages HTTP routes for relayer tasks
workers/api-server/src/http/wallet.rs957Implements HTTP routes for wallet state
workers/api-server/src/http/network.rs148Handles HTTP routes for p2p network operations
workers/api-server/src/http/order_book.rs97Manages HTTP routes for network order book
workers/api-server/src/http/admin.rs475Implements HTTP routes for admin operations
workers/api-server/src/router.rs381Main router for HTTP and websocket routes
workers/api-server/src/http.rs530Main HTTP implementation and routing
Total20762

Smart Contracts

Sources found here: Github

FileSLOCPurpose
contracts-common/src/types.rs522Types for smart contracts
contracts-common/src/constants.rs119Constants used in smart contracts
contracts-common/src/solidity.rs89Solidity type definitions
contracts-common/src/lib.rs14Library file
contracts-common/src/serde_def_types.rs166Serde foreign trait implementations
contracts-common/src/backends.rs71Arithmetic and hashing backends
contracts-common/src/custom_serde.rs511Custom serialization and deserialization
contracts-core/src/crypto/mod.rs4Module file
contracts-core/src/crypto/poseidon.rs10Shim code for Poseidon hash function
contracts-core/src/crypto/ecdsa.rs94ECDSA signature verification and related functions
contracts-core/src/lib.rs13Main library file for contracts-core
contracts-core/src/transcript/mod.rs290Implementation of Fiat-Shamir transformation and transcript
contracts-core/src/verifier/mod.rs1197Main implementation of PlonK verification
contracts-core/src/verifier/errors.rs37Error types and handling for the verifier module
contracts-stylus/src/contracts/merkle.rs353Implements Merkle tree operations for the darkpool
contracts-stylus/src/contracts/transfer_executor.rs152Handles token transfer execution in the darkpool
contracts-stylus/src/contracts/vkeys.rs55Manages verification keys for PlonK proofs
contracts-stylus/src/contracts/darkpool_core.rs790Core functionality of the darkpool contract
contracts-stylus/src/contracts/mod.rs28Module definitions for darkpool contracts
contracts-stylus/src/contracts/verifier.rs46Implements PlonK proof verification
contracts-stylus/src/contracts/darkpool.rs599Main darkpool contract implementation
contracts-stylus/src/lib.rs17Library file for the darkpool project
contracts-stylus/src/utils/constants.rs539Constants used across the darkpool contracts
contracts-stylus/src/utils/solidity.rs76Solidity type definitions
contracts-stylus/src/utils/helpers.rs254Helper functions for the darkpool contracts
contracts-stylus/src/utils/mod.rs7Module definitions for utility functions
contracts-stylus/src/utils/backends.rs156Arithmetic and hashing backends
Total6209

Additional Context

Publicly Known Issues

The following are publicly known issues that will not be considered valid findings, but may be helpful pointers as to where to look for vulnerabilities:

  • Users may avoid paying the relayer a fee if they are able to "self match" at a zero (or low) price — effectively a transfer to another wallet. This drains a balance in one wallet, and allows the user to abandon the wallet with its non-zero fees.

    The user will still owe a fee on the transferred balance in the new wallet, but this may be less than what they owe on the abandoned wallet.

    Relayers choose prices themselves in the price agreement phase of the match, so naturally they will choose fair market prices to avoid this. However, if a user queues up a "self match" manually (without going through the relayer) they may still exploit this.

Trusted Roles

  • Owner: The owner of the darkpool may pause and unpause the system, set the protocol fee and fee encryption key, and upgrade any contract in the system. [Source Code]

  • Relayer: A relayer manages user state -- shopping around orders and proving state transition predicates in zero-knowledge. The relayer should never be able to place orders, deposit/withdraw balances, etc without the user's authorization via their privately held keychain.

    The relayer is trusted to faithfully execute orders at the real time Binance midpoint. As such, the relayer selecting a malicious price is not classified as theft of funds.

    Note that while the relayer is trusted with price agreement, user orders have a worst_cast_price field that backstops the price that the relayer chooses.

Protocol Invariants

See the Smart Contract Invariants for a detailed discussion of the invariants in the system.

Miscellaneous

Employees of Renegade, and employees' family members are ineligible for bounties.