Whitepaper

CoinQuoter: Democratized market maker infrastructure for off-chain price creation combined with on-chain settlement

Kamil Chelstowski, Mikolaj Stasiak

CoinQuoter.com

May 21, 2022

Abstract

For blockchains to become a settlement layer of the world of various financial instruments, we need to find ways to design on-chain settled trading workflows that would be even more efficient than currently used solutions. On the professional OTC FX market usual bid-ask spread for 1 mln EUR/USD trade is around 0.001%. Our research of centralized and decentralized crypto infrastructure showed us that the design of popularized workflows does not allow for significant reduction of trading costs limiting adoption of on-chain settled trading.

To prepare for the next wave of blockchain adoption and significant decline in costs of on-chain settled trading, we designed CoinQuoter dApp that facilitates low-latency price creation and price aggregation infrastructure for peer-to-peer exchange of tokens on EVM blockchains. CoinQuoter is combining OTC trading with last look known mainly from the FX market with on-chain trade settlement where the smart contract is playing the role of Central Clearing Counterparty.

CoinQuoter copies OTC FX multi-dealer quote aggregation, pricing engine workflows, OTC last look standard, clearing house with a blockchain and pre-trade risk assessment with on-chain token balance check. To assure low-latency execution we also added an on-chain user session on the maker and taker side replicating a regular login process.

This combination is intended to serve as an alternative to the CLOB, AMM model popularized by Uniswap and OTC firm liquidity model popularized by 0x/1inch. Whitepaper briefly describes the inefficiencies related mainly to arbitrage activity in all 3 models mentioned above (AMM, firm liquidity and CLOB) and suggest a potential solution that is still not very popular in DeFI.

Taking example from tools used in OTC FX market and combining it with blockchain based a settlement layer can not only significantly improve token liquidity and decrease transactional costs for DeFI users, but also bring more attention of traditional finance that on one hand would be familiar with OTC workflow with last look and on the other see benefit from credit risk mitigation and more open access for all market participants thanks to blockchain settlement layer.

Shortcomings of popular token trading workflows

Below overview of popular trading workflows is mainly focused on presentation of problems that we intend to solve with the CoinQuoter project. We simplified a lot of concepts and one can argue that the below definitions are not precise or do not cover all cases. For that reason, readers that want to get a precise understanding of popular trading workflows should conduct their own research.

Central Limit Order Book (CLOB)

Order machine is taking place on one centralized server. CLOB is offering so-called firm liquidity, where active orders on the CLOB server are matched/executed without optionality. Due to the possibility of latency arbitrage between different CLOB platforms, servers of market makers are usually based in the same data center as CLOB and there is a constant fight between market participants to find the fastest route between different CLOB platforms with an active market of the same/linked instrument. In the case of cryptocurrencies, almost all popular centralized exchanges like Binance, Coinbase, Huobi are using this execution model.

CLOB is particularly demanding for market makers due to the latency war that is happening between exchanges where the same instrument is available for trading. If the price would change on one exchange to allow arbitrage on the other exchange, the fastest player would execute an arbitrage orders on both exchanges. This creates a situation, where market making is limited to the fastest players that are able to arbitrage between CLOB exchanges and withdraw their quotes fast enough to prevent somebody else from arbitraging them. All slower players that are willing to make markets using directional or neutral strategies are often losing money with their orders being executed mainly by low latency arbitraging bots and not by real market takers. We believe that this might significantly limit the depth of the book and move bigger liquidity away from exchange.

Automated Market Maker model

Automated market makers (AMMs) allow digital assets to be traded without permission and automatically by using on-chain liquidity pools instead of a traditional market of buyers and sellers. Price is influenced not by market makers, but by trades that are executed against the pool. For AMMs, arbitrage traders are financially incentivised to find assets that are trading at discounts in liquidity pools and buy them up until the asset’s price returns in line with its market price. Liquidity Providers that are contributing funds to the pool will incur losses when the price ratio of the pooled asset deviates from the price at which LP deposited funds. The higher the shift in price, the higher the loss incurred. In the case of AMM, Liquidity Provision is only profitable, when losses related to change in price ratio are smaller than fees earned from trades executed against the pool.

