概括

Tokenlon是基于以太坊的去中心化交易所，实现了0x协议，提供链下订单簿，链上结算的功能；报价模型采用传统的柜台报价模式(RFQ/RFS)。

RFQ: 用户向Tokenlon server请求资产报价，Tokenlon向所有的做市场询问价格，并将集成后的最好报价返回给用户。
RFS:

柜台报价的模式与UniSwap模式的不同之处：当RFQ返回报价后，一旦用户确定该价格，则用户订单交易执行期间，订单的成交价格就为用户所看到的价格； UniSwap的显示价格，是流动性池的两种token的比值，在用户交易上链期间，流动性池的token数量很大可能会发生变化，且由于AMM的特性，用户自身的订单也会导致流动性池的token数量产生变化，存在价格滑点，所以，uniswap上看到的价格，大部分情况下并非用户订单成交的价格。

组件介绍

MMProxy(Market Maker Proxy Contract): 作为做市场的钱包合约，需要存储一定的金额；当做市商接受用户的报价时，去中心化交易所合约会自动从MMProxy合约转出用户需要的token，并将用户的token转给MMProxy 合约.

MMSK(SDK)：用于链接做市商与Tokenlon server，主要的功能是将做市商的报价转换为链上的订单，返回给用户(作为用户的对手单)。

Trading Engines: 由两部分组成，Price engines(价格引擎)和 Hedging system(风控引擎)，由做市场开发，链接至MMSK.

交易模型

Tokenlon 采用链外报价、线上结算模型；用户可以基于实时的链外报价数据流，选择最近的价格作为订单成交价；用户发送订单交易至以太坊，链上合约处理该笔订单交易，在做市商与用户的订单之间做撮合，完成这笔订单。

整体结构

Tokenlon 协议由三部分组成：TokenlonExchange(TE), MarketMakerProxy(MMProxy) and UserProxy(UProxy)

TE: 作为协议的入口，用来处理订单交易.
MMProxy: 做市商的钱包，存储一定的资金，以便TE和0x协议的操作.
UProxy: 用户的代理合约，感觉类似于UniSwap中的Router合约，approve一定数量的token给它，然后在随后的交易中，用户转出用户的token.

流程如下：用户发送签名后的订单至TE合约，合约校验后，订单被发送至0x交易所，在0x交易所验证订单签名和参与方的可用余额后，使用(0xERC20Proxy)在UProxy与MMProxy合约之间转换此次交易的订单token。

MMProxy合约有三种角色：owner、operator、signer.

owner: 拥有最高权限，可以设置operator
operator: 拥有合约操作的基本权限，可以设置signer，approve一定数量的token给其他合约，提取合约中的资金等操作
signer: 拥有合约的订单签名权利；0x交易所调用合约的isValidSignature来验证做市商订单是由signer签名的.

做市商订单的生成

由于0x协议是基于订单簿的协议，所以，链上订单的成交，一定是两个对手单的成交。意味着：做市商的报价会被MMSK合约生成对手单，与用户的订单进行成交，做市商的订单由 SIGNER地址签名，来保证做市商订单的有效性；做市商每次报价都会返回一个可以成交的数量范围(由minAmount、maxAmount表示)，无论此次报价的结果是什么，是否可以交易，每次做市商返回的结果，都会包含这两个数量参数；用户的订单数量必须在做市商要求的范围内，否则，无法成交。

用户确认接收做市商的订单报价，然后用自己的地址签名用户的订单，发送至TE合约，最后被TE发送至0x交易所(感觉这里可能是链下的，导致订单交易并不会立即完成)。

0x交易所调用Uproxy和MMProxy合约的isValidSignatrue方法，来分别验证两笔订单的签名有效性。

+-------------------------------------------+
|                                           |
|                          |--> Uproxy      |   
|   TE --> 0xERC20Proxy ----                |
|                          |--> MMProxy     |
|                                           |
+-------------------------------------------+