SIP-301: Accounts (V3)

NetworkEthereum & Optimism
ImplementorDaniel Beal (@dbeal-eth), Leonardo Massazza (@leomassazza), Alejandro Santander (@ajsantander)

Simple Summary

This SIP proposes the creation of staking accounts in Version 3 of the Synthetix protocol. Users can mint an NFT (which represents their account) and stake any of the accepted collateral types in the protocol.


Staking account tokens are transferrable ERC-721 tokens which are functionally similar to user accounts in traditional authentication and authorization systems. Governance determines the types of collateral that can be staked by the accounts.


Currently, stakers are unable to transfer their position in the Synthetix protocol between wallets without exiting the system and re-entering. This is a poor user experience and can be gas intensive. With account tokens, a user could simply transfer ownership between the two wallets, as they would any other NFT. By decoupling accounts and addresses, this pattern allows us to create clean abstractions for delegation and authorization functionality.

Also, the protocol currently accepts multiple types of collateral (SNX, ETH, and LUSD) but they are handled inconsistently. By building a flexible and unified system for adding and removing different types of collateral, the protocol can be simplified and more future-proof.



When someone begins staking in the Synthetix protocol, they will be minted an snxAccount token. All aspects of the protocol that would otherwise reference a staker by their address should instead reference an account ID. Account owners may also delegate specific permissions to additional addresses. All collateral staked in the system is associated with an account.


Representing stakers as tokens allows us to create a variety of abstractions related to ownership and permissions which significantly improve user experience. By implementing the ERC-721 standard, we can maximize composability with smart contracts and existing user interfaces. This could also allow for a secondary market to be created for account tokens, which may have interesting side effects.

Regarding collateral management, we plan to build the protocol such that governance could effectively recreate the configuration currently utilized by the protocol. For example, governance may specify that stakers may provide SNX, ETH, or LUSD. Future SIPs will outline the ability for governance to provide incentives to stakers of specific collateral types, such as voting power or increased rewards.

Technical Specification

Accounts will implement the ERC-721 standard as well as the following functions:

interface IAccount is IERC721 {
	function mint(uint requestedAccountId, address owner);
	function stake(uint accountId, address collateralType, uint amount);
	function unstake(uint accountId, address collateralType, uint amount);
	function hasRole(uint accountId, bytes32 role, address target) external view returns (bool);
	function grantRole(uint accountId, bytes32 role, address target) external;
	function revokeRole(uint accountId, bytes32 role, address target) external;
	function renounceRole(uint accountId, bytes32 role, address target) external;

All collateral will be held in the main proxy contract. Total value locked can be calculated by simply observing the value held by that contract.

For native ETH to become an accepted collateral type, we would technically approve wETH and have the user interface wrap it with a multicall before staking to provide a seamless user experience.

Additional functionality for accounts will be specified in future SIPs, such as assigning collateral to funds, collecting rewards, etc.

Test Cases

Relevant tests will be developed during implementation.

Configurable Values (Via SCCP)

Governance can add or remove accepted collateral types, each with the following configuration:

  • Token (address) - An ERC-20 contract that represents the collateral.
  • Price Feed (address) - A contract which provides the current value of this asset, denominated in USD.
  • Minimum C-Ratio (uint) - The minimum ratio that the value of this collateral type must maintain in relation to the value of the debt that it backs to avoid becoming subject to liquidation.
  • Target C-Ratio (uint) - The lowest C-Ratio that the protocol allows stakers to reach voluntarily with this collateral type (by minting sUSD, for example).
  • Disabled (bool) - Whether the protocol should accept any more collateral of this type.

Additional parameters will be specified (pertaining to leverage, voting power, etc.) in future SIPs.

Copyright and related rights waived via CC0.