ERC-8316: Programmable Settlement Locks

ERCs
1

I’m preparing to open a PR for a new ERC tentatively titled “Programmable Settlement Locks”, and wanted to start a thread first to introduce the proposal and provide a place for discussion.

Context

The proposal defines a minimal interface for value-bearing contracts to expose a common lock lifecycle: creation, update, delegation, spending, cancellation, and inspection.

The primary use case is atomic settlement across systems that do not share the same asset model or visibility assumptions. This includes conventional token contracts such as ERC-20, shielded or private token systems, zero-knowledge proof based transfers, externally validated state transitions, and other value-bearing contracts where the details of an operation may not be fully visible on-chain.

Proposal summary

The core idea is a standardized settlement object, rather than a uniform token model.

A programmable settlement lock represents a prepared value-bearing operation with a single current spender, committed spend and cancel paths, and delegation of finalization authority.

The intended shape of the interface is roughly:

interface IERCXXXX {
   function createLock(...) external returns (bytes32 lockId);
   function updateLock(bytes32 lockId, ...) external;
   function delegateLock(bytes32 lockId, address newSpender, ...) external;
   function spendLock(bytes32 lockId, ...) external;
   function cancelLock(bytes32 lockId, ...) external;

   function getLock(bytes32 lockId) external view returns (...);
   function isLockActive(bytes32 lockId) external view returns (bool);
}

The implementing contract is responsible for defining exactly what the lock means, how arguments are encoded, how commitments are constructed, and how supplied execution arguments are validated.

This allows a single executor, such as a coordinating smart contract, to settle many such locks in a uniform manner, even when they are tied to assets or value systems with very different internal construction.

The proposal is intended to support flows where a party prepares an operation on its own asset or value system, delegates control of that prepared operation to another party or coordinating contract, and allows the delegated spender to finalize it only through the predefined spend or cancel path.

Review focus

My plan is to open the PR with the complete specification rather than reproducing or summarizing it here. The most useful discussion will likely be against the full proposal.

Initial feedback is welcome on the general framing, related settlement patterns, and major token or value-system examples that should be considered. I’ll link back here once the PR is open to allow for more detailed discussion on the specifics.

2 Likes
2

PR for the proposal is here: Add ERC: Programmable Settlement Locks by awrichar · Pull Request #1840 · ethereum/ERCs · GitHub

3

This is a super interesting problem that you’re tackling with this ERC. There’s a good bit of conversation happening around how various ERCs that are orthogonally related to this area are composable with each other, and I think this contribution would be very welcome in that regard.

I contributed to ERC-8312 (Bounded Agent Actions), and this feels largely complementary rather than overlapping.

My current (albeit preliminary) mental model is that the two proposals answer different questions:

  • ERC-8316: “What value-bearing operation is being prepared and eventually settled?”

  • ERC-8312: “How much of an agent’s bounded mandate has been consumed across all actions so far?”

One is a settlement primitive, the other is an aggregate metering primitive if that makes sense.

I could imagine them composing quite naturally. For example: an agent operating under a bounded mandate (via 8312) might prepare multiple settlement locks over time. Each successful spendLock() could become the witness that advances the agent’s bounded-action cursor. The settlement lock finalizes a single operation, while the cursor records the cumulative authority consumed by all such operations.

Something like this . . .

Bounded Action Envelope
        │
        ├── Settlement Lock A → spend
        ├── Settlement Lock B → spend
        ├── Settlement Lock C → cancel
        └── Settlement Lock D → spend

Cursor = aggregate authority consumed

I think what makes this useful is that avoids forcing settlement objects to become policy objects iykwim.

One question that occurred to me while reading the proposal: could a settlement lock optionally carry an (chainId, registry, envelopeId) reference (or equivalent) as opaque metadata? That would allow a coordinating contract to update both the settlement lifecycle and the bounded-action cursor atomically, without either ERC depending directly on the other.

From my perspective, one potential approach to layering would be as follows:

  • ERC-7710 / ERC-7715: delegation and authorization

  • ERC-8312: aggregate authority metering

  • ERC-8316: settlement object lifecycle

  • ERC-8301: workflow orchestration

Each layer answers a different question which makes the composition cleaner than trying to merge the responsibilities into a single primitive. I’d love to know what you think.

1 Like