ERC-5485 Jurisdiction, accreditation, and enforcement declaration interface (Jurisdiction, Accreditation, and Enforcement)

Review · Other · created 2022-08-17

An interface that lets a smart contract declare and expose, in a standard way, the jurisdiction it follows, the accreditation it has received from that jurisdiction, and the channel through which enforcement decisions are delivered to it.

Why it is needed

Smart contracts are digital agreements executed through network consensus, but as their use has expanded into domains resembling real-world law and institutions, a missing piece has become apparent. There was no way to structurally express on-chain which legal system (jurisdiction) a given contract follows, whether that system's authority has formally recognized the contract as a legitimate participant (accreditation), or how the authority's decisions are communicated to the contract. For stablecoins, reserve custody, redemption, freezing, and regulatory compliance all depend on a specific legal authority, and for tokenized stocks, securities law, transfer restrictions, and investor rights vary entirely by legal jurisdiction. Conversely, some contracts want to make clear that they are self-sovereign, following no external system at all. Without a standard way to express both states, contracts have no consistent way to check jurisdictional compatibility with each other or verify whether a counterparty is an accredited participant, and when disputes arise there is no automatic way to determine which procedure should be followed.

What to implement

In depth

Four concepts: sovereignty, jurisdiction, accreditation, and enforcement

The original text standardizes four foundational concepts. Sovereignty is whether a contract is self-sovereign or claims to belong to a higher-level system. Jurisdiction is which external authority it has chosen to follow. Accreditation is whether that authority has formally recognized the contract as a valid participant within its system. Enforcement is the method by which the authority's decisions and rulings are delivered to the contract and acknowledged. The original text gives examples of both cases, such as a state granting incorporation to a company or a school approving a club, where a participant must be accredited before it can act, and cases like a declaration of independence that explicitly states there is no external jurisdiction, explaining that expressing both dependent and self-sovereign modes together is essential for accurately modeling institutional relationships on-chain.

Rules for sourceOfAccreditation()

Returns the address that accredited this contract as a valid participant in some jurisdiction or governance system. If an accrediting authority exists, it MUST return that address, and if the contract does not recognize any external accreditation and operates in a self-sovereign manner, it MUST return address(0). The return value SHOULD remain stable over the contract's lifetime, or change only through a defined governance or upgrade procedure. Because accreditation can only be granted by an authority, this function's value represents an external approval relationship, not the contract's own claim about itself.

Rules for jurisdiction()

Returns the primary jurisdiction or system whose rules this contract claims to follow. If a single contract plays both the jurisdiction and accreditation roles, it MAY return the same address as sourceOfAccreditation(). If it does not claim any external jurisdiction, it MUST return address(0). This value indicates which higher-level system the contract aligns itself with, regardless of whether accreditation has been granted. In other words, it can express a state where jurisdiction alone has been declared but accreditation has not yet been received.

How imposeEnforcement() is processed

This is the standard entry point for submitting an enforcement proposal to a contract. The implementation MUST define and document access control for this function. For example, it can be restricted to jurisdiction(), sourceOfAccreditation(), or a curated list of authorities. The implementation MAY execute some or all of the proposed actions immediately, record them for later deliberation, or partially accept or completely ignore them according to policy. It SHOULD emit an event or store state so that the fact an enforcement attempt occurred can be verified on-chain. The function is payable so that ETH can be sent along with the call when an execution item specifies a nonzero value or when a processing fee is required.

Data structures based on ERC-5247

An enforcement proposal is represented by two structs that extend ERC-5247. IERC5247Executable represents a single executable action, with four fields: the target address to call, the amount of ETH to send value (in wei), the gas limit gasLimit, and the call data data. There is no guarantee of execution, and an implementation may ignore or interpret these fields differently. It is explicitly stated that gasLimit may also be ignored by the implementation. IERC5247Executables bundles these actions into a single enforcement proposal as an ordered list.

Why jurisdiction and accreditation were kept separate

The two concepts were separated because they represent fundamentally different relationships. Jurisdiction is voluntary: a contract can unilaterally declare that it will follow a given system's rules. Accreditation, by contrast, requires external approval: only the authority can formally recognize a contract as an accepted participant in its system. Jurisdiction expresses alignment, while accreditation expresses acceptance, and declaring a jurisdiction does not mean the authority has recognized that contract. Also, because an authority typically only imposes enforcement on contracts it has accredited, it is accreditation that creates the enforcement pathway. This distinction reflects how real-world institutions actually work: following a system's rules is a self-declaration, but gaining formal status within it requires explicit action by the authority.

Backward compatibility

The absence of jurisdiction and accreditation is a superset of existing behavior, so it is compatible with existing contracts. A contract that does not implement this interface is, by default, considered self-sovereign, following no jurisdiction and holding no accreditation. Also, because ERC-5247 is used as the basis for enforcement proposals, it is compatible with contracts that already implement ERC-5247, including multisig wallets such as DAO treasuries.

A proposal still under review

This ERC's status is Review. It is at the stage of receiving community review, so its interface and rules may change before final confirmation. If you are planning an actual implementation, it is safer to keep checking the original text for changes.

Things to watch out for

Original ERC · ← ERCs