⚠️ This EIP is not recommended for general use or implementation as it is likely to change.

EIP-5247: Smart Proposal Source

An interface of "proposals" that is submitted to, recorded on and possibly executed and enforced onchain.

AuthorZainan Victor Zhou
TypeStandards Track
Requires 7


This EIP presents an interface for “smart proposals”: proposals that are submitted to, recorded on, and possibly executed on-chain. When a smart proposal is on-chain executable, it contains information on smart-contract calls, including addresses, ether values, call data, and other metadata information.


It is oftentimes necessary to separate the code that is to be executed from the actual execution of the code.

A typical use case for this EIP is in a Decentralized Autonomous Organization (DAO). A proposer will create a smart proposal and advocate for it. Members will then choose whether or not to endorse the proposal and vote accordingly (see EIP-1202). Finallym when consensus has been formed, the proposal is executed.

A second typical use-case is that one could have someone who they trust, such as a delegator, trustee, or an attorney-in-fact, or any bilateral collaboration format, where a smart proposal will be first composed, discussed, approved in some way, and then put into execution.

A third use-case is that a person could make an “offer” to a second person, potentially with conditions. The smart proposal can be presented as an offer and the second person can execute it if they choose to accept this proposal.


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.

interface IERC5247SmartProposal {
    event ProposalCreated(
        uint256 proposalId,
        string proposalUri,
        uint8[] optionIds,
        address proposer,
        address[][] targets,
        uint256[][] values,
        string[][] signatures,
        bytes[][] calldatas,
        uint256 startBlock,
        uint256 endBlock
    event ProposalExecuted(uint256 proposalId);
    // TODO: add Proposal Cancel/Edit/Withdraw Event and Functions?

    // TODO: decide whether we require generating ProposalId in the method or not?
    // TODO: if require generating ProposalId internally, can it be incremental hash-generated?
    // TODO: what if proposal need to demonstrate sufficient support? How to input quorum?
    function createProposal(
        uint256 proposalId,
        string calldata proposalUri,
        uint8[] calldata optionIds,
        address[] calldata targets,
        uint256[] calldata values,
        bytes[] calldata calldatas,
        uint256 startblock,
        uint256 endblock,
        bytes calldata extraParams
    ) external returns (uint256 registeredProposalId);

    // TODO: what's most proper way to update the voting period?
    // TODO: do we want to include cancel or withdraw?
    // TODO: what's the best way to include weight scheme?


  • Originally, this interface was part of part of EIP-1202. However, the proposal itself can potentially have many use cases outside of voting. It is possible that voting may not need to be upon a proposal in any particular format. Hence, we decide to decouple the voting interface and proposal interface.
  • Arrays were used for targets, values, calldatas instead of single variables, allowing a proposal to carry arbitrarily long multiple functional calls.
  • registeredProposalId is returned in createProposal so the standard can support implementation to decide their own format of proposal id.

Security Considerations

Needs discussion.

Copyright and related rights waived via CC0.


Please cite this document as:

Zainan Victor Zhou, "EIP-5247: Smart Proposal [DRAFT]," Ethereum Improvement Proposals, no. 5247, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5247.