ERC-1425: Action Standard

[chaitanyapotti]

---

eip: 1425
title: Action Standard
author: Chaitanya Potti (@chaitanyapotti), Partha Bhattacharya (@pb25193)
type: Standards Track
category: ERC
status: Draft
created: 2018-09-17
requires: 165, 1261, 1417
discussions-to: #1425

Note to Readers

1. We have created a couple of implemetations of polls for varied use cases.
   Please refer to them here

Simple Summary

A standard interface for Action Contract.

Abstract

The following standard allows for the implementation of a standard API for interacting with a governance system comprising of entity contracts(EIP-1261) and polls(EIP-1417).
The entity allows for permissioning and maintaining citizenship, and the poll allows for collection of consensus. Both of these, together come together to create a system that can manage data for governance structures. However there is a need for a system which can execute certain decisions based on pre-decided criteria. It is not always enough to have consensus, if there is no underlying system which will obey that consensus. The following are some examples of such systems, and it is possible to come up with several others:

1. Consensus based refunds: In a DAICO(refer vitalik buterins article), once a certain quorum has been reached on the refund decision, an action contract can be used to execute the refund.
2. Fiscal policy: If a number of bodies are collectively designing and working on issuance policy and debt policy of a certain currency, action contracts will be useful in carrying out the decisions that are collectively made.
3. Democratic administratorship: If some entity(see EIP-1261) wishes to change their admin collectively, an action contract may be designed to read the consensus from a poll(see EIP-1417) and then update the admin
4. Futarchy implementation: In futarchy(https://www.wikiwand.com/en/Futarchy), typically it is difficult to bring to the blockchain, data about what actually happened outside the blockchain. If such data is put into a one-person-one-vote poll(see EIP-1417), then an action contract may be written to allow people to withdraw the proceeds of their reward.

The philosophy behind the deployment of actions is that since blockchains cannot fire off a transaction on their own, the results of polls will not get executed automatically. If the action trigger is left to the person in power, they may or may not execute it based on their personal interests. However if the action is open for all people to execute, while being conditioned upon the result of the poll, the action is executed if any of the allowed addresses calls the execute function.

Motivation

A standard interface allows any user,applications to work with any action contract on Ethereum. We provide for simple ERC-1425 smart contracts.
The motivation behind creating this standard is to allow for enforceability of governance with entities(see EIP-1261) and polls(see EIP-1417) without needing to add enforceability into the interface of those contracts itself. The separation of enforceablity from the above two standards allows for flexibility in the actions. One action can base itself upon the result of several criteria, rather than the result of operations on the data present in a single contract.
While the action contracts were created mainly as a tool for leveraging EIP 1261 and EIP 1417, there is no such restriction, action contracts are able to read balances of ERC20 contracts, ERC721 contracts, or any other publicly available data in the creation of the conditioning function. That being said, we are aware that this EIP might not find much usage other than whatever is coupled with EIP1261 and EIP1417 and we are open to suggestions for more use cases.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Every ERC-1425 compliant contract must implement the ERC1425 and ERC165 interfaces (subject to "caveats" below):

/// @title ERC-1425 Action Standard
/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1425.md
///  Note: the ERC-165 identifier for this interface is 0x19ff1a63.
interface IAction {

    /// @notice checks whether the action can be executed
    /// @dev perform checks and return an appropriate uint corresponding to the executable block
    /// @return the number corresponding to the executable block
    function canExecute() external view returns (uint);

    /// @notice executes the action
    /// @dev executes the action based on the result from `canExecute`
    function execute() external;
}

Caveats

The 0.4.24 Solidity interface grammar is not expressive enough to document the ERC-1417 standard. A contract which complies with ERC-1417 MUST also abide by the following:

• Solidity issue 3368: Fixes typo of = instead of == #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: payable, implicit nonpayable, view, and pure. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a payable function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.24 is that you can edit this interface to add stricter mutability before inheriting from your contract.
• Solidity issue Added EIP-2330: EXTSLOAD #2330: If a function is shown in this specification as external then a contract will be compliant if it uses public visibility. As a workaround for version 0.4.24, you can edit this interface to switch to public before inheriting from your contract.

If a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification.

Rationale

There are many potential uses of Ethereum smart contracts that execute certain tasks based on consensus and membership. Examples of existing or planned systems that use action contracts are Vault, a DAICO platform, and Polis, a micro-governance platform. Future uses include the implementation of direct democracy, treasury management and many more.
The action contract is kept as simple as it can be - it has only 2 main methods. One of these is the condition function, and the other one is the execute function.

• Condition Function: This function checks for some logic, and evaluates whether the criterion coded in the function is true or not. The function is hard coded, and takes in no arguments. It reads data in other smart contracts on the blockchain and then uses that data to give a true/false/uint output by evaluating the logical expression.

• Execution Function: This function performs a hardcoded set of actions based on the result of the condition function. By hardcoding these 2 functions in tandem, the action contract becomes a standard contract for ‘promise on the blockchain’. It is an immutable request that processes upon the fulfillment of a certain criterion.

The way the contract is described above is reminiscent of betting market contracts, except that the execution function allows for more flexibility. Action contracts in general would contain several other methods other than the above mentioned methods. This is because action contracts would typically have some additional role, depending on the context in which they are placed, for example an action contract could potentially be an ERC20 contract as well, that has certain special checks. However the 2 methods above are designed to leverage the automation of blockchain in tandem with governance outcomes that the Electus Protocol(EIP1261, EIP1417, and EIP1425) produces.

Privacy

Personal information: The standard does not put any personal information on to the blockchain, so there is no compromise of privacy in that respect.

Community Consensus

We have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein.

Test Cases

Action Standard includes test cases written using Truffle.

Implementations

Action Standard -- a reference implementation

• MIT licensed, so you can freely use it for your projects
• Includes test cases
• Also available as a npm package - npm i electusaction

References

Standards

• EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)
• EIP-165: Standard Interface Detection
• ERC-1261 MV Token Standard
• EIP-1417: Poll Standard(a.k.a. ERC-1417)
• RFC 2119 Key words for use in RFCs to Indicate Requirement Levels

Issues

1. The Original ERC-1425 Issue. ERC-1425: Action Standard #1425
2. Solidity Issue Added EIP-2330: EXTSLOAD #2330 -- Interface Functions are Axternal. Interface functions are external, or no interfaces solidity#2330
3. Solidity Issue 3368: Fixes typo of = instead of == #3412 -- Implement Interface: Allow Stricter Mutability. Inheritance: allow stricter mutability solidity#3412
4. Solidity Issue Micah zoltu patch  #3419 -- Interfaces Can't Inherit. Interfaces can't inherit solidity#3419

Discussions

1. ERC-1425 (announcement of first live discussion). ERC-1425: Action Standard #1425

Voting Implementations and Other Projects

• Action Implementations

Copyright

Copyright and related rights waived via CC0.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.