Execution Rewards & Tiered KYC: why agent payouts need on-chain counterparty tiers, not custodial checkboxes

#agents #ai #blockchain #security

When a human opens an OTC account, KYC is a one-time event. Documents go in, a flag turns on, the desk lets you trade. That flag is opaque to anyone else, mutable at the desk's discretion, and revisited maybe once a year.

When an autonomous agent picks a counterparty, the equivalent question is different in shape. The agent does not ask "is this party allowed to trade?" once a year. It asks "given everything I can verify about this party over the last 30 days, what is the probability the trade I am about to submit will actually settle within its committed window?" — and it asks before every bid.

A KYC checkbox does not answer that question. It was never designed to.

So when we wrote down Hashlock's fifth invented primitive — the last of the five we set out to ship after the V1 mainnet contracts went immutable — we wrote it down twice. Once as a settlement-history primitive (Execution Rewards), and once as an identity-attestation primitive (Tiered KYC). Each one is mostly useless on its own. Together they let an agent answer the continuous question, on-chain, in two reads, before it ever talks to the maker.

The continuous-data problem

Agent commerce has a property human OTC does not. The same address can submit thousands of bids per week. Every one of those bids is a discrete event that either settled or failed, on a timeline that is mostly public. After a few weeks, the address has produced a settlement track record dense enough to be more informative than any single identity claim about who is behind it.

This inversion is why "KYC-flag-once-a-year" feels wrong for agents. The expensive piece — verifying a real-world identity — is also the piece that ages worst and tells you the least about whether the next trade will work. The cheap piece — counting how often the address paid on time over the last 200 swaps — is also the most predictive, and the easiest to publish in a way the counterparty can verify without trusting you.

A well-designed primitive for agent commerce should make the cheap, predictive piece a first-class output of the protocol, and treat the expensive piece as an optional, tiered overlay that the taker can demand or ignore based on policy.

Execution Rewards: track record as a protocol output

Every Hashlock atomic swap has a committed settlement window built into the HTLC parameters — T+0 for spot legs, T+24h or T+48h for forward legs, per-leg deadlines for multi-leg trades. The HTLC contract already emits a claim event. We added a second event, written by the same transaction, that records (address, swap_id, committed_deadline, actual_settlement_time) for both sides.

That stream of events is the entire input. Every other reward is a deterministic function on top of it.

At each clearing window the protocol computes per-address statistics over the prior 30 days: number of swaps completed, number completed on time, number that timed out and refunded, weighted by swap notional. Addresses with a clean settlement history earn a tier-graded fee rebate on their next set of swaps. The rebate ladder is published, the math is a pure function on event data anyone can index, and the protocol does not keep a private list of "good" or "bad" addresses anywhere.

Two consequences follow. The track record is portable — an agent's settlement history is just events on the chain, and any maker can use it without asking Hashlock for permission. We are not selling the data; the data is the chain. And the rebate is the incentive, not the gate: an address with zero history can still trade, it just does not earn the rebate. There is no "no service" condition anywhere in the protocol.

Tiered KYC: identity as an attested overlay

Four tiers, each attested on-chain as a separate object the address controls.

T0 — pseudonymous. Default. No attestation. The address has whatever settlement track record it has earned.
T1 — self-attested. A signed statement from the address itself ("I am an autonomous agent operated by X"). Cheap, unverified, but stable and visible.
T2 — third-party verified. An issuer-signed attestation from a designated verifier (we are starting with two community-run verifiers; the issuer set is on-chain governable). The issuer signs whatever it verified — agent operator identity, organisation registration, controlling-key custodian. The attestation lives on-chain; the underlying documents stay with the verifier.
T3 — sanctioned-issuer KYB. Same on-chain shape as T2; the verifier itself holds a regulated KYB licence.

The taker chooses the minimum tier its policy requires when it submits an RFQ. Counterparties below that tier are filtered at the matching layer. The tier is a number on the RFQ, not a custodial decision.

The piece worth dwelling on: no custodian ever holds the underlying identity documents. The issuer verifies, signs an attestation, hands it to the address. The address publishes. The protocol reads. If the issuer disappears, the attestation stays on-chain but its issuer leaves the active set; takers decide as policy whether to honour attestations from departed issuers. The custody surface is the verifier's paperwork archive, not the protocol's.

Why this is different from custodial verification services

A category of well-funded competitors is converging on the same problem from the other direction. Nava ($8.3M seed) and a handful of others sell agent-payout verification as a service: send us your payout, we verify the counterparty, we release the funds. Fees usually 30–80 bps; verification logic private; the custodian in the loop on every settlement.

Two questions an agent can ask of any custodial verification service:

Does the verifier custody the asset in flight? If yes, the verifier is a bridge in disguise — an honeypot, a regulatory point of failure, a reputational point of failure.
Is the verifier's decision policy auditable? If the policy lives behind an API that returns yes/no, the agent has bought a third party's opinion, not a verifiable fact. The policy can change between bids without warning.

Execution Rewards + Tiered KYC inverts both. The verifier never touches the asset — the HTLC custodies it cryptographically. The policy lives on-chain as readable attestations the agent evaluates in its own code path. The asset is custodied by a hash preimage; the identity by a signed attestation. Neither is custodied by us.

The chain-level part, briefly

The shape only works because the underlying chains' object models cooperate.

On Sui, each address can own a per-address ExecutionLog object (immutable, append-only, written by the Hashlock package via capability) and a TierAttestation object (mutable, replaceable by the address). One RPC, both objects, done. On Ethereum, the same shape lands as two registry contracts and two eth_call reads.

The MCP server exposes both as tools: getExecutionRecord(address, chain) and getAttestation(address, chain). An agent calls those before submitting an RFQ. Settlement track record + identity tier + the live RFQ — three facts, one decision.

Honest limitations

The rebate ladder is a parameter, not a theorem. We are starting with a conservative schedule and will move it based on actual settlement-failure-rate data over the first quarter. If the ladder over-rewards heavy-volume addresses that occasionally fail, we will flatten it. The economics are not load-bearing on the trust model; they are tunable on top of it.

Attestations are only as good as the issuer set. A bad-issuer attack on T2 — a verifier mass-signing attestations for shell addresses — is detectable from on-chain data and removable via governance, but the detection window is non-zero. Takers that need a hard guarantee should set their minimum tier to T3 and accept the smaller address pool. There is no policy that gives "high-fidelity identity at zero verifier risk." That is a structural property of attestation, not a Hashlock-specific tradeoff.

What we want feedback on

The piece we are least sure about is the rebate-ladder shape: how should the protocol weight on-time settlement of a small swap versus a large one, when the small swap is easier to settle but the large swap is what the rebate is supposed to incentivise? The conservative answer is notional-weighted with a square-root dampener; we are not convinced that is right.

If you build trading agents, or have built them: when your bot picks a counterparty, what is the cheapest verifiable signal you would actually trust — a custodial KYC stamp issued by a service you ping per trade, or an on-chain settlement track record you can read from chain state in two calls?

Honest answers welcome. We will fold the best ones into the V2 parameter set.