HomeEIPs
EIPsERC-5485
ERC-5485

Legitimacy, Jurisdiction and Sovereignty

An interface for identifying the legitimacy, jurisdiction and sovereignty.
StagnantStandards Track: ERC
Created: 2022-08-17
Requires: EIP-165, EIP-5247
Zainan Victor Zhou (@xinbenlv)
DiscussionsOriginal linkEdit
1 min read

ERC-5485 is a proposed standard for smart contracts to declare their legitimacy lineage, jurisdiction they observe, and sovereignty if they choose to not fall onto any jurisdiction. This standard aims to support better integration with today's legal and regulative scenarios by allowing a regulative body to allow or deny interoperability with smart contracts. It also allows DAOs to declare "self-sovereignty" by announcing via this interface that they do not assert legitimacy from any source other than themselves. The interface supports both cases, providing a way to allow smart contracts to determine if they want to allow/prohibit interaction based on sovereignty. For example, a country might want to require any digital money service's all smart contracts to observe their ERC-5485 jurisdiction before they are allowed to operate money in their (real world) legal jurisdiction. Overall, ERC-5485 provides a way for compliant smart contracts to identify their legitimacy, jurisdiction, and sovereignty relationship, which can help with regulatory compliance and interoperability.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

Provide a way for compliant smart contracts to declare their legitimacy lineage, jurisdiction they observe, and sovereignty if they choose to not fall onto any jurisdiction.

Motivation

Today, smart contracts have no standard way to specify their legitimacy lineage, jurisdiction, or sovereignty relationship. The introduction of such a standard, supports better integration with today's legal and regulative scenarios:

  1. it supports a regulative body to allow or deny interoperability with smart contracts.
  2. it also allows DAOs to clearly declare "self-sovereignty" by announcing via this interface by saying they do not assert legitimacy from any source other than themselves.

A real-world example is that ContractA represents an A company registered in a country, ContractB represents a The Secretary of State of the country, and ContractC represents the Supreme Court of the Country.

Another real example is a contract that declares "self-sovereignty" that doesn't follow any jurisdiction.

This interface supports both cases, providing a way to allow smart contracts to determine if they want to allow/prohibit interaction based on sovereignty.

For example, a country might want to require any digital money service's all smart contracts to observe their ERC-5485 jurisdiction before they are allowed to operate money in their (real world) legal jurisdiction.

Another real world use-case is that in some jurisdiction e.g. in United States, if an token issuer choose to issue a token, they can try to petition SEC to recognize their token as registered security, if approved, will gain legitimacy from SEC. Should they choose to petition Commodity Futures Trading Commission (CFTC) to recognize them as a commodity, if approved, will gain legitimacy from CFTC.

On the other hand, a DAO with a strong decentralized ideology might choose to only inter-operate with EOA or "self-sovereign" smart contracts to avoid being affected by any country.

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.

  1. Compliant contract MUSTS implement the following interface.
interface IERC5485 { /// A function that returns the source of legitimacy in an address /// /// @returns address of EOA or contract that grants legitimacy status to this contract. /// See Specification #2 and #3 for more details. function sourceOfLegitimacy() public view returns (address); /// A function that returns the sovereign jurisdiction in an address /// /// @returns address of EOA or contract that *ultimately* grants legitimacy status (root of legitimacy lineage). /// See Specification #4 and #4 for more details. function jurisdiction() public view returns (address); }
  1. Suppose a compliant ContractA is deployed at address 0x<Contract_Address_A> and gains its legitimacy from another contract or External Owned Account (EOA) at 0x<ADDRESS_B>. In this case, it MUST return the 0x<ADDRESS_B> when being queried for sourceOfLegitimacy(). For example. If ContractA gains legitimacy from ContractB, ContractB gains legitimacy from ContractC but ContractC doesn't gain legitimacy from anyone, ContractC is considered the "jurisdiction" that both ContractB and ContractA observe. Both ContractA and ContractB MUST return the address of ContractC as the result of jurisdiction.

  2. A contract that matches ANY of the following cases is considered a "sovereign contract":

  • Case 1: it does not implement this EIP
  • Case 2: it implements this EIP but return its own address.
  • Case 3: it implements this EIP but return a ZERO address.
  1. Any compliant contract MUST return its legitimacy sources chain up to the sovereign contract when queried by jurisdiction().

  2. If ContractA gains legitimacy from ContractB, ContractA MUST observe the ContractB's order to ANY of the following

  • Order Type 1: execute a selfdestruct of ContractA
  1. If ContractA observes jurisdiction of ContractC (a sovereignty), ContractA MUST observe ContractC's order to ANY the following
  • Order Type 1: execute a selfdestruct of ContractA
  • Order Type 2: execute ANY smart contract executable proposals as specified in ERC-5247

TODO determine whether to address "add/remove legitimacy" in this EIP or leave it as a future EIP

Rationale

Needs discussion.

Backwards Compatibility

Needs discussion.

Security Considerations

Needs discussion.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Resources
GitHub
Supported by