Profitability of Automated Market Maker strategies popular in Decentralized Finance is questionable [1]. The market volatility that is driving arbitrage volumes on AMM DEX’es is generating losses for market makers that often are greater than market maker fees generated from trading. It seems to be a very similar structure to market-making on CLOB exchanges where only highly capital and technically prepared participants are able to make a profit mainly thanks to different arbitrage strategies [2]. The cost of losses that are experienced by market makers are passed to market takers that need to pay much bigger fees to at least partially reward market makers for the risk that they are taking.

AMM works very well, when DEX is the main source of liquidity for a given token, but when there are multiple places, where a particular token is traded, the liquidity is fragmented and a bulk of volume is not coming from real market takers, but from arbitrage.

Firm OTC liquidity settled on-chain

Market maker provides a signed quote that can be used by market takers to settle the trade on the blockchain (idea was popularized by 0x, but now also used by other solutions like 1inch). On Etherum it is common to see quotes with 90-120 second validity time.

Consequently, spread between bid and ask price is dependent on market volatility during quote validity time. The more volatile the market, the wider spread should be quoted by market makers. Even if market makers can quote much narrower pricing, they are not, due to possibility of an arbitrage.

Firm quotes are also not allowing market makers to pass liquidity from one place to another without market risk. They are learning about the trade only when trade is settled on the blockchain, what usually happens many seconds after the trade.

Basic CoinQuoter workflows inspired by OTC FX

OTC FX benchmark

Smart Contracts acting as a settlement layer of finance are democratizing market access and solving a lot of critical issues in finance related to credit and settlement risk. They are giving a very big edge of DeFI, but what is missing is an efficient trading infrastructure that on a design layer will allow market participants to execute trades worth trillion of dollars with cost at least matching what they pay with traditional institutions. Current solutions (AMM or Firm OTC Liquidity) does not allow trading with 0.001% bid-ask spread due to its design limitation mentioned above.

To allow blockchain technology to gain significant market share in real world financial transactions, we need to build infrastructure and workflows that would make on-chain trading much more efficient than it currently is. Having this in mind we need to question current solutions available in DeFI (AMM/Firm OTC Liquidity) and focus on a new design that will inspire a new wave of innovation in Decentralized Finance.

Cryptocurrencies in their foundation are much more like FX than to Equity. They are traded all around the world without any attachment to a particular exchange or a region. In most cases, people are free to buy and sell them without any restrictions at the price they agree with each other. Due to latency between different data centers around the world it is common that there is a slightly different price on different continents.

For a long-term success of blockchain infrastructure, FX can be taken as a benchmark for the future of on-chain settled trading. Most of FX volumes are done between market-makers and market takers via Streaming or RFQ workflows that support last look. CLOB model never got significant traction due to very high risk of latency arbitrage. In the OTC FX market microsecond latency is not that important as in the case of Equity and Futures trading on CLOB.

It is perfectly normal to expect 250-700 ms response times when trading on multi dealer platforms. OTC FX is offering constant access to deep liquidity unseen Equity or Crypto markets with volume trades being almost 20 times bigger on a global scale (FX volume is estimated at around $5 Trillion per day and equity at roughly $200 billion per day).

90% of trades on the interbank market are done between market makers and market takers that have some sort of relationship with each other. Order Book-style trading is relatively limited because there is no physical way to know where the real market is in a particular millisecond, making CLOB pricing much wider than OTC pricing. Market Makers aggregate feeds from multiple sources and offer prices to the end customers. Thanks to Last Look Market Makers are able to check if the market price that they quoted has not changed to much. During the last look Market Makers can auto-hedge flow before giving final confirmation to the end customer. Thanks to this structure, bid-ask spread on the most traded FX pairs is < 0.001% for $1 million, 0.0025% (0.3 pip on EURUSD) and < 0.003% for 10 million of liquidity . To buy $5 million worth of ETH on Binance, one needs to pay a premium of around 0.23% from the mid-market price. FX liquidity offered by an average bank (that is just passing liquidity and not making markets) is 100 times more liquid than the biggest crypto exchange in the world.

To even get a wider perspective one can compare volumes and generated fees. On 22 of September 2021, the volume of the biggest Decentralized Exchange (DEX) Uniswap v3 was 1.9b USD with 3.2m fees paid to Liquidity Providers. This gives an average fee of 0.16%. Professional FX market maker: XTX was doing on average 200 billion USD a day in 2019 with revenue of 1.78m USD per day [3]. The average fee of XTX was 0.001%. Market Maker fees on FX market are almost 190 times smaller than the fee paid by Uniswap customers.

