Skip to content

Latest commit

 

History

History
148 lines (95 loc) · 6.44 KB

ERC-725.md

File metadata and controls

148 lines (95 loc) · 6.44 KB
Raw
eip title author discussions-to status type category created
725
Proxy Account
Fabian Vogelsteller (@frozeman), Tyler Yasaka (@tyleryasaka)
Draft
Standards Track
ERC
2017-10-02

Simple Summary

A standard interface for a simple proxy account.

Abstract

The following describes standard functions for a unique identifiable proxy account to be used by humans, groups, organisations, objects and machines. The proxy has 2 abilities: (1) it can execute arbitrary contract calls, and (2) it can hold arbitrary data through a generic key/value store. One of these keys should hold the owner of the contract. The owner may be an address or a key manager contract for more complex management logic. Most importantly, this contract should be the reference point for a long-lasting identifiable profiles.

Motivation

Standardizing a minimal interface for an proxy account allows third parties to interact with various proxy accounts contracts in a consistent manner. the benefit is a persistent account that is independed from single keys and can attach an arbitrary amount of information to verifiy, or enhance the accounts purpose.

Specification

Methods

getData

Returns the data at the specified key.

function getData(bytes32 _key) external view returns (bytes32 _value);

setData

Sets the data at a specific key.

Triggers Event: DataChanged

function setData(bytes32 _key, bytes32 _value) external;

execute

Executes an action on other contracts or a transfer of the EVM chains native cryptocurrency. MUST only be called by the current owner of the contract.

function execute(uint256 _operationType, address _to, uint256 _value, bytes _data) external;

The operationType should represent the assembly operation as follows:

  • 0 for call
  • 1 for delegatecall
  • 2 for create

Others may be added in the future. Inspired by ERC1077 and Gnosis

Events

DataChanged

MUST be triggered when setData was successfully called.

event DataChanged(bytes32 indexed key, bytes32 indexed value);

ContractCreated

MUST be triggered when execute creates a new contract using the _operationType 2.

event ContractCreated(address indexed contractAddress);

Ownership

key: 0x0000000000000000000000000000000000000000000000000000000000000000
value: left padded address, e.g. 0x000000000000000000000000de0B295669a9FD93d5F28D9Ec85E40f4cb697BAe

The proxy account contract should have exactly one owner. This owner should be the only msg.sender that is allowed to call execute or setData. The owner address sits at key 0x0000000000000000000000000000000000000000000000000000000000000000. The value of this key is the owner address left padded to 32bytes, like 0x000000000000000000000000de0B295669a9FD93d5F28D9Ec85E40f4cb697BAe. Transferring the ownership can be done by having the current owner call setData for key 0x00....

Data keys

Data keys, should be the keccak256 hash of a type name. Exception is key 0x00..., which must be the owner. If there is a need for numbering multiple versions of a key, bytes can be removed from the hash of the name, in order to make room for the number. This method would allow the contracts themselves to read the name.

Multiple keys of the same type

Multiple keys for the same key type must add a keyTypeName-1 at the end of the key type.

This would looks as follows for myNewKeyType:
version 0 myNewKeyType: 0xa94996022594f93c34a730df0ae89d1ecd69dff98c17d0387e69ce58346323a4
version 1 myNewKeyType-1: 0xb6dace1ed14874742c4d1b8cd9b270305176f769e0ae22118a02c2db4e620f29
version 2 myNewKeyType-2: 0x6cc96a01de588f4550e8c3a821aed065ae7897f8dfb61836c78c0389e499d9ed
...

Anyone that would like to standardize a new data key should make a pull request to update the table below.

Name Description Key value
owner The owner of the proxy account 0x0000000000000000000000000000000000000000000000000000000000000000 left padded owner address, e.g. 0x000000000000000000000000de0B295669a9FD93d5F28D9Ec85E40f4cb697BAe
735 The proxy accounts claim holder contract (per ERC735) 0xb0f23aea7d77ce19f9393243a7b50a3bcaac893c7d68a5a309dea7cacf035fd0 left padded address of the claim holder contract, e.g. 0x000000000000000000000000de0B295669a9FD93d5F28D9Ec85E40f4cb697BAe
780 The proxy accounts claim holder contract (per ERC735) 0xdaf52dba5981246bcf8fd7c6b00dce587fdcf5e2a95b281eea95dcd1376afdcd left padded address of the claim registry contract, e.g. 0x000000000000000000000000de0B295669a9FD93d5F28D9Ec85E40f4cb697BAe

Rationale

The purpose of an identity proxy is to allow an entity to exist as a first-class citizen in Ethereum, with the ability to execute arbitrary contract calls. At that same time the proxy account should be managed by an arbitrary simple or complex logic.

It also opens up the possibility of meta transactions, where a third party can send a transaction to the owner contract, that then verifies the execution permission based on a signed message.

It further allows any information to be attached to that proxy accounts which can be in the forms of claims via ERC735 or ERC780, or any arbitrary new systems and protocols.

This specification was chosen to allow the most flexibility and experimentation around verifiable manageable accounts.

Implementation

Solidity Interface

pragma solidity ^0.5.4;

interface ERC725 {
    event DataChanged(bytes32 indexed key, bytes32 indexed value);
    event ContractCreated(address indexed contractAddress);

    function getData(bytes32 _key) external view returns (bytes32 _value);
    function setData(bytes32 _key, bytes32 _value) external;
    function execute(uint256 _operationType, address _to, uint256 _value, bytes calldata _data) external;
}

Copyright

Copyright and related rights waived via CC0.