Infinity Architecture
Infinity is a Hybrid protocol which runs its order book and risk management off-chain, with settlement occurring on-chain (today, on Ethereum). While it's not possible to power Infinity entirely on-chain with all of our code available openly, we look forward to a day when we can. Prior to that day, we plan on being as transparent as appropriate, and look to the community to guide us in the ways that give them more comfort.
On-chain Settlement
The on-chain interaction with Infinity is largely similar to that of any other protocol. That is, you connect to us through smart contracts, lock proceeds within a smart contract, and then trade accordingly. Your account value increases (or decreases) directly in line with your trading gains (or losses). Broadly speaking, whenever your overall positions increase, the amount of tokens in your wallet increases and when your position decreases, the amount of tokens in your wallet decreases.
Infinity updates everyone's wallet accordingly every [ 1 ] hour, and it does so in a batch process to limit the underlying gas fees that any individual should have to pay. We do this using ERC1155 contracts instead of the ERC20 standard which is more gas-efficient.
If you put on new positions within [ 1 ] hour, you will not see this updated in your wallet until the next batch update when we update everyone's positions. If you would like to see an immediate reconciliation on-chain, you can always choose to trigger a manual update yourself (and pay the requisite gas fees).
You may view our smart contracts here [ link ] (coming soon)
ERC1155 vs ERC20 Contracts
Instead of updating and manipulating ERC20 contracts directly, we lock these tokens and create duplicates using the ERC1155 format. This affords us not only more flexibility in respect of minting fungible and non-fungible tokens, it enables us to perform batch updates and transfers in a more gas-efficient manner.
Current Accounts vs Trading Accounts
As a security measure, we have created a Current Account, which acts as a staging account for tokens going in and out of the protocol. For Tokens to be actively traded, they must be transferred from this Current Account into a Trading Account where trades can occur freely.
This two-step process is put in place to prevent gaming the system, or situations in which simultaneous, conflicting transactions are sent via both Offchain and Onchain methods. For example, if a user were to submit both a Withdrawal request and a Loan request at the same time, this two-step account ensures that these requests are processed sequentially, and not concurrently (which may result in a loss).
Off-chain Risk Management
The off-chain risk systems are your single-source of truth for your positions. This means that you can view your risk at any time through our website, or via our API. At the same rate, this enables you to effectively put tens, or hundreds of trades through per second while incurring only nominal gas fees.
While we've built our off-chain servers for both performance and redundancy, there exists an unlikely event that these servers might go offline (e.g. see here). At the same rate, there are also unforeseen outages on-chain (e.g. this chain). While we seek to limit downtime wherever it may occur, one cannot foresee unforeseen events.
Smart Escape
The batch updating of positions on-chain is effectively a delayed Mark-to-Market of your position. While the website and APIs show your exact position, there may be a lag or discrepancy between your positions off-chain, and your positions on-chain, depending on the frequency at which you trade and the movements in the market.
In the event that our off-chain AWS servers go offline for an extended period, we have built an escape into our smart contracts, so that we can override the off-chain servers, and release funds accordingly. This escape is multisig (multi-signature) controlled.
While the protocol, by design, has some degree of centralization risk, we look to mitigate any economic-related risks through the smart contract 'escape' so that the maximum loss (or potential gain) at any point in time would be the difference between what the off-chain risk engine sees, and your last update on-chain.
Last updated
