XIP-7

Infinex Accounts

authorRay Zhu, Axe
typecore-upgrade
networkEthereum & Base
statusSuperseded
supersededbyXIP-47
created2023-12-13
updated2024-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:

  1. The introduction of deposit and trading accounts
  2. Relayer mechanism
  3. The security key permissions
  4. The mechanism for taking trading fees
  5. The mechanism for taking withdrawal fees
  6. 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 NameDescriptionRequired Permissions
Upgrade toUpgrades to a new implementationActive browser key
Add browser keyAdds an active browserRecovery key + active browser key
Add browser key with delayRecovers the account by adding a new browser key after a 7 day delay periodRecovery key
Remove browser keyRemoves an active browser key. Can be called on self in cases of compromised keys.Active Browser key
Activate browser keyActivates an inactive browser key and removes it from inactive browser keysActive browser key
Reject recover browser keyRemoves an inactive browser keyActive Browser key
Set MFA key status with MFA keyAdd or remove an mfa key. Can’t remove the last remaining keyMFA key + active browser key
Set MFA key status with recovery keyAdd or remove an mfa key. Can’t remove the last remaining keyRecovery key + active browser key
Set recovery key status with MFA keyAdd or remove a recovery key. Can’t remove the last remaining keyMFA key + active browser key
Set recovery key status with recovery keyAdd or remove a recovery key. Can’t remove the last remaining keyRecovery key + active browser key
Set emergency withdrawal addressAdds or removes a withdrawal address that can only be used to withdraw to itselfMFA key + active browser key
Set allowlisted withdrawal addressAdds or removes an address to the allow listMFA key + active browser key
Update circle bridge paramsPulls the latest information required for bridging via circle from the protocol config beaconActive browser key

Trading account

Function nameDescriptionRequired Permissions
Withdraw (Regular)Withdraws to the target addressMFA key + active browser key
Withdraw (Emergency)Withdraws to the msg sender if they are a valid emergency walletSignature from emergency wallet
Withdraw (Allowlisted)Withdraws to an existing allow listed addressActive Browser key
Withdraw to L1 (Regular)Withdraws to the target addressMFA key + active browser key
Withdraw to L1 (Emergency)Withdraws to the msg sender if they are a valid emergency walletSignature from emergency wallet
Withdraw funds (Allowlisted)Withdraws to an existing allow listed addressActive Browser key
Modify collateralAdd or remove margin to use in SynthetixActive or Inactive Browser key
Execute tradeExecute a perps trade in Synthetix V3Active 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.

MarketSNX maker fee (bps)SNX taker fee (bps)
BTC26
ETH26
ATOM48

Infinex can charge incremental fees on top of these. For example:

MarketMaker fee (bps)Taker fee (bps)Incremental maker feeIncremental taker feeTotal maker fee paid by userTotal taker fee paid by user
BTC26517 (2 + 5)7 (6 + 1)
ETH26517 (2 + 5)7 (6 + 1)
ATOM486210 (4 + 6)10 (8 + 2)

They need to be set out in a global fee structure that will look something like this:

MarketIncremental maker feeIncremental taker fee
BTC51
ETH51
ATOM62

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:

MarketIncremental maker feeIncremental taker fee
BTC00
ETH00
ATOM00

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.

ParameterDescriptionRequires user opt inRisks
latestAccountImplementationThe address of the latest implementation for the trading accountYesThis 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.
latestConfigBeaconThe address of the latest Infinex Protocol Config Beacon for the trading accountYesThis 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.
revenuePoolThe address where revenue from withdrawal fees and Synthetix referral fees are sent. This should be a multisig.NoIf 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.
tradingFeePoolThe address where trading fees are sent.NoIf this variable is changed, an attacker could set the trading fee pool address to their own and receive all Infinex trading fees.
defaultTradingFeesA 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.NoThis 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.
userSpecificTradingFeesA mapping of trading fees that are specific to individual users.NoThis 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.
userSpecificTradingFeesSetA mapping of boolean flags for whether a user has non-default trading fees.NoThis 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.
withdrawalFeeThe withdrawal fee amount processed on every withdrawal to both L1 and L2. This is given in 18 decimals.NoThere 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.
circleBridgeThe address of the circle bridge on this chain.YesThe 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.
circleBridgeDestinationDomainThe chain domain ID for each supported target chain for bridgingYesThis 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.
circleBridgeUSDCTokenAddressThe USDC address for the local chain.YesIf 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.

Contribute to Proposals on GitHub