Totle V2

Our API is getting an upgrade.

Set to be released this summer, V2 is built entirely from scratch using Typescript, and will make Totle’s system much more powerful, scalable, and flexible.

In case you’re new here, Totle lets you swap ERC20 tokens and make payments while automatically getting the best price from the leading DEXs. Our platform is integrated with 13 DEXs and supports 130+ ERC20 tokens. Users can trade with Totle on our dApp, API, or through one of our growing network of API partners.

Everything is a swap

There will be no more buys/sells. Swaps are simpler, and we are implementing clearer names to make sure we follow industry standards, such as maker & taker and source & destination assets. These swaps will allow users to swap different assets by source amount and destination amount.

Swaps will include one or more trades, consisting of a collection of main and backup orders.

Swaps will feature direct token trades, eliminating the need for an intermediate asset (previously ETH). This flexibility means more pairs, more liquidity (right now we filter out direct pairs that we do not support), and better rates for users.

Base Currencies

Although we are eliminating the need for an intermediate base pair, it does not mean we don’t need it entirely. We’ll be introducing new base currencies, such as WETH, DAI, MKR, or any other asset that could potentially improve trade rates. These settings can be modified in real time.

New base currencies bring huge potential in the form of new trading routes. Totle v2 will be better than the best token swap on a single DEX. Pairs that do not exist on any other singular DEX can be traded via Totle. This maximizes our ability to find the absolute best price.

Payments

We recently announced a payments prototype, which allows users to pay a 3rd party in their preferred ERC20 token (given Totle supports it), and the 3rd party/merchant can receive whichever ERC20 token they prefer (we anticipate DAI and ETH to be popular here).

Totle v2 takes this payment feature out of prototype and a step forward:

1. Users send in extra crypto and get change to overcome slippage and still benefit from pool exchanges and backup orders.
2. It is built into our primary contract so users don’t have to use proxy contracts.

Totle Strategies

A new concept we are introducing are Totle Strategies. These are the logic of selecting orders, both main and backup. We can have a number of different algorithms, such as:

1. Safe: target orders with long expiration, enough liquidity, and more.
2. Aggressive: target low expiration orders with a low price.
3. DEX Diversification: include a lot of different DEXs in the backup orders.
4. Safe Fallback: if you consider one DEX to be the safest or most successful, we will only fallback there.

We can mix and match these strategies. For example, one strategy for the main order and one strategy for the backup orders. Users can configure this in run-time selection.

Payload

Totle v2 will sign the payload with a private key, and this signature will be validated on the Primary Contract. The Primary Contract will discard any payloads that do not match that signature.

This allows our system to shift a lot of checks it is currently doing on-chain to the Primary Contract, resulting in lower gas fees and securing the payload against man-in-the-middle attacks. Once the payload leaves the contract, we can be sure that no one will be able to change that information in the payload. Information will still be transparent but unhackable.

User Wallet Address

The Primary Contract will do an additional check of the user’s wallet address to make sure that the wallet address parameter in the payload actually matches the transaction sender.

With the user’s wallet address, Totle v2 can construct complete transaction objects and not just return data. We are removing the hassle of having users build those objects themselves. Users can now simply take this object, sign it with their private key, and send it to our Primary Contract.

We’ll also be able to check for token approval to our Token Transfer Proxy contract. If some user approvals are missing, we can generate approval transactions and have the user batch sign them. It will be one seamless process of clicking through confirmations.

Expiration

The payload will have an expiration, and the Primary Contract will be discarding all expired payloads. This expiration will be defined in real time for each and every request by the Primary Contract, and it can be based on a different number of parameters: strategy based expiration, exchange based expiration (for example, Kyber and Bancor have higher expiration because they don’t have actual orders), or any other logic we wish to implement. This will improve the success rate and gracefully fail a transaction if the payload is expired, ultimately saving gas.

Fees

Our customized partner fees are implemented as affiliate contracts. When transactions are executed, the fee is sent in ETH to partners’ affiliate contracts. With Totle v2, partners can decide which ERC20 token they’d like to accumulate fees in.

Validations

We are including a large variety of new validations to make sure we process the request correctly and that we do not generate payloads that we know for sure will fail.

1. Input: we will check that the structure of the request is valid, that it contains all required values and parameters in the right format, that the addresses are real token address with valid ERC20 assets, and that they are using tokens tradable in our system.
2. Wallet: we will check that the address has sufficient ETH/ERC20 token balances and the allowances are set correctly.
3. Maker: we will check that they have enough assets to be taken and that allowances are set correctly.

API Keys

Every partner that goes through an on-boarding process will be assigned an API key, that will allow product access to things such as /swap, /pay, Totle Strategies, DEX data, and more.

Error Reporting

In an effort to improve the developer experience, we are changing how we handle errors in our Primary Contract response by generating developer friendly errors.

These errors will have clear error messages explicitly explaining what happened and why the request failed. It will also include instructions on how to solve errors and documentation references if applicable.

Why now?

The DEX landscape looked a lot different when we first launched a year ago, and the progress of the ecosystem has been amazing to witness. With these changes all around us, Totle needs to adapt and change too.

Totle v2 does so. This upgrade brings improved price savings and lower gas by using different base currencies and moving all transactions to a swap. There is increased flexibility by using Typescript, Totle Strategies, and introducing a fully fledged payment product. Validations will increase reliability of trades, and error reporting will increase usability.

Get Started

To start using Totle, sign up for API access here: Build with Totle

Follow us on Twitter, Facebook, Telegram, or Medium for the most up-to-date news on Totle. Or email us at hello@totle.com.