Infinex Accounts
| author | Ray Zhu, Axe |
| type | core-upgrade |
| network | Ethereum & Base |
| status | Superseded |
| supersededby | XIP-47 |
| created | 2023-12-13 |
| updated | 2024-07-18 |
Proposal Summary
XIP-7 outlines the proposed implementation for Infinex accounts on L1 and L2. If passed, the code will be approved to deploy for the alpha launch.
Specification
Overview
XIP-7 proposes the following:
- The introduction of deposit and trading accounts
- Relayer mechanism
- The security key permissions
- The mechanism for taking trading fees
- The mechanism for taking withdrawal fees
- The global configuration beacon
Note: For the purposes of this XIP, L1 refers to Ethereum mainnet, and L2 refers to Base.
The specification for the upgradable proxy architecture will be detailed in a future XIP.
Rationale
Infinex aims to combine the ease of use of centralised exchanges with the composability and security of Defi. To achieve this, several features are required:
- Gasless transactions
- Security requirements for different types of transactions
- Ability to trade using Synthetix V3
- Extensibility to add new features
Since the smart accounts are intended to be deployed for the Infinex alpha launch, the scope has been kept narrow. Future upgrades to the smart accounts will require new XIPs to be created.
Technical Specification
Deposit and Trading accounts
There are two different types of on-chain accounts an Infinex user will need to use Infinex: deposit accounts and trading accounts. This proposal suggests deposit accounts are deployed on Ethereum, and trading accounts are deployed on Base.
The combination of a deposit account and a trading account controlled by a single user make up an Infinex Account.
Deposit accounts
On mainnet Ethereum, a user will have a deposit account through which they can deposit funds that will be bridged to their trading account on Base. The cross-chain bridging mechanism is outlined in XIP-4.
Trading accounts
On Base, users will have a trading account through which they can trade perpetual futures on Synthetix V3.
Account creation
Both deposit and trading accounts will share the same address on L1 and L2, giving the user a single, chain-agnostic address tied to their Infinex Account. Addresses for accounts are predicted using create2, and are only created once a user deposits funds into them.
When an account is created, it is initialised with three security keys: a browser key, an MFA key, and a recovery key. These keys can all be standard Ethereum wallets. The accounts will store the public key of the wallet. The private key is stored in the respective location mentioned in XIP-2, and will be used to sign transactions to execute account functions (like trading, and withdrawing)
Relayer mechanism
In order to allow transactions to be sent by the user without paying for gas, a relayer is used. The relayer passes transactions through to a ERC2771Forwarder contract which allows transactions to be made to the Infinex accounts. The relayer can be run by anyone and will pay for the gas of users transactions. To authenticate the user, the relayed messages must be signed by one or more of the users' keys, to be validated in their trading account contract.
The ERC2771Forwarder contract follows the ERC2771 standard which allows for third parties to act as relayers for transactions as well. This standard was adhered to closely to allow for third party relayers as a feature or by user choice.
Account actions and security requirements
The following tables specify the actions which require security keys in the Infinex accounts, and for exclusively the trading account.
Infinex Accounts
| Function Name | Description | Required Permissions |
|---|---|---|
| Upgrade to | Upgrades to a new implementation | Active browser key |
| Add browser key | Adds an active browser | Recovery key + active browser key |
| Add browser key with delay | Recovers the account by adding a new browser key after a 7 day delay period | Recovery key |
| Remove browser key | Removes an active browser key. Can be called on self in cases of compromised keys. | Active Browser key |
| Activate browser key | Activates an inactive browser key and removes it from inactive browser keys | Active browser key |
| Reject recover browser key | Removes an inactive browser key | Active Browser key |
| Set MFA key status with MFA key | Add or remove an mfa key. Can’t remove the last remaining key | MFA key + active browser key |
| Set MFA key status with recovery key | Add or remove an mfa key. Can’t remove the last remaining key | Recovery key + active browser key |
| Set recovery key status with MFA key | Add or remove a recovery key. Can’t remove the last remaining key | MFA key + active browser key |
| Set recovery key status with recovery key | Add or remove a recovery key. Can’t remove the last remaining key | Recovery key + active browser key |
| Set emergency withdrawal address | Adds or removes a withdrawal address that can only be used to withdraw to itself | MFA key + active browser key |
| Set allowlisted withdrawal address | Adds or removes an address to the allow list | MFA key + active browser key |
| Update circle bridge params | Pulls the latest information required for bridging via circle from the protocol config beacon | Active browser key |
Trading account
| Function name | Description | Required Permissions |
|---|---|---|
| Withdraw (Regular) | Withdraws to the target address | MFA key + active browser key |
| Withdraw (Emergency) | Withdraws to the msg sender if they are a valid emergency wallet | Signature from emergency wallet |
| Withdraw (Allowlisted) | Withdraws to an existing allow listed address | Active Browser key |
| Withdraw to L1 (Regular) | Withdraws to the target address | MFA key + active browser key |
| Withdraw to L1 (Emergency) | Withdraws to the msg sender if they are a valid emergency wallet | Signature from emergency wallet |
| Withdraw funds (Allowlisted) | Withdraws to an existing allow listed address | Active Browser key |
| Modify collateral | Add or remove margin to use in Synthetix | Active or Inactive Browser key |
| Execute trade | Execute a perps trade in Synthetix V3 | Active or Inactive Browser key |
As per XIP-2, the recoveryDelay period has been set to 7 days. This is hardcoded and requires an account upgrade to be changed. Active browser keys are all browser keys that are in use. Inactive browser keys are browser keys that are currently going through the recovery delay period. An inactive browser key shouldn’t be able to do anything besides trade and modify collateral.
Trading fees
The trading account provides the option to take trading fees on top of the fees that Synthetix V3 already takes. Fees will be controlled by the Infinex council multisig via a separate contract called InfinexProtocolConfigBeacon. Trading fees are immutably capped at 50 bps for both maker and taker fees so the InfinexProtocolConfigBeacon can't set the value above that. The details of how they're controlled is specified in Infinex Protocol Config Beacon. Here's an example of how the fees would be calculated.
Suppose that the Synthetix fee structure looks like this.
| Market | SNX maker fee (bps) | SNX taker fee (bps) |
|---|---|---|
| BTC | 2 | 6 |
| ETH | 2 | 6 |
| ATOM | 4 | 8 |
Infinex can charge incremental fees on top of these. For example:
| Market | Maker fee (bps) | Taker fee (bps) | Incremental maker fee | Incremental taker fee | Total maker fee paid by user | Total taker fee paid by user |
|---|---|---|---|---|---|---|
| BTC | 2 | 6 | 5 | 1 | 7 (2 + 5) | 7 (6 + 1) |
| ETH | 2 | 6 | 5 | 1 | 7 (2 + 5) | 7 (6 + 1) |
| ATOM | 4 | 8 | 6 | 2 | 10 (4 + 6) | 10 (8 + 2) |
They need to be set out in a global fee structure that will look something like this:
| Market | Incremental maker fee | Incremental taker fee |
|---|---|---|
| BTC | 5 | 1 |
| ETH | 5 | 1 |
| ATOM | 6 | 2 |
Non-default fees for VIP users
The Infinex council will have the ability to change this ‘feeType’ for certain VIP users to incentivise volume. For example:
| Market | Incremental maker fee | Incremental taker fee |
|---|---|---|
| BTC | 0 | 0 |
| ETH | 0 | 0 |
| ATOM | 0 | 0 |
Withdrawal fees
Fees are taken on all withdrawals to both L1 and L2 addresses. Withdrawals to an L2 address can only take place on the same chain. Fees are taken at the moment of withdrawal, resulting in the amount withdrawn equalling the amount minus the withdrawal fee. Withdrawal fees are a flat fee denominated in USD.
Withdrawal fees are immutably capped at a max of $50 in the trading account to prevent the council from increasing fees to an unreasonable amount and locking users funds.
Infinex Protocol Config Beacon
The InfinexProtocolConfigBeacon is a global variable setter that is controlled by the Infinex Council. Changing existing variables don't require the contract to be upgraded, and any upgrades will be automatically pulled by the Infinex accounts. Every variable can only be changed through a council vote, leaving users vulnerable to malicious upgrades by the council, or if a majority of the council's keys are compromised. For new variables to be added, a new contract must be deployed and the Infinex council must approve it. Additionally, each user will need to opt in to the new upgrade.
Changes to critical settings require user opt-in in addition to council approval. This ensures that users still have a safe guard from malicious changes. In this case, critical settings are those impacting withdrawals. Settings like trading fees can be controlled without an individual user's approval, but the option to withdraw is always available to the individual.
Here are the variables set by the Infinex Protocol Config Beacon along with the potential risks if they are changed maliciously: The exact values of each variable will be determined in a future XIP.
| Parameter | Description | Requires user opt in | Risks |
|---|---|---|---|
| latestAccountImplementation | The address of the latest implementation for the trading account | Yes | This variable is usually set to the latest version of the trading accounts in order to release new features to users. If set to an account implementation that has malicious code, it can extract funds from users. This requires users to sign a transaction with their browser key to upgrade to the malicious implementation. |
| latestConfigBeacon | The address of the latest Infinex Protocol Config Beacon for the trading account | Yes | This variable will be set to the latest version of the Infinex Protocol Config Beacon when one is made available. If this is changed to a malicious config beacon, any Infinex accounts that upgraded to it will be permanently lost. If an account is upgraded to a malicious beacon, all trades, and withdrawals can be frozen. |
| revenuePool | The address where revenue from withdrawal fees and Synthetix referral fees are sent. This should be a multisig. | No | If this variable is changed, an attacker could set the revenue pool address to their own and receive all non trading fee revenue from the protocol. |
| tradingFeePool | The address where trading fees are sent. | No | If this variable is changed, an attacker could set the trading fee pool address to their own and receive all Infinex trading fees. |
| defaultTradingFees | A mapping of trading fees that are standard across all users. It sets maker and taker fees for each synthetix market. Fees are measured in bps. | No | This could be changed to be extremely high but there is a maximum of 50 bps hard coded in the trading account on both maker and taker fees which can't be changed without the individual user opting in to that change. |
| userSpecificTradingFees | A mapping of trading fees that are specific to individual users. | No | This could be changed to be extremely high but there is a maximum of 50 bps hard coded in the trading account on both maker and taker fees which can't be changed without the individual user opting in to that change. |
| userSpecificTradingFeesSet | A mapping of boolean flags for whether a user has non-default trading fees. | No | This could be changed to be extremely high, making trades cost up to near infinitely more, effectively resulting in losing the total margin when placing a trade. |
| withdrawalFee | The withdrawal fee amount processed on every withdrawal to both L1 and L2. This is given in 18 decimals. | No | There is a max limit of $50 hard coded into the trading account so that is the max it could be set to. The council can make any changes to the withdrawal fee up until the cap. It would require the user to upgrade their account to an implementation that removes this hard cap in order to take exorbitant fees. |
| circleBridge | The address of the circle bridge on this chain. | Yes | The account contract approves spending by the circleBridge contract, if this is pointed to a malicious wallet or contract, it could steal user funds that are deposited, and steal user funds when a withdraw is attempted. |
| circleBridgeDestinationDomain | The chain domain ID for each supported target chain for bridging | Yes | This controls which target chains funds are redeemable on. If this is changed to an invalid domain, several things could happen depending on the value. Either withdrawals won't be able to processed, or funds will get sent to a different chain. If sent to an EVM chain, the user still has access to those funds but they'll just be on a different chain than intended e.g. Optimism instead of L1. If sent to a non-EVM chain, the withdrawal won't be processed. |
| circleBridgeUSDCTokenAddress | The USDC address for the local chain. | Yes | If this is changed to a different address, withdrawals to L1 can't be processed |
To summarise, the Infinex Protocol Config Beacon has access to sensitive variables which the council has control over. If the council approves changes to the beacon either by going rogue or through having their keys stolen, significant damage can be done to the Infinex protocol. Any new actions that take place after the config beacon has been taken over can result in the loss of some or all of a user's funds. It is fairly safe to assume that an attacker will be able to take all of a users' funds if they are able to control the config beacon and the user accepts the update. What is assured is that no funds can be stolen unless the user performs an action. They will always be able to withdraw the full amount of their funds (-$50) if malicious actions are taken by the council.
Copyright
Copyright and related rights waived via CC0.