Floodgate

Reference illustration for ##What we learned

Interview with MetaverseExplorer

the link can be found here: https://www.youtube.com/watch?v=5P7uwr0o8j4&t=417s&ab_channel=MetaVerseExplorer

Inspiration

It is difficult for new token projects to find a platform for their tokens to be traded in a high liquidity environment. Centralized exchanges have a long processing time and high cost associated. Moreover, this process can take some time and it is not always guaranteed that a token will get listed unless the token can show high historical trading volume. Order book DEX could be an alternative to this but many order book lacks liquidity so orders do not get executed.

What it does

We are building and delivering 3 pieces of technology in parallel 1) Floodgate API specification in OpenAPI Specification (OAS) format that is sufficient to build trading bots that operate on top of our serum-based exchange, and will also feature a client development library in golang to make it easier / faster for others to build bots

2) Trading bot (sp1got) that will serve as a “counterparty of last resort” on our exchange, an example of how to build clients on top of the floodgate API, a starting point for others to clone and build their own bots; and

3)floodgate API server (hydra) that will actually implement/serve the floodgate API

How we built it

We are building the API server as well as a first client (the trading bot) in parallel. In other words, we are “dog fooding” our own API from day one allowing us to work out any kinks and improve the API usability greatly. Furthermore, we build these systems using different languages (TypeScript for the API server and golang for the trading bot) to ascertain interoperability across the API boundary.

Challenges we ran into

The major challenge we faced is that all API requests that move funds in some way (e.g. place / cancel order etc.) result in Solana transactions that must be signed by the private key of the wallet that a bot is using.

This would be easy to accomplish if the bots/clients were to actually construct these Solana transactions themselves. We deemed this too hard and too much of a barrier, however. Also, we wanted to present an API that is closer to something the bot devs would know from working with centralized exchanges.

In a nutshell, we were looking for a solution that would make it easy to build bots that consume the floodgate API whilst allowing the bots to hold on to their private keys.

Accomplishments that we're proud of

We are proud to offer an API that is very similar to what devs are used to when dealing with centralized exchanges and coming up with a good solution for the transaction signing challenge described above. Last but not least we are also very happy that we were able to find an elegant solution that did NOT require changes to either the serum-ts or the solana/web3.js library.

What we learned (See illustration in the second slide as reference):

We thus came up with the idea of a two-phase flow for these kinds of requests phase 1: the bot/client does a normal POST request e.g. to place an order which corresponds to step 1 in the “place order” sequence diagram below if the request is legitimate and checks all the boxes hydra will construct the corresponding Solana transaction (step 3) and return it as a blob to the client (step 5) phase 2: the bot/client signs the blob returned by hydra (step 7) and publishes the signature via a second POST request (on the /tx endpoint) in step 8 if the signature is good hydra will add it to the transaction and finally forward the latter to the Solana network (in step 10)

What's next for Floodgate

We may build another UI/UX on top of Serum to provide a unique trading experience. We would also look to channel more liquidity through introducing cross-chain liquidity borrowing/lending and to add more trading products and derivatives such as perpetual products