v0.3.1

Aori v0.3.1

Read The Code:

Contracts:

Aori.sol
AoriUtils.sol

Interfaces:

IAori.sol

Audits:

Aori v0.3.1 Zellic Audit

Changelog

1. Native Token Support

The depositNative function has been added to allow users to deposit to their locked balance. Fills are handled the same as other swap flows, and the accounting is effectively unchanged, treating 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE as the native token representative address.

In AoriUtils.sol the NativeTokenUtils library has been added to abstract conditions for handling of transfers and balance change observations for cases of native token swaps.

This feature implementation makes up the majority of the diff between versions and can be seen in this commit.

2. Withdraw Amount Input Specification

In the withdraw function, added the ability for the caller to specify an amount to be withdrawn. With the sentinel value of 0 allowing the caller to specify a withdraw of the full balance.

function withdraw(address token, uint256 amount) external nonReentrant whenNotPaused {
    address holder = msg.sender;
    uint256 unlockedBalance = balances[holder][token].unlocked;
    require(unlockedBalance > 0, "Non-zero balance required");
    
    if (amount == 0) {
        amount = unlockedBalance;
    } else {
        require(unlockedBalance >= amount, "Insufficient unlocked balance");
    }
    
    IERC20(token).safeTransfer(holder, amount);
    balances[holder][token].unlocked = uint128(unlockedBalance - amount);
    emit Withdraw(holder, token, amount);
}

3. Cancellation Changes

• Removed source chain cancellations for cross-chain orders, forcing all standard cancellation flows go through the destination chain to confirm the order has not been filled, mitigating any risk of the aforementioned race condition.
• Internal _cancel function now transfers tokens directly to user from balance, rather than forcing them to withdraw.
• Permitted recipients to be able to cancel cross-chain orders from the destination chain: Considering cases in which a cross-chain swap is being performed by a single user, from one address on the source chain (offerer) to a different address of theirs on the destination chain (recipient)

4. Safer Accounting for Emergency Functions

• Added additional functionality to emergencyWithdraw which withdraws tokens from a specified addresses locked or unlocked balance to ensure that in the event of an emergency withdraw needs to be processed, it doesn't break the state of accounting, or create an inconsistency in memory held balances vs. actual contract balances.
• Since now all cancellations for cross-chain orders (users and solvers) go through destination chain cancel() function, i’ve added emergencyCancel(bytes32 orderId, address recipient) as an owner-only emergency function to handle stuck orders when normal cancellation flows fail or are unavailable.

Audit Remediations.

See v0.3.1 Audit Report