Execution Rewards + Tiered KYC: Designing Incentives for a Settlement Layer With No Arbiter

On 18 May 2026, the BNB Agent SDK went live on BNB Chain mainnet. It has been running for three months, which makes it one of the few agent-commerce stacks that is neither a proposal nor a testnet demo.

It ships four modules: identity on ERC-8004, commerce and escrow on ERC-8183 (APEX), payment on MPP plus x402, and persistent memory on BNB Greenfield. The interesting one is commerce. ERC-8183 defines a job lifecycle - creation, funding, submission, evaluation, settlement, refund - and BNB's implementation extends it with UMA's Optimistic Oracle. Undisputed jobs settle fast. Disputed jobs escalate to UMA's Data Verification Mechanism, where token holders vote on the outcome.

So the agent economy now has a working arbiter on mainnet, and the arbiter is a token-holder vote.

We want to be careful here, because the lazy version of this post writes itself and it would be wrong.

The honest part: that is not our problem

ERC-8183 arbitrates subjective delivery quality. An agent was hired to produce something. Was the output good enough? That question has no mechanical answer. It genuinely requires a judge, and a decentralised judge is a defensible thing to build.

HTLC atomic settlement answers a completely different question: did both legs land? That question does have a mechanical answer. Either the preimage was revealed inside the timelock and both transfers executed, or it was not and both refunded. There is nothing to adjudicate because there is nothing subjective in it.

These are two different problems. A comparison that blurs them is selling something. Plenty of workloads genuinely need the jury, and for those, escrow plus arbitration is the right architecture and we are not a substitute for it.

What is worth saying is that most stacks buy arbitration by default, including for the exchange leg, where it buys nothing but latency and governance surface.

Where that leaves the incentive design

Here is the part that is less discussed. Your dispute architecture determines your bill.

If your protocol has an arbiter, you have to fund it. Someone compensates voters. Someone absorbs the latency of a challenge window. Someone carries the governance risk that the vote goes the wrong way for reasons unrelated to the job. Those costs are real, they are ongoing, and they scale with dispute volume.

If your protocol has no arbiter, you have a different bill, and in some ways a worse one: liquidity. Atomic settlement is worthless alone. A hash-time-locked swap needs a counterparty on the other side, and no amount of cryptographic elegance conjures one. Our design problem was never "who judges." It was "why does anyone show up."

That is the problem Execution Rewards and Tiered KYC were specified to solve.

The design

Three factors, all denominated in the fee we actually collect rather than in an emissions schedule:

Tiered execution rebate: 1.5 to 3.0 bps of settled notional, scaling with volume tier.
Referral share: 10% of the fees generated by a referred counterparty, for 12 months.
Streak bonus: a 1.0x to 1.3x multiplier on the rebate for consistent settlement activity.

The deliberate choice is the denomination. There is no reward token. No emissions curve, no unlock cliff, no governance asset to defend in a drawdown. A rebate paid out of collected fees cannot decouple from actual usage, which means it cannot manufacture the fake volume that reward tokens reliably manufacture.

The part of the arithmetic that does not close

We would rather publish this than have someone find it.

Our stated fee target is 1 to 2 bps, against the 8 to 10 bps typical of intermediated OTC settlement. The specified rebate is 1.5 to 3.0 bps of notional. Those two numbers do not close against each other. A 3.0 bps rebate paid out of a 2 bps fee is a subsidy, not a rebate, and calling it a rebate would be dishonest.

There are defensible ways to resolve it - rebate tiers that sit strictly inside the realised fee, funding the top tier explicitly as time-boxed acquisition spend and saying so, or repricing. What is not defensible is shipping the two numbers side by side and hoping nobody multiplies. This is the open question in the design, and it is why the program is specified rather than live.

Tiered KYC, and the distinction that matters

Three tiers:

Tier 0: no KYC. $5K/day settlement cap. Rewards accrue but stay frozen.
Tier 1: basic KYC. $100K/day cap.
Tier 2: full KYC. No cap, full payouts.

The distinction that carries the whole design: the settlement path is permissionless at every tier. Only the payout is gated.

You never need anyone's permission to settle. The HTLC does not know or care who you are, and it could not be made to care without stopping being an HTLC. What requires identity is receiving a rebate - because a rebate is a payment from us to you, and payments from a company to a person are a regulated activity in a way that a hash preimage is not.

That separation is not a compromise we settled for. It is the only structure we found where a compliance-aligned incentive program can sit on top of a trust-minimised settlement primitive without contaminating it. Tier 0 users get the full protocol. They just do not get paid until they tell us who they are.

Why this is the harder half

Decentralised arbitration is a hard technical problem with several known-good solutions, of which UMA's is one and BNB now runs it in production.

Bootstrapping a two-sided settlement venue without issuing a token is a market problem, and there are far fewer known-good solutions to those. We think the constraint is worth accepting, because the alternative is to inherit exactly the governance surface we designed the settlement layer to avoid. But we would be overselling it to call the answer solved.

Status, no hedging

Execution Rewards and Tiered KYC are specified and not shipped. The numbers above are design parameters, not live terms, and the fee gap above is unresolved.

The MCP server is at 0.6.0 on npm, six tools, scoped package hashlock-tech/mcp. The settlement leg runs live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested and are not live. The Bitcoin HTLC path is signet-validated with mainnet pending.

Rails ready, trains coming. We would rather undersell that.

The question

If you are designing an agent-commerce system: did you pick escrow plus arbitration because your workload has subjective delivery quality, or because it was the default in the template you started from?

Those produce the same architecture diagram and completely different risk.