eip: 5485
title: Interface for Legitimacy, Jurisdiction and Sovereignty
description: <Description is one full (short) sentence>
author: Zainan Victor Zhou (@xinbenlv)
discussions-to:
status: Draft
type: Standards Track
category: ERC
created: 2022-08-17
requires: 165
Abstract
An interface for legitimacy, jurisdiction and sovereignty.
Motivation
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.
For example. If ContractA gains legitimacy from ContractB, ContractB gains legitimacy from ContractC but ContractC doesn’t gain legitimacy from any one, ContractC is considered the “jurisdiction” that both ContractB and ContractA observe.
Both ContractA and ContractB MUST return address of ContractC as the result of jurisdiction.
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. The ContractC represents Supreme Court of the Country.
Another real example is a contract the declared “self-sovereignty” that doesn’t follow any jurisdiction.
This interface supports both cases, providing a way to allow smart contract to determine if they want to allow / prohibit interaction based
on the sovereignty.
For example A country might want to require any digital money service’s all smart contracts to observe their EIP-5485 jurisdiction before they are allow to operate money in their (real world) legal jurisdiction.
On the other hand, a DAO with strong decentralized ideology might choose to only inter-operate with EOA
or “self-sovereigned” smart contracts to avoid being affected by any countries.
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.
- Compliant contract MUSTS implement the following interface.
interface IERC5485 {
function legitimatedBy() public view returns (address);
function jurisdiction() public view returns (address);
}
-
Suppose a compliant
ContractAis deployed at address0x<Contract_Address_A>gains its legitimacy from another contract or External Owned Account (EOA) at0x<ADDRESS_B>, it shall return the0x<ADDRESS_B>when being queried forlegitimatedBy(). -
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.
-
Any compliant contract MUST return its legitimacy sources chain up to the sovereign contract when queried by
jurisdiction(). -
If ContractA gains legitimacy from ContractB, ContractA MUST observe the ContractB’s order to ANY of the following
- Order Type 1: execute a
selfdestructof ContractA
- If ContractA observes jurisdiction of ContractC (a sovereignty), ContractA MUST observe ContractC’s order to ANY the following
-
Order Type 1: execute a
selfdestructof ContractA -
Order Type 2: execute ANY smart contract executable proposals as specified in EIP-5247
Rationale
Needs discussion.
Backwards Compatibility
Needs discussion.
Security Considerations
Needs discussion.
Copyright
Copyright and related rights waived via CC0.