Taking all above into account, it is highly likely that in the future crypto volumes will move away from currently dominating equity like CLOB trading on centralized exchanges to FX like OTC last look workflow, because FX market has already found a proper workflow and could optimize all-in-all cost of buying and selling 1 mln EUR/USD to less than 20 USD.

CoinQuoter design

Crypto market is much more like FX than anything else. It is traded 24/5, on all continents with no central source of truth about current price on the market. Main characteristics of OTC FX that inspired CoinQuoter design:

1. FX is mostly traded OTC with relatively small share of CLOB’s (mainly due to possibility of latency arbitrage)

2. OTC Platforms are aggregating quotes coming from different market makers

3. Market Makers can quote different prices for different customer groups depending on arbitrary decision of market maker

4. Even big market takers are happy to live with 250ms last look window and 5-7% rejection ratio getting in return bid-ask spread on the most traded FX pairs below 0.003% for 10 million of liquidity

5. Market Makers can pre-hedge the flow before giving final confirmation to the client (market maker don’t need to take market risk and can act just as a broker)

6. Last look workflow prevents latency arbitrage, clients with toxic flow focused on latency arbitrage can get very sharp pricing for a moment, but will lose it very quickly,

7. Settlement risk is mitigated by a clearing house.

Main CoinQuoter design

1. copies OTC multi-dealer quote aggregation,

2. copies pricing engine workflows,

3. copies OTC last look standard,

4. replaces clearing house with a blockchain,

5. replaces pre-trade risk assessment with on-chain balance check,

6. compromises sub-millisecond latency achievable on top Crypto exchanges running CLOB model,

7. give last look protection for market makers,

8. allow almost risk-free liquidity brokerage (pass liquidity from one place to the other and make immediate risk fee profit with every trade),

9. democratize access to OTC market making thanks to public access to blockchains.

Off-chain price creation and price discover for P2P trading

When evaluating potential infrastructure needed for replication of OTC multi-dealer quote aggregation and pricing engine workflows in DeFI space the most important parameter was number of quotes per second on FX platforms that is a range of 300 000 for an mid sized FX platform (multiple /market data sources pairs/sizes /customer groups). If the fastest blockchains can process up to 4500 tps, even not taking blockchain costs into account, it is very clear that a big part of business logic needs to be off-chain.

By splitting on-chain settlement logic from off-chain pricing engine and price aggregation, CoinQuoter allowed much quicker development cycles for the most complex parts of the workflow, white maintaining a high level of stability and much slower development cycles for critical parts of the solution related to settlement.

First version of CoinQuoter off-chain pricing engine is to not only aggregating pricing feeds coming from professional market makers but also democratizing access to price creation software offering an out-of-the-box pricing engine allowing market makers to easily create its own pricing rules depending on different factors (ex. market volatility, account balance, price levels, customer group etc.)

On-chain settlement of every transaction is opening a new territory, where there can be hundreds if not thousands of market makers creating their own pricing and making them available in the central marketplace. Each of these makers can run different strategies, use different data sources and with help of CoinQuoter aggregation engine distribute them to the taker customers.

We see a very big potential in users with use of CoinQuoter engine to provide liquidity just on one side of the market with a goal of directional trading at a current price adjusted by market maker spread without arbitrage risks. This kind of liquidity would significantly increase depth of the market as a result of real market interest. We see this as a missing piece in the currently available workflow.

It is common to see OTC FX market makers quoting different prices for different groups of customers. It is up to the market maker to measure characteristics of client flow and decide what kind of pricing should be given to what customers. ex. Customers with big so-called “toxic” flow are usually given wider prices than customers that are executing full amounts without much impact on the market. On the other hand, it is also up to market takers to decide about the basket of market makers based on their historical performance. Even if trading on CoinQuoter can be anonymous, we see grate potential in scoring of market takers and market makers allowing for a lot of intelligence on both sides of the trade. Implementation of customer groups is foreseen in the future versions of CoinQuoter.

Last look and on-chain settlement done by market maker

