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 delegate specific permissions for this account to other addresses.
\nAccount tokens are transferrable ERC-721 tokens which are functionally similar to user accounts in traditional authentication and authorization systems. These accounts represent stakers and are not relevant to the traders interacting with markets powered by the protocol.
\nCurrently, 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.
\nWhen 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.
\nRepresenting 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.
\nAlso, by adding more robust delegation functionality, stakers can practice improved operational security. For example, a hardware wallet may own an account with permission for claiming rewards delegated to a software wallet. If the software wallet were compromised, the attacker would only be able to claim outstanding rewards for the account (and not, for example, unstake all of the account’s collateral).
\nAccounts will implement the ERC-721 standard as well as the following functions:
\ninterface IAccount is IERC721 {\n\tfunction mint(uint requestedAccountId, address owner);\n\tfunction hasRole(uint accountId, bytes32 role, address target) external view returns (bool);\n\tfunction grantRole(uint accountId, bytes32 role, address target) external;\n\tfunction revokeRole(uint accountId, bytes32 role, address target) external;\n\tfunction renounceRole(uint accountId, bytes32 role, address target) external;\n}\nThe roles that are supported by accounts will be specified as functionality is added. This will entail actions like staking, unstaking, minting, burning, claiming rewards, modifying others’ roles, etc.
\nFundamentally, the protocol associates all staked collateral with an account, so accounts will be specific to the network where staked collateral is held. In other words, we don't anticipate building functionality for transferring accounts tokens cross-chain. Any cross-chain functionality pertaining to accounts will need to specify relevant account IDs (in addition to the relevant chain IDs) where necessary.
\nThe governance module will need to include support for voters to be represented by account IDs rather than addresses (either in future iterations or with peripheral contracts). It will also need to confirm that any users attempting to vote has appropriate permissions in relation to the account ID that they specify.
\nRelevant tests will be developed during implementation.
\nN/A
\nCopyright and related rights waived via CC0.
"}},"pageContext":{"id":"ac240d45-8046-5422-9915-c48056c04af9","frontmatter__sip":301,"__params":{"frontmatter__sip":"301"}}},"staticQueryHashes":[]}