SIP-301: Accounts (V3)

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 delegate specific permissions for this account to other addresses.

Abstract

Account 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.

Motivation

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.

Specification

Overview

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.

Rationale

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.

Also, 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).

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 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;
}

The 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.

Fundamentally, 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.

The 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.

Test Cases

Relevant tests will be developed during implementation.

Configurable Values (Via SCCP)

N/A

Copyright

Copyright and related rights waived via CC0.