In OTC trading, the market maker provides a quote rather than a firm price. After getting a quote, the client is sending an execution request to the liquidity provider. When a request to trade against the quoted price is received, the LP may hold the request for some time (last look) and then execute or reject the trade. During the last look window, the market maker can check if the pricing is still valid and can also auto-hedge the trade before giving final confirmation to the end client. Last look is necessary to protect liquidity providers in a fragmented and unregulated marketplace where there is no central exchange for a given instrument and risk of latency arbitrage is high [4].

We think that last look protection for market makers is needed to increase available liquidity. Last look will not only prevent latency arbitrage present on CLOB platforms, but also will allow capital reach entities to pass liquidity between platforms almost risk free.

Low latency execution request

Each OTC trading platform is very focused on ping times between the server and end client, to minimize rejection ratios. We found it impossible to assure low-latency execution with execution signatures generated by Metamask or a multi sign process.

To minimize the time between user requesting execution and market maker getting execution request, we decided to implement a session that in the first stage is saved directly on the blockchain.

Trade rejections and taker compensation

In OTC FX parties know each other and can turn off market makers that are abusing last look privilege. Wallet2wallet anonymous token exchange requires trusted party/parties that would supervise last look practice and prevent market makers from abusing last look privilege.

To simplify initial workflow, we decided to use CoinQuoter off-chain infrastructure as a trusted party. This decision was driven by the fact that CoinQuoter has all the data necessary to judge if execution request rejection performed by market makers is justified or not. CoinQuoter is also validating each individual execution request against rules setup by the market maker (ex. If market maker setup a slippage of 0.05%, all execution request above this steppage will be rejected without even passing it to the market maker), so if the latency between market maker and CoinQuoter server is smaller than 100 ms there is a fair amount of confidence that execution request should be accepted on the market maker side as well.

Currently market makers are required to put an initial deposit with a special smart contract. Prices of a market maker will not be shown to market takers, if platform defined threshold is not available. In case of unjustified rejection CoinQuoter will compensate market takers with funds coming from market makers. At the beginning the amount will be small to not discourage market makers from quoting on the platform. Due to the fact that this idea is unique, and we are missing real world data on market maker and market behavior, it is unclear how big a rejection compensation should be given to the taker, under what conditions and with how much dependence on previous performance of the market maker/market taker. The CoinQuoter team is committed to work with the community on this topic, when more data will become available. We are sure that an efficient way to manage last look practice will be found, will not discourage sound market makers and prevent bad actors. Taking OTC FX as a benchmark long term rejection ratio of a particular market-maker should be below 5%.

Leveraged trading with use of lending protocols

To enable capital efficiency for market makers, CoinQuoter smart contract responsible for trade settlement is giving the option for the market maker to use lending protocols like Aave or Compund to leverage the trade. This concept is taken also from the OTC FX market, where professional market players are able to leverage SPOT trading with SWAPs that are executed independently from SPOT trades. In the long run, we believe that the same can be implemented on the market taker side.

We see big value in the fact that SPOT trading is independent from trade financing. This is allowing margin in SPOT traders to use the same pull of SPOT liquidity.

CoinQuoter Components

Session

Session is a unique concept of a user session account that is saved on the blockchain on the Market Taker and Market Maker side. The session allows you to achieve low latency executions by storing a special key set (session account) in the browser or any other software that is responsible for trade execution. The session account has a validity time. You must restart your session if the expiration time has passed.

Every Market Maker should save his private session key, to not lose his session balance.

After the user session account is assigned to the account holding transaction nominal on the blockchain, private key stored in the browser or in some other execution engine has the right to:

• sign execution request in the name of Market Taker

• push transactions to the blockchain in the name of a Market Maker account.

This is an analogy to the regular centralized exchanges, banks, and Gmail accounts. In the case of these services, after login, we have access to certain functionality without the need of password re-entry (like executing trades on Binance or executing big FX trades on platforms like Bloomberg). User session account on the Maker and Taker side allows shortening the time between “Market Taker clicking the rate” to “Market Maker sending transaction to the blockchain for settlement” to milliseconds without a need to store private keys of the nominal holding accounts in the browser.

Maker front-end

Maker is an open-source platform created for Market Makers. A Maker's primary responsibility is to receive Market Takers orders and send them to the blockchain. Maker front-end is completely independent from Coin-Quoter backend server and can be changed according to the will of the Makers. This architecture is providing additional protection for market makers.

