Why we are building Atlas

Blockchains are governed by cause and effect. Their state only changes when something acts upon them to change it. This cause is usually a transaction.

This means if something changes and we want to represent that in a blockchains state, we’re going to need a transaction. For example a user could decide they want to exchange one of their tokens for another, or the price of a token on another platform could change.

These state changes have consequences. If a user interacts with a liquidity pool to exchange some of their tokens for another token, then afterwards the relative balance between the tokens in that pool will have changed, changing the swap rate for the next transaction When these changes are favorable there will be fierce competition between traders to be the next transaction in the block, allowing them to capture the opportunity created by the previous transaction. This form of trading is known as MEV trading (for Maximal Extractible Value), and we call this type of trader a searcher.

This means that whoever decides in what order transactions are executed is able to arrange them in a way that allows them to make a profit, for example by selling the slot after a users swap transaction to the highest bidder. Typically, it is the block producer who makes this ordering decision.

However it is users and protocols that generate these trading opportunities, and today they have no easy way to capture the value they leak to the rest of the transaction supply chain.

Atlas is a framework to enable protocols to keep this value they create within their ecosystem. It works by allowing protocols to auction off the right to execute a transaction immediately after a user’s, and then bundling these two transactions together into a single atomic transaction.

For existing protocols that weren’t designed with MEV resistance in mind, Atlas is an easy way for them to retain as much of the value as they generate as possible. Proceeds from these auctions could be used to buy and burn a governance token, give rebates to users or be redistributed to liquidity providers who are suffering from impermanent loss.

For new protocols a popular approach has become to allow a user to specify the outcome they are trying to achieve, rather than exactly how they want to achieve it. This is the difference between saying “I want to swap token A for token B using this liquidity pool” and “I want to swap token A for as much token B as possible, and I don’t care where token B comes from”. These are known as intents, and traders compete for the right to be the counterparty to a particular user's intent, and we call this type of trader a solver. Under this model solvers compete not based on how much value they can extract from a user's transaction, but instead on who can best meet the user's desired outcome. Solvers are incentivized to return as much value to the user as possible to win the opportunity, minimizing any value leaking in the first place.

Taken a step further, Atlas has been designed to be used as a general purpose matching engine between two counterparties. For protocols considering an intents based approach to satisfying their users needs, Atlas takes care of most of the undifferentiated heavy lifting of matching counterparties and ensuring they do what they say they will, leaving you to focus on what makes your app unique.

Follow us on X to keep up to date as we get ready to launch. If you're a DApp, protocol or searcher interested in being a launch partner, please get in touch.