forked from DecentralizedClimateFoundation/DCIPs
96 lines
5.0 KiB
Markdown
96 lines
5.0 KiB
Markdown
---
|
|
eip: 5485
|
|
title: Legitimacy, Jurisdiction and Sovereignty
|
|
description: An interface for identifying the legitimacy, jurisdiction and sovereignty.
|
|
author: Zainan Victor Zhou (@xinbenlv)
|
|
discussions-to: https://ethereum-magicians.org/t/erc-5485-interface-for-legitimacy-jurisdiction-and-sovereignty/10425
|
|
status: Draft
|
|
type: Standards Track
|
|
category: ERC
|
|
created: 2022-08-17
|
|
requires: 165, 5247
|
|
---
|
|
|
|
## 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](./eip-5485.md) 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.
|
|
|
|
```solidity
|
|
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);
|
|
}
|
|
```
|
|
|
|
2. 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.
|
|
|
|
3. 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.
|
|
|
|
4. Any compliant contract MUST return its legitimacy sources chain up to the sovereign contract when queried by `jurisdiction()`.
|
|
|
|
5. 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
|
|
|
|
6. 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](./eip-5247.md)
|
|
|
|
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
|
|
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|