Rates streamed by Market Makers do not commit the Market Makers to execute a particular quote (not Firm Quotes). It is up to the Market Makers to decide if the Execution Request sent by Market Takers should be sent to the blockchain for settlement. Rejections are monitored by CoinQuoter server that in particular cases will issue last look fee for unjustified rejections. CoinQuoter workflow is allowing an almost risk-free position for auto-hedging of any incoming execution request on any platform. Auto-hedging can be performed between receiving an Execution Request from Market Taker and sending the transaction to the blockchain for settlement. If the hedge trade would not be possible at the given price, Market Maker can reject the execution request (last-look). Market Makers are paying gas for the trade. The cost associated with gas should be included in the price. Price without gas cost can be shown in a separate field on the client screen (particularly important in the case of small trades on expensive networks like Ethereum).

Market Maker should take care of the latency between the server that is streaming the price and the end client.

Market Maker has full control over its reputation. Constant trade rejections will cause reputation damage.

Order Execution

Maker panel must always be open, as it is responsible for executing orders. Leave it open on your server or computer. If you close your Maker panel, there will be no trading activity.

Maker's primary responsibility is to execute Market Takers orders and send them to the blockchain. The Maker must create a session that will push transactions to the blockchain in the name of his wallet account. The session allows you to achieve low latency executions. Maker panel that is pushing transactions to the blockchain is in your full control. You have open-source code, you can change it as you like. Current version of this panel is published on IPFS with ENS domain. Maker panel has implemented a double price check with Binance.com and Crypto.com for every single execution. This is done on top of validations that we do on CoinQuoter backend server. It slows down execution by around 500ms but allows us to sleep better. CoinQuoter is not able to do anything with the execution request. It can just validate it, but sending it to blockchain requires a Maker session private key or signature. Sending execution to blockchain is only in Maker’s hands.

Maker Safety

Maker core functionality is completely independent of our server. It provides an additional form of protection for Market Makers. There are also some safety settings like max gas fee, max slippage and your token list that you need to set in order to start executing trades. All of these security settings, as well as the separation of the Maker panel from the server, are designed to protect Market Makers in case of hacking our server, or its corruption.

The Market Maker always has the final decision whether to accept or decline the transaction.

Trade Requirements

To begin executing trades, you must first configure some fundamental settings on the maker's panel. These settings apply to the transaction fees, as well as your security.

Session Balance

The session account is pushing trades to the blockchain for settlement, so it should hold money that would cover gas costs. We deposit session balance in native token for a specific blockchain. It is essential to deposit the required amount of session balance to start executing orders.

Penalty Balance

The Market Maker has complete authority over his reputation. Consistent trade rejections will cause reputation damage. Every time the Market Maker rejects a transaction, we send compensation to the Market Taker. The reimbursement comes from your "Penalty Balance". So to start trading, you need to deposit some amount on your "Penalty balance" in case you reject incoming requests.

Fee Balance

Every transaction made on our platform has a specific fee that a Maker needs to pay. Fees will be charged from the fee balance account, so you must have funds in your account to begin trading.

Max Gas Fee

Max gas fee is a maximum amount that you're willing to pay for transaction gas in GWEI. Order requests that exceed the gas fee will not be sent to the blockchain for settlement. As a form of self-protection, you must specify the Max Gas Fee amount.

Max Slippage

Max slippage is a maximum percentage of slippage you're willing to accept. Slippage is a percentage value of the price fluctuation. It's the difference between the current price of an asset and a price at which the market taker made a transaction.

Max slippage is one of the security settings, which means it's superior to all slippage values for each pricing rule set on the Quoter panel.

Your Tokens

Your tokens are a list of crypto assets that you are willing to trade with. You have to add tokens from the available list in order to start trading. For every added token, you have to set your allowance. Allowance allows us to carry out a transaction of a certain amount of your tokens, which are associated with your address.

Taker front-end

Taker provides an easy way to buy or sell crypto assets at a specific price. Taker is an open-source platform created for Market Takers, and can be changed according to the will of the Takers. On Taker, users are getting current prices from Market Makers and trade tokens via sending execution requests to the Market Makers who provided those exact prices. Market Taker is sending the execution request to the Market Maker with validity time. Validity time should be dependent on the finality time of a given blockchain and the maximum value of last look time that the Market Taker would give to a particular Market Maker. To achieve low latency execution, Market Taker has a session key stored in the browser. Information about the session key is stored on the blockchain. The session key has validity time. The concept is taken from a regular authorization standard used by companies like Amazon, Google, and Facebook.

