ERC-5485 - Jurisdiction, Accreditation, and Enforcement

Abstract

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.

Motivation

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:

• Sovereignty — whether a contract is self-sovereign or claims allegiance to a higher-order system;
• Jurisdiction — which external authority it chooses to observe;
• Accreditation — whether that authority formally recognizes the contract as a valid participant within its system; and
• Enforcement — how decisions, rulings, or binding actions issued by that authority can be delivered to and acknowledged by the contract.

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.

Use Cases (Primary)

The primary use cases address the questions related to the status of a contract themselves.

• Stablecoins (e.g., USDC): Require jurisdiction because reserve custody, redemptions, freezes, and regulatory compliance depend on a specific legal authority.
• Tokenized Stocks / RWAs: Require jurisdiction because securities laws, transfer restrictions, investor rights, and enforcement vary entirely by legal venue.
• Regulated Lending Protocols: Require jurisdiction to define collateral rights, default resolution, licensing requirements, and enforceability of loan agreements.
• Private Company Equity for Qualified Investors: Require jurisdiction to enforce accreditation rules, transfer limits, corporate law, and cap-table validity.

Use Cases (Secondary)

The secondary use cases address the questions related to the interactions between contracts.

• Jurisdiction Compatibility Checks: Ensuring that interacting contracts operate under compatible or acceptable jurisdictions.
• Regulatory Boundary Enforcement: Gateways, bridges, or marketplaces can restrict integration to contracts meeting specific jurisdictional or accreditation requirements.
• Good-Standing Verification: Validating whether a contract is accredited and in compliance under its declared jurisdiction.
• Jurisdiction-Based Access Control: Allowing or restricting participation based on jurisdiction or accreditation metadata.
• Cross-Contract Legal Cohesion: Ensuring coherent jurisdictional alignment across multi-contract systems, federated DAOs, or hierarchical governance structures.
• Automated Dispute-Path Selection: Determining which arbitration venue, legal process, or enforcement route applies when disputes ar

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.

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.

1. Data Structures

For backward compatibility with existing contracts that implement ERC-5247, the interface extends the IERC5247Executable and IERC5247Executables data structures.

IERC5247Executable

Represents 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.

/// @notice A single executable action that MAY be proposed as part of an enforcement.
struct IERC5247Executable {
    /// @notice The target address to be called if this executable is processed.
    address target;

    /// @notice The amount of ETH (in wei) to send along with the call to `target`.
    uint256 value;

    /// @notice The gas limit for the call. Implementations MAY ignore this field.
    uint256 gasLimit;

    /// @notice The calldata to send to `target`.
    bytes data;
}

IERC5247Executables

A batch of IERC5247Executable items representing an ordered enforcement proposal.

/// @notice A batch of executable actions forming an enforcement proposal.
struct IERC5247Executables {
    /// @notice Ordered list of executable actions included in this proposal.
    IERC5247Executable[] executables;
}

2. Interface

sourceOfAccreditation()

Returns the address that accredited this contract as a valid participant within some jurisdiction or governance system.

• MUST return the accrediting authority’s address if one exists.
• MUST return address(0) if the contract does not recognize any external accreditation source (e.g., self-sovereign behavior).
• SHOULD remain stable over the contract’s lifetime or change only through a defined governance or upgrade mechanism.

jurisdiction()

Returns the primary jurisdiction or system whose rules this contract claims to observe.

• MAY return the same address as sourceOfAccreditation() when a single contract performs both roles.
• MUST return address(0) if the contract claims no external jurisdiction.
• Represents the higher-order system the contract aligns with, independently of accreditation.

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:

• immediately execute some or all proposed actions,

• record the proposal for later deliberation,
• partially honor or completely ignore the proposal based on policy.
• 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.

Full Interface

interface IERC5485 {
    /// @notice Returns the address that accredited this contract, if any.
    /// @dev MUST return address(0) if the contract does not recognize 
    ///      an external accreditation source. SHOULD remain stable or change 
    ///      only via defined governance.
    function sourceOfAccreditation() external view returns (address);

    /// @notice Returns the jurisdiction or higher-order system this contract 
    ///      observes.
    /// @dev MAY be the same as `sourceOfAccreditation()`. MUST return address(0) 
    ///      when the contract claims no external jurisdiction (self-sovereign 
    ///      behavior). SHOULD remain stable or change only via defined governance.
    function jurisdiction() external view returns (address);

    /// @notice Submits an enforcement proposal to this contract.
    /// @dev Implementations MUST define access control. Implementations MAY execute,
    ///      schedule, partially honor, reject, or only record `_proposal`. 
    /// @dev Implementations SHOULD emit events or store state acknowledging receipt of 
    ///      enforcement proposals. Payable to allow ETH forwarding for executables that 
    ///      specify non-zero value.
    function imposeEnforcement(IERC5247Executables _proposal) external payable;
}

Rationale

Separation of Jurisdiction and Accreditation

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.

Backwards Compatibility

1. 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.

2. 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.

Security Considerations

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

Copyright and related rights waived via CC0.