Defines a standard interface for smart contracts to declare their sovereignty status, observed jurisdiction, accreditation within that jurisdiction, and the mechanisms by which they may receive and record enforcement actions.
Smart contracts are, in essence, digital agreements whose execution is enforced by network consensus. As their use increasingly expands into domains that mirror real-world legal or institutional relationships, one critical component present in traditional systems is missing on-chain: a structured way to express sovereignty, jurisdiction, accreditation, and enforcement.
Historically, much of the smart-contract ecosystem has emphasized decentralization and self-sovereignty, implicitly assuming that contracts do not rely on any external legal or institutional framework. However, many practical use cases—especially those that interface with real-world regulations, property rights, or compliance regimes—require an explicit identification of the jurisdiction(s) a contract observes, the authority that has accredited it as a valid actor within that jurisdiction, and the mechanisms by which binding decisions may be communicated to it.
This ERC proposes a standardized interface for representing four foundational concepts:
In many real-world and institutional settings, an entity becomes an actionable participant only after receiving formal accreditation by the relevant authority—whether this is a state chartering a corporation, a school recognizing a student club, a platform onboarding a developer, or a DAO admitting a module into its governance structure. Conversely, some entities explicitly declare their absence of external jurisdictional alignment, operating instead as sovereign actors such as declaration of independence as newly established countries gain their sovereignty, or joining a jurisdictional system as a newly established entity. Representing both modes—subordination and self-sovereignty—is essential for accurately modeling institutional relationships on-chain.
By standardizing how smart contracts declare sovereignty, jurisdiction, accreditation, and enforcement pathways, this ERC enables interoperability between legal systems, regulatory frameworks, institutional hierarchies, and on-chain governance models—bridging a structural gap between real-world systems and their digital counterparts.
The primary use cases address the questions related to the status of a contract themselves.
The secondary use cases address the questions related to the interactions between contracts.
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.
A contract compliant with this ERC MUST implement the interface defined below.
The interface provides standardized primitives for declaring a contract’s accreditation source, its observed jurisdiction, and a mechanism for receiving structured enforcement proposals. When the jurisdiction is absent, a contract is self-sovereign.
For backward compatibility with existing contracts that implement
ERC-5247, the interface extends
the IERC5247Executable and IERC5247Executables data structures.
IERC5247ExecutableRepresents a single action that MAY be proposed as part of an enforcement submission.
This structure follows a generic “executable call” pattern: a target address, an optional ETH value, a gas limit, and calldata for invocation.
No guarantees are made regarding execution; implementations MAY ignore or reinterpret these fields.
IERC5247ExecutablesA batch of IERC5247Executable items representing an ordered enforcement proposal.
sourceOfAccreditation()Returns the address that accredited this contract as a valid participant within some jurisdiction or governance system.
address(0) if the contract does not recognize any external accreditation source (e.g., self-sovereign behavior).jurisdiction()Returns the primary jurisdiction or system whose rules this contract claims to observe.
sourceOfAccreditation() when a single contract performs both roles.address(0) if the contract claims no external jurisdiction.imposeEnforcement(IERC5247Executables _proposal)A standardized entry point for submitting an enforcement proposal to the contract.
Implementations MUST define and document the access control for this function (e.g., restricted to jurisdiction(), sourceOfAccreditation(), or a curated authority list).
Implementations MAY:
Implementations SHOULD emit events or persist state enabling verifiable on-chain acknowledgment that an enforcement attempt occurred.
The function is payable to allow ETH to accompany proposals when executables specify non-zero value or when processing fees apply.
This ERC separates jurisdiction from accreditation because they represent fundamentally different relationships:
Jurisdiction is voluntary.
A contract may unilaterally declare that it observes the rules or
norms of a particular system.
Accreditation requires external approval.
Only the authority itself can grant formal recognition that a contract
is an accepted participant within its system.
Jurisdiction expresses alignment; accreditation expresses acceptance.
Declaring jurisdiction does not imply the authority recognizes the contract.
Accreditation establishes the reciprocal relationship.
Accreditation enables enforcement.
Authorities typically issue enforcement only to contracts they have
accredited. Jurisdiction alone does not create this binding pathway.
Keeping these concepts distinct reflects how real-world institutions work: observing a system’s rules is self-declared, but gaining formal standing within that system requires an explicit action by the authority. This distinction ensures more accurate modeling of institutional relationships on-chain.
The absence of accreditation and jurisdiction is backward compatible with existing contracts, as it is a superset of the existing behavior. More explicitly, a contract that does not implement this interface observes no jurisdiction, by default showing no accreditation and is considered self-sovereign.
Using ERC-5247 as a base interface for enforcement proposals is backward compatible with existing contracts that implement ERC-5247, such as Multi-Sig wallets such as treasury of a DAO.
Similar to a real world scenario, when observing a jurisdiction practically gives the contract the ability to enforce rules on the contract's behavior. Simlar to "Ownable" (ERC-173) or "AccessControl", implementations MUST be aware of the security implications of this: the security of a contract is compromised if the jurisdiction is compromised.
Copyright and related rights waived via CC0.