Order Request

The execution request sent to the maker is a data structure created off-chain (ex. in the browser) and signed according to EIP-712 by the valid session key.

Request message format

Name	Data Type	Description
type	Number	Order type. 0 - bid, 1 - ask
takerAmount	String	Has to be number with no decimals.
makerAmount	String	Has to be number with no decimals.
limitOrder	RFQOrder	Object created with "buildRFQOrder" method from limit order protocol library.
sessionKey	String	Session public key.
resultEIP712	resultEIP712	Object created with "buildRFQOrderTypedData" method from limit order protocol library.
limitOrderSignature	String	String created with "buildOrderSignature" method from limit order protocol library.
ruleId	Number	Rule id received from pricing stream.
orderGas	Object	Gas Fee information received from the pricing stream.

Quoter front-end

Quoter is a proprietary panel for Market Makers. Quoter panel allows Market Makers to create pricing rules and conditions for their activation. Moreover, on the Quoter panel, you can view the takers' exchange requests. The panel shows which pricing stream the requests belong to, what activation conditions were met at the time, and how the market looked before and after the transaction. The Quoter panel gives a general overview of your assets and the pricing streams that you broadcast to Market Takers. On the Quoter panel you can freely modify your price streams and the conditions for their activation or deactivation.

Quoter Authentication

Quoter panel access is restricted only to authenticated users. You can log into Quoter only from your maker panel. The only possibility that someone else might log into your quoter is if you lose your session private key.

CoinQuoter backend

CoinQuoter is a non-open-source pricing engine inspired by pricing engines used in FX. CoinQuoter pricing engine provides low latency aggregation and price creation based on rules with ability to use different pricing feeds. Pricing and execution requests on CoinQuoter can be integrated with FIX protocols. CoinQuoter validates each individual execution request against rules setup by Market Maker before passing the request to Maker for final decision whether to accept or decline the transaction (Last Look). Having all the needed information, CoinQuoter also acts as a trusted party and judges if the execution request rejection performed by Market Maker is justified or not.

CoinQuoter Workflow

Figure 1 presents the general workflow of the CoinQuoter ecosystem. Below the diagram you can see a simplified workflow description.

Simplified workflow description:

• Market makers need to have an active “session” that will allow them to push trades to the blockchain as fast as possible.

• Market makers are setting up an open-source Maker panel that will be responsible for final trade confirmation and will push trades for settlement to the blockchain.

• Market makers are setting up pricing rules on Quoter Panel or are integrating their own data sources.

• Quoter will select the best rates for the market takers.

• Market Taker needs to create a session as well, to assure that trade requests will be sent to the Market Maker just after an execution confirmation click.

• The execution request of market taker contains a signature to allow market maker to settle the trade on the blockchain.

• Quoter server is the validating execution request of Takers and sends it to the Market Makers.

• Open source Market maker panel makes a sanity check and sends it to the blockchain.

Smart Contracts

CoinQuoter Protocol for trade settlement

CoinQuoter Protocol is a permission less protocol to settle crypto trades between 2 counter-parties (Wallet2Wallet trading). The framework allows counter-parties to agree on the price off-chain in a low latency environment and settle the trade on-chain. Thanks to the Last Look workflow market makers have a chance to auto-hedge client flow on low latency centralised exchanges. This makes liquidity independent from TVL.

General workflow

• Market Maker is streaming prices to Market Taker using its own engine or CoinQuoter Pricing Engine

• Taker is sending Execution Request to Market Maker

• Maker Maker is sending trade to the blockchain for trade settlement

To allow low latency execution workflow between 2 parties without compromising security, we implemented an additional key set on the market taker and on the market maker side. Information about keys used for low latency workflows is saved on the blockchain.

Quoter Protocol implements a settlement layer for quotes sent from Market Maker to Market Taker. Market Makers are responsible for executing signed execution requests that they received from Market Takers.

On-chain Quoter Protocol does guarantee that each execution request signed by the Market Taker is only executed once and transfers are successfully executed for both sides of the trade: maker to taker, and taker to maker. Pre-trade validations of execution requests sent from market takers to market makers are expected to be performed off-chain. The core of Quoter Protocol is based on 1inch Limit Order Protocol and 1inch Limit Order Protocol util. 1inch Limit Order Protocol has been audited multiple times by respected auditors. Security Audits of 1inch Limit Order Protocol can be found on: https://github.com/1inch/1inch-audits/tree/master/Limit Order Protocol [5].

Comparison between 1inch Limit Order Protocol and Quoter Protocol:

1. Quoter Protocol is using just RFQ workflow of 1inch Limit Order Protocol. Limit Orders with complex predicate functionality have been deleted to avoid unnecessary complexity.

2. In RFQ workflow of 1inch Limit Order Protocol market makers were providing firm liquidity to market takers with defined validity time exposing themselves to the risk of arbitrage during the order validity period. This is causing that pricing provided by market makers was taking into account expected volatility when providing firm pricing to market takes. Quoter Protocol is switching the role of market taker with the role of the market maker. In Quoter Protocol market taker is sending execution requests to the market maker. In Quoter Protocol market maker has the right to accept or reject execution requests from market takers. Market taker is defining the time till when execution requests can be executed by the market maker. This change has not affected the core logic of the code, but to make clear on the Protocol level about our intention of the desired workflow, we decided to replace “maker” naming with “taker” and “taker” with “maker” in the original 1inch Limit Order Protocol and in 1inch Limit Order Protocol util.

3. The design of 1inch Limit Order Protocol is relying on signatures generated by market makers and market taker accounts that are holding transaction nominals. To allow low latency execution, Quoter Protocol is implementing a unique concept of user session account that is saved on the blockchain on the market taker and the market maker side. After user session account is assigned to the account holding transaction nominal on the blockchain, private key stored in the browser or in some other execution engine has the right to:

   • sign execution request in the name of market taker

   • push transaction to the blockchain in the name of market maker account.

This is an analogy to the regular centralized exchanges, banks, and Gmail account. In the case of these services, after login, we have access to certain functionality without the need of password reentrance (like executing trades on Binance or executing big FX trades on platforms like Bloomberg). User session account on the maker and taker side allows shortening the time between “market taker clicking the rate” to “market maker sending transaction to the blockchain for settlement” to milliseconds without a need to store private keys of the nominal holding accounts in the browser. The protocol also gives the possibility to the market taker to sign execution requests with the main account to avoid gas costs related to session creation on the blockchain, but this workflow is not recommended due to the higher risk of market movement during the execution request signature process. This will result in a much higher rejection ratio or a much wider price quoted to the users that are sending execution requests using outdated quotes.

1. Market Maker is able to settle the trade at a better rate than requested by the market taker.

2. Market Maker can leverage position using their own smart contract (ex. to connect Quoter with AAVE).

CoinQuoter last look protocol

CoinQuoter last look protocol is a permission less protocol to punish Market Makers for continuous unjustified trade rejections. In wallet-wallet anonymous trading, it’s required to have a trusted party/parties that would supervise last look practice and prevent Market Makers from abusing this privilege. CoinQuoter has all the data necessary to judge whether the execution request rejection performed by Market Maker is valid or not. In case of unjustified rejection, CoinQuoter will compensate Market Taker with funds coming from the Market Maker.

CoinQuoter last look protocol allows Makers Makers to put in an initial deposit with a special smart contract. Last look protocol is also responsible for compensating Market Takers for unjustified rejections.

General workflow

• Market Maker is required to put an initial deposit with a smart contract to his penalty balance.

• Market Taker is sending an Execution Request to Market Maker.

• Maker rejects the execution request.

• CoinQuoter judges that the execution request rejection was unjustified and done in bad faith.

• Market Taker is compensated with funds coming from Market Maker's penalty balance.

References

[1] https://reuptake.medium.com/liquidity-providing-in-uniswap-v3-3-c82fb9a5f545

[2] https://docs.flashbots.net/

[3] https://fxnewsgroup.com/forex-news/institutional/market-maker-xtx-markets-2019-revenue-up-339m/

[4] https://en.wikipedia.org/wiki/Last_look_(foreign_exchange)

[5] https://github.com/1inch/1inch-audits/tree/master/Limit Order Protocol

Disclaimer

This paper is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This paper reflects current opinions of the authors and is not made on behalf of FICC or its affiliates and does not necessarily reflect the opinions of FICC, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.