Switchboard is an on-chain protocol to help facilitate best-execution trades. We define best-execution as the liquidity adjust arrival price of the submitted trade payload.
Payload Execution
Pre-trade Request: The client submits a request to the /trade/peek API Endpoint. Our backend then utilizes our routing solver to derive the best liquidity adjusted execution pathway. To execute the request we return a response to the client that contains a singable transaction payload consisting of orders that must be settled on chain.
Post-trade Execution: Payload returned by TinesV2 and sends it to the Ethereum Network. The protocol translates the payload into a set of 'chunks', that execute on the involved trading venues. The contracts execute transfers and the payload execution is finalized.
Think of 'chunks' as you would in a bin packing problem
A Ward is responsible for all implementation specific logic required by each venue.
All initiating functions must be handled and authorized from these modules. A Ward is a namespace for an Exchange Venue. Wards enable us to separate the logic specific to each venue without polluting the entire protocol with venue-specific implementation details.
This could range from depositing funds prior to initiating a trade to wrapping or unwrapping ether as required. It is a key requirement that we keep DEX logic separate from the primary contract in order to allow for the expansion of the platform.
| Venue | Ward | |--- |--- | | UniswapV02 | YE | | UniswapV03 | YES | | SushiswapV01 | VIA Router | | SushiswapX | N/A | | BalancerV01 | YES | | ZeroEx/0xV01 | YES | | ZeroEx/0xV03 | YES | | StableSwap/Curve | YES | | Bancor | N/A | | Zapper | N/A |
The SwitchBoard sequences each token trade: executing all orders using their respective Ward.
This contract is the entry point for external transactions and performs sanity checks on the payload Due to the differing requirements of executing trades at each DEX, we employ the use of separate Ward contracts.
Share this post on Twitter.