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:

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

File	SLOC	Purpose
circuit-types/src/merkle.rs	38	Merkle tree circuit types
circuit-types/src/order.rs	193	User order circuit types
circuit-types/src/srs.rs	267	The structured reference string used in our PlonK setup
circuit-types/src/transfers.rs	81	The transfer circuit type for deposits/withdrawals
circuit-types/src/lib.rs	463	Circuit type definitions
circuit-types/src/note.rs	72	The note type, used to pay fees out of a balance
circuit-types/src/fixed_point.rs	841	A circuit type for fixed point representation in finite fields
circuit-types/src/balance.rs	87	User balance circuit types
circuit-types/src/match.rs	106	The match tuple circuit types -- the result of a match
circuit-types/src/wallet.rs	152	The user's wallet circuit type
circuit-types/src/errors.rs	77	Errors for circuit types
circuit-types/src/elgamal.rs	253	ElGamal encryption types
circuit-types/src/keychain.rs	396	User keychain circuit types
circuit-types/src/traits.rs	1132	Traits for interacting with circuit types
circuits/src/zk_circuits/valid_fee_redemption.rs	826	The circuit for valid fee redemption
circuits/src/zk_circuits/valid_commitments.rs	1007	The circuit for valid commitments
circuits/src/zk_circuits/valid_wallet_update.rs	1445	The circuit for valid wallet update
circuits/src/zk_circuits/valid_reblind.rs	628	The circuit for valid reblind
circuits/src/zk_circuits/valid_wallet_create.rs	299	The circuit for valid wallet create
circuits/src/zk_circuits/proof_linking.rs	753	Proof linking implementation
circuits/src/zk_circuits/valid_offline_fee_settlement.rs	828	The circuit for valid offline fee settlement
circuits/src/zk_circuits/mod.rs	391	Module definitions for circuits
circuits/src/zk_circuits/valid_match_settle/multi_prover.rs	479	The multi-prover circuit for valid match settlement
circuits/src/zk_circuits/valid_match_settle/single_prover.rs	456	The single-prover circuit for valid match settlement
circuits/src/zk_circuits/valid_match_settle/mod.rs	912	Module definitions for match settlement circuits
circuits/src/zk_circuits/valid_relayer_fee_settlement.rs	1085	The circuit for validating relayer fee settlement
circuits/src/zk_gadgets/merkle.rs	338	Gadgets for Merkle tree operations
circuits/src/zk_gadgets/arithmetic.rs	167	Gadgets for arithmetic operations
circuits/src/zk_gadgets/wallet_operations.rs	530	Gadgets for wallet operations
circuits/src/zk_gadgets/bits.rs	347	Gadgets for bit operations
circuits/src/zk_gadgets/note.rs	79	Gadgets for note operations
circuits/src/zk_gadgets/fixed_point.rs	298	Gadgets for fixed-point arithmetic
circuits/src/zk_gadgets/mod.rs	18	Module definitions for zk gadgets
circuits/src/zk_gadgets/comparators.rs	650	Gadgets for boolean comparison operations
circuits/src/zk_gadgets/select.rs	132	Gadgets for selection operations
circuits/src/zk_gadgets/elgamal.rs	197	Gadgets for ElGamal encryption operations
circuits/src/zk_gadgets/poseidon.rs	384	Gadgets for Poseidon hash function operations
workers/api-server/src/websocket/price_report.rs	114	Handles websocket communication for price reporting
workers/api-server/src/websocket/handler.rs	89	Main websocket message handler
workers/api-server/src/websocket/task.rs	123	Manages websocket messages for relayer tasks
workers/api-server/src/websocket/wallet.rs	74	Handles wallet-related websocket operations
workers/api-server/src/websocket/order_status.rs	64	Manages order status updates via websocket
workers/api-server/src/auth/admin_auth.rs	126	Implements authentication for admin users
workers/api-server/src/auth/helpers.rs	49	Helper functions for authentication
workers/api-server/src/auth/mod.rs	84	Module definitions for authentication
workers/api-server/src/auth/wallet_auth.rs	134	Implements authentication for wallet users
workers/api-server/src/error.rs	72	Defines error types and handling for the API server
workers/api-server/src/lib.rs	20	Main library file for the API server
workers/api-server/src/worker.rs	144	The main event loop for the API server
workers/api-server/src/compliance/client.rs	46	Compliance client for the API server
workers/api-server/src/compliance/mod.rs	5	Module definitions for compliance-related functionality
workers/api-server/src/websocket.rs	404	Main websocket implementation and routing
workers/api-server/src/http/price_report.rs	63	Handles HTTP routes for price reporting
workers/api-server/src/http/task.rs	156	Manages HTTP routes for relayer tasks
workers/api-server/src/http/wallet.rs	957	Implements HTTP routes for wallet state
workers/api-server/src/http/network.rs	148	Handles HTTP routes for p2p network operations
workers/api-server/src/http/order_book.rs	97	Manages HTTP routes for network order book
workers/api-server/src/http/admin.rs	475	Implements HTTP routes for admin operations
workers/api-server/src/router.rs	381	Main router for HTTP and websocket routes
workers/api-server/src/http.rs	530	Main HTTP implementation and routing
Total	20762

Smart Contracts

Sources found here: Github

File	SLOC	Purpose
contracts-common/src/types.rs	522	Types for smart contracts
contracts-common/src/constants.rs	119	Constants used in smart contracts
contracts-common/src/solidity.rs	89	Solidity type definitions
contracts-common/src/lib.rs	14	Library file
contracts-common/src/serde_def_types.rs	166	Serde foreign trait implementations
contracts-common/src/backends.rs	71	Arithmetic and hashing backends
contracts-common/src/custom_serde.rs	511	Custom serialization and deserialization
contracts-core/src/crypto/mod.rs	4	Module file
contracts-core/src/crypto/poseidon.rs	10	Shim code for Poseidon hash function
contracts-core/src/crypto/ecdsa.rs	94	ECDSA signature verification and related functions
contracts-core/src/lib.rs	13	Main library file for contracts-core
contracts-core/src/transcript/mod.rs	290	Implementation of Fiat-Shamir transformation and transcript
contracts-core/src/verifier/mod.rs	1197	Main implementation of PlonK verification
contracts-core/src/verifier/errors.rs	37	Error types and handling for the verifier module
contracts-stylus/src/contracts/merkle.rs	353	Implements Merkle tree operations for the darkpool
contracts-stylus/src/contracts/transfer_executor.rs	152	Handles token transfer execution in the darkpool
contracts-stylus/src/contracts/vkeys.rs	55	Manages verification keys for PlonK proofs
contracts-stylus/src/contracts/darkpool_core.rs	790	Core functionality of the darkpool contract
contracts-stylus/src/contracts/mod.rs	28	Module definitions for darkpool contracts
contracts-stylus/src/contracts/verifier.rs	46	Implements PlonK proof verification
contracts-stylus/src/contracts/darkpool.rs	599	Main darkpool contract implementation
contracts-stylus/src/lib.rs	17	Library file for the darkpool project
contracts-stylus/src/utils/constants.rs	539	Constants used across the darkpool contracts
contracts-stylus/src/utils/solidity.rs	76	Solidity type definitions
contracts-stylus/src/utils/helpers.rs	254	Helper functions for the darkpool contracts
contracts-stylus/src/utils/mod.rs	7	Module definitions for utility functions
contracts-stylus/src/utils/backends.rs	156	Arithmetic and hashing backends
Total	6209

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.