Dango

In the current version of our DEX smart contract, only the admin account is capable of creating new trading pairs. Therefore, you can assume the contract only interacts with tokens already examined and approved by the admin.

Dango's smart contract VM does not use ERC-20 tokens. Instead, all tokens are centrally managed by a single smart contract called the "bank". Each token is identified by a string denomination or "denom", and quantified by a 128-bit unsigned integer.

The DEX contract is intended to work with tokens with >= 0 and <=18 decimal places (ie, issues related to the token having >=0 and <=18 decimals can be considered valid and in scope) and prices as low as 0.00001 USD (an example of this would be the SHIB token).

In Dango's VM, there is a chain-level config that defines a single admin account called the "owner". Several functionalities in the DEX contracts can only be accessed by the owner. You can assume the owner is trusted.

Any component of the Dango chain that is out of the scope of this audit contest, can be assumed to work properly as intended.

Validators should be considered trusted and not act maliciously, as the protocol will have a centralised validator set.

No

No

Oracle prices are provided directly by the proposer of each block. The proposer would insert a transaction to the very beginning of the block, that invokes the oracle contract and feeds it the latest price data. However, this is out of scope for this audit contest.

An invariant that must always hold true, is that the DEX contract must have more assets than its liabilities. "Assets" means its token balances held in the bank contract. "Liabilities" is the sum of 1) the tokens contained in all open orders from users (excluding orders from the market making vault), and 2) the reserves of all market making vaults. "Token contained in an open order" means if the user is to cancel this order, the amount of token he will be refunded. In other words, if all trader immediately cancel all orders, and all liquidity providers immediately withdraw all liquidity, the contract should have enough balance to cover these requests.

This property should hold true for each token denom, not just the aggregate USD value of all tokens. In an ideal world, for each denom, the asset amount should equal exactly the liability denom; but in reality, the difference {asset - liability} should increase monotonically due to the accumulation of rounding errors, and should never decrease.

We have an fuzzy test in the dango-testing crate to demonstrate this property.

Design choices are documented in the "Implementation" section of this README file: https://github.com/left-curve/left-curve/blob/main/dango/dex/README.md#implementation

None

• https://x.com/larry0x/status/1947685791167353284
• https://github.com/left-curve/left-curve/blob/main/dango/dex/README.md

The following files are not in the scope, but may be useful for understanding the code:

• dango/dex/README.md (same as linked above): an overview of the DEX smart contract and explanation of some of our design choices.
• dango/testing/tests/dex*.rs: integration tests related to the DEX contract.

For this contest, you will review Dango's onchain order book exchange module, which has two unique features:

• the use of periodic auctions as the order matching algorithm, which deters toxic flow and MEV;
• the incorporation of market making vaults, which acts as backstop liquidity in the exchange, and provides a new yield opportunity for passive investors.

It's recommended to start from this README document: https://github.com/left-curve/left-curve/blob/main/dango/dex/README.md

This contest has custom Severity definitions:
High severity - Direct loss of funds without (extensive) limitations of external conditions. The loss of the affected party must be significant and the loss must be unrecoverable (ie, bridged out to other chains). Standard percentage and amount thresholds apply (>1% and 10+ USD loss of the affected party).

Medium severity:
Causes a loss of funds but requires certain external conditions or specific states, or a loss is highly constrained. The loss must be relevant to the affected party, unrecoverable loss (ie, lost tokens remain in the chain and can be recovered by the protocol in any way) >0.01% and 10+ USD of the affected party, or recoverable loss (ie, bridged out to other chains) >0.01% and 10+ USD, but <=1% are considered Medium

Breaks core contract functionality, rendering the contract useless or leading to loss of funds that's relevant to the affected party. Unrecoverable loss (ie, lost tokens remain in the chain and can be recovered by the protocol in any way >0.01% and 10+ USD of the affected party, or recoverable loss (ie, bridged out to other chains) >0.01% and 10+ USD, but <=1% are considered Medium

Issues that lead to DOS will not be considered High and can be Medium at max.

Issues with the root cause in out-of-scope dependencies will be deemed as out of scope and not valid.