Hi all — I have been exploring whether the ecosystem is missing a standard settlement layer for high-frequency off-chain interactions, especially for autonomous agents.
Recent standards and proposals seem to cover identity, accounts, permissions, and payment signaling reasonably well. But I have not found a common interface for off-chain conditional settlement itself: typed lock messages, settlement proof references, relay claim requests, and minimal conditional settlement extension interfaces.
I am considering a narrowly scoped ERC for this interface surface only.
Importantly, I am not trying to standardize a full payment channel network, routing layer, privacy backend, or rebalancing algorithm. The idea is much narrower: standardize the settlement envelope that wallets, hubs, relays, and adjudicators could share.
Why I think this may matter
1. Agents seem like the first truly natural users of off-chain settlement systems
Historically, state channels and similar off-chain systems have been difficult for human users because they require:
-
liveness,
-
frequent signing,
-
dispute handling,
-
lifecycle management,
-
and liquidity awareness.
Agents are much better suited to this model:
-
they are online continuously,
-
they can sign and verify automatically,
-
they can handle disputes programmatically,
-
and they can manage channel state without human intervention.
So my intuition is that agent systems may finally create a real user class for off-chain conditional settlement.
2. A large class of agent interactions are high-frequency and low-value
Many agent interactions look like:
-
recurring API/tool payments,
-
data feed subscriptions,
-
solver or service payments,
-
streaming payments,
-
conditional execution with refund paths.
For these flows, per-action on-chain settlement is often too expensive or too latent, even when combined with account abstraction or private RPC approaches.
3. Existing standards cover adjacent layers, but not the settlement layer itself
Very roughly, the stack today seems to be:
-
identity / registry standards,
-
account abstraction and permissions,
-
payment signaling,
-
application-specific execution logic.
What seems missing is a shared settlement-facing interface for:
-
conditional lock objects,
-
proof or attestation references,
-
relay-based claims,
-
conditional settle / refund semantics and their bindings into host channel lifecycle.
One way to think about this is:
-
payment signaling standards tell you when payment should happen,
-
this proposal would try to standardize how off-chain conditional settlement is represented and resolved.
Why not just use rollups?
This proposal is not intended as a replacement for rollups.
Rollups remain the right place for on-chain execution, composability, and final settlement. However, even on L2, many agent-native interactions still face a mismatch between the execution model and the workload:
-
each action still competes for inclusion and blockspace,
-
each action still carries per-action execution / proving / data overhead,
-
and the latency model is still fundamentally different from sub-second off-chain coordination.
The specific gap I am trying to address is the settlement layer for interactions that are too frequent, too low-value, or too recurring to include individually on-chain, even when the chain is a rollup.
In that sense, I see this proposal as complementary to rollups rather than competitive with them.
Rollups are excellent for low-frequency, high-value execution. The missing piece seems to be a standardized settlement interface for high-frequency agent interactions such as streaming payments, recurring tool/API usage, and conditional micropayments.
Relationship to ERC-7824
I am aware of ERC-7824. From its published materials and reference interfaces, it already appears to cover the host state-channel framework layer: lifecycle management, challenge / checkpoint / conclude flows, asset custody and exit handling, application sessions, broker coordination, and off-chain RPC.
That means I do not want to redefine the lifecycle primitives that ERC-7824-like systems already expose. In particular, interfaces in the spirit of challenge, checkpoint, conclude, deposit / transfer / reclaim, and application-defined state validation seem to belong to the host channel framework.
What I am exploring here is narrower: a conditional settlement extension or companion interface that can sit on top of such frameworks. The layer I still think may be missing is a shared envelope for:
-
conditional lock typed data,
-
proof references,
-
relay claim requests,
-
conditional settlement / refund hooks,
-
and lock status discovery.
So the real question is not “replace ERC-7824?”, but rather “is there a missing conditional-settlement interface that should compose with ERC-7824-style channel systems?”
If the right direction is “this should be an ERC-7824 extension profile / companion ERC” rather than a standalone ERC, that would be very useful feedback.
Proposed scope
In scope
I am currently thinking about standardizing:
-
EIP-712 typed data for proof-bound conditional obligations
-
a proof/attestation reference envelope
-
a relay claim request envelope
-
a minimal on-chain conditional settlement extension interface, including
settleConditional,refundConditional, andlockStatus
Many channel systems already contain some notion of a lock or pending conditional transfer. However, those objects are usually framework-local or application-local: they are encoded inside app-specific state, interpreted by framework-specific validators, and not exposed as a reusable settlement-facing interface.
What seems missing is not “locks exist” but a common envelope for proof-bound conditional obligations. In particular, when settlement depends on external evidence such as a receipt root, oracle attestation, zk proof, or delegated relay claim, a generic PCN lock is no longer enough. Wallets, hubs, relays, verifiers, and adjudicators need a standard way to agree on what is being conditionally paid, what proof authorizes settlement, how timeout refund works, and how the current lock status can be discovered.
Example: an agent and a hub may already share a payment channel, but the agent wants to pay only if the hub can prove that a private execution actually happened in an external system. A generic HTLC-style lock does not say which verifier is authoritative, which receipt root or proof digest is being referenced, who may relay the claim, or how third parties can observe whether that lock is still pending, settled, or refunded. That is the narrower interoperability gap this proposal is trying to address.
Possible optional extensions
These might be extensions rather than core:
-
capability discovery
-
private claim relay
-
local rebalancing coordination extensions
Explicitly out of scope
I do not think the following should be in the core proposal:
-
channel lifecycle primitives already covered by host frameworks, such as
challenge,checkpoint, andconclude -
custody / exit primitives such as deposit, transfer, reclaim, and exit format
-
HTLC vs virtual channels
-
specific rebalancing algorithms or coordination policies
-
specific privacy-preserving routing or hub-blinding constructions
-
specific zero-knowledge circuit internals
-
private execution backend design
-
operator collateral / solvency models
-
hub business logic or fee policy
My goal is to keep the proposal narrow enough that it standardizes an interface layer, not an entire protocol stack.
Very rough shape of the core objects
At a high level, I am thinking about something like:
struct ConditionalLock {
bytes32 channelId;
address initiator;
address responder;
bytes32 assetId;
uint256 amount;
uint256 fee;
uint256 expiry;
bytes32 conditionType;
bytes32 conditionCommitment;
bytes32 applicationCommitment;
bytes32 escrowCommitment;
uint256 channelNonce;
}
struct SettlementProofRef {
bytes32 channelId;
bytes32 lockId;
bytes32 proofType;
bytes32 settlementRoot;
bytes32 proofDigest;
address verifier;
bytes32 auxDataHash;
}
struct ClaimRelayRequest {
bytes32 channelId;
bytes32 lockId;
bytes32 escrowCommitment;
bytes32 outputCommitmentHash;
uint256 maxRelayFee;
uint256 deadline;
bytes32 proofType;
bytes32 proofDigest;
uint256 nonce;
}
And a minimal conditional settlement extension interface roughly along the lines of:
interface IAgentConditionalSettlementExtension {
enum LockStatus {
None,
Locked,
Settled,
Refunded
}
function settleConditional(
bytes32 *channelId*,
ConditionalLock calldata *lock*,
SettlementProofRef calldata *proofRef*,
bytes calldata *proof*
) external;
function refundConditional(bytes32 *channelId*, bytes32 *lockId*) external;
function lockStatus(bytes32 *channelId*, bytes32 *lockId*) external view returns (LockStatus);
}
Lifecycle methods such as close / dispute or challenge / checkpoint / conclude are intentionally not shown here and would come from the underlying channel framework.
This is only a sketch, not a finalized spec.
Why I think this should be a settlement-layer ERC, not a “full state channel ERC”
I think trying to standardize the entire off-chain protocol stack in one proposal would be too broad.
Different systems may reasonably choose different answers for:
-
routing,
-
privacy,
-
rebalancing,
-
proof systems,
-
liquidity sourcing,
-
and trust assumptions.
But they may still benefit from a shared envelope for conditional settlement.
That is the layer I am interested in standardizing.
Questions for feedback
I would especially appreciate feedback on the following:
1. Is this problem actually real, or am I reinventing an existing standard that I missed?
2. Is this better framed as a generic off-chain conditional settlement ERC, rather than an “agent” ERC?
3. Is the proposed scope narrow enough for an ERC discussion?
4. Should capability discovery be part of the core proposal, or clearly separated as an extension?
5. Should private claim relay be a separate proposal instead of an extension?
6. Does it make sense to standardize only the conditional-settlement extension surface and explicitly leave lifecycle primitives to host frameworks such as ERC-7824?
7. Should this be a standalone companion ERC, or would it make more sense as an explicit extension profile for ERC-7824-like channel frameworks?
I already have a longer draft spec, but before polishing it into a more formal ERC, I wanted to first sanity-check whether the problem statement and scope make sense to the community.
Thanks in advance — I would especially appreciate prior art, critiques on scope, and reasons this should not be an ERC.