Fennec Async Kit Specs

User Interaction Flow

Design Goals

  • Unburden Gnosis Safe users from the complexity of time sensitive operations, gas management, nonce management, and swap configurations- handle all of the following operations for users without sacrificing controls

  • Inherit and build on the security of the Gnosis Safe’s M-of-N threshold signatures assumption instead of compromising the contract with the module’s own security model.

  • The module stays non-custodial - the delegate address (the backend service agent executing the transaction) does not have the ability to execute transactions without the valid signatures.

  • Introduce a new model for asynchronous-atomic transactions instead of synchronous-sequential transactions

  • Give Gnosis Safe signers the ability to opt-out of any inflight transaction they have committed to

  • Orders are 100% private and will only be revealed atomically as the transaction gets settled

Smart Contracts

First implemented async kit module: AsyncSwap functionality supports:

  1. DCA orders: recurring transactions that can be submitted multiple times after a cool down period

  2. Limit orders: submit one-off inflight order that gets filled after a certain price level is met, ie. a take-profit and stop-loss.

a Gnosis SAFE can have arbitrary number of async orders running.

// Anatomy of a standard order for the first version of AsyncSwap implementation
struct Order {
        address inAddress; // input token
        address outAddress; // output token
        uint128 amount; // exact amount of input to a swap
        uint128 minReceive; // expected minimum amount of input from swap
        uint32 validFrom; // first block number which order is valid
        uint32 cooldown; // number of blocks before order can be called again
        uint32 deadline; // final block number which order is valid
        uint32 lastExecute; // last block the call is executed
        address delegateAddress; // address permitted to transact on behalf of Safe
 }

Backend Service

The backend service is implemented as Cloud Functions and managed database in GCP. The service is responsible for:

  • running series of cron-based Hasura Scheduled Trigger that checks the validity of each orders, ie. checking price parameters and valid range for the contract.

  • manage signatures data from the UI to be submitted with the transaction execution instead of utilizing Gnosis Safe official transaction service, this allows transaction concurrency

  • User Authentication via EIP-4361 Sign in With Ethereum

  • Multi-tennant application

  • API Gateway

Dapp UI

The design goal for the user interface is to optimize for experience of Gnosis SAFE signers, ensuring that they stay in the same user interface without the need to leave the application. The design is a mix of regular DEX interface, trading application and a brokerage service.

  • the UI implement hybrid user authentication, signers will be able to see Safe related settings right in the UI.

  • user is able to select assets, create orders and view existing orders

  • user is able to sign to reject or approve orders

Potential Future Development

  • More order types such as partial fill orders

  • A more generic order validation check to be ran against arbitrary external contract interactions with the exact same level of security guarantees. ie. support for multiple DEX supports

  • Event based trigger for order validity check instead of Cron schedulers

  • Calculate aggregate price metrics instead of utilizing spot price

  • Allow DAOs to schedule buy walls: multiple partial fill orders at varying prices for NFTs or ERC20s on DEXs

  • Integrate Flashbot or dark pool for MEV protection

PreviousContract AuditsNextBrand Guidelines & Marketing Assets

Last updated