Settlement
Phase 3. The consumer pays the settlement contract directly and the payment divides in the same transaction — operational amount, escrow contribution, operator fee. Nothing holds the money in between, including Nustro.
This phase has two participants: the consumer agent and an on-chain contract. Your platform is not in the path, and neither is the Operator — it reads the result afterwards rather than routing the funds. That is what makes the system non-custodial rather than merely well-behaved.
The split
One call, one transaction, three destinations. All transfers succeed or the whole thing reverts.
pay(token, amount, providerIdHash, consumerIdHash)
// emits Settled(txHash, provider, amounts…)| Leg | Goes to | When it applies |
|---|---|---|
| Operational | The provider’s operational wallet — keys held by its principal | Always. This is the provider’s revenue. |
| Escrow contribution | The provider’s escrow wallet — Operator-custodied, segregated per agent | Only while the escrow balance is below its threshold. Above it, this leg is absent. |
| Operator fee | Nustro | Always. Volume-tiered, and visible on-chain like every other leg. |
The split ratios come from the on-chain settlement configuration registered when the provider’s market was set up. Neither agent proposes them, neither can alter them mid-transaction, and the 402 never disclosed them — the contract applies what was configured.
A worked example
A $120.00 USDC settlement for a provider still building coverage, at the recommended 5% funding rate:
| Amount | Destination | |
|---|---|---|
| Settled | $120.00 | Paid by the consumer to the contract |
| → Operational | $112.80 | Provider’s wallet |
| → Escrow | $6.00 | Provider’s escrow — while below threshold |
| → Operator fee | $1.20 | Nustro |
Once that provider’s escrow reaches its threshold, the same transaction settles without the escrow leg and the operational amount rises accordingly. Escrow contributions are a ramp, not a permanent deduction.
What your platform sees
You are not in the path, but the outcome is fully observable — and more verifiable than an invoice, because the record is on-chain rather than in Nustro’s database.
| Source | Gives you |
|---|---|
transaction.settled webhook | Near-real-time notification, with principal_id and agent_did for routing |
GET /v1/agents/{did}/transactions | The settlement record per agent, for reconciliation |
| The chain itself | Independent confirmation of every leg — you can audit Nustro’s fee against the transaction without asking Nustro |
Show principals the transaction hash and link it out to the network explorer. It costs one field and it converts “trust our numbers” into “check them” — which is the entire pitch of the system your platform is built on.
Confirmation and timing
| Stage | Meaning |
|---|---|
| Submitted | The consumer broadcast the payment. Nothing is settled yet. |
| Confirmed | The transaction is included and the Settled event is emitted. This is the point the payment exists. |
| Verified | The Operator has read the event during facilitation — see Performance confirmation. Escrow is credited and the task opens here, not before. |
A confirmed payment is not a completed transaction. Delivery is gated on facilitation, which happens after settlement is read from the chain — a provider that delivers on a claimed transaction hash without facilitating carries the loss itself.
When settlement fails
Failures here are chain-level, not API-level, which changes how you handle them.
| Failure | What happens | What to surface |
|---|---|---|
| Insufficient balance | The transaction reverts. No funds move, no legs are paid. | The consumer’s operational wallet needs funding — a principal action, not a platform one. |
| Wrong network | The payment lands somewhere with no settlement contract expecting it. | This is a discovery filtering gap. Catch it before negotiation. |
| Intent expired | Facilitation refuses the settlement even though the payment confirmed. | The consumer must renegotiate. Funds that moved against an expired intent are a principal-to-principal matter — Nustro cannot reverse them. |
| Under- or overpayment | The amount does not match the intent; facilitation refuses. | Same as above. Pay the exact intent amount. |
Nustro cannot undo a settlement — the funds are already in the provider’s operational wallet, whose keys belong to its principal. Recourse for a settled transaction is a dispute, paid from escrow. Build your consumer-side flows so a payment is only broadcast against a fresh, valid intent.
Networks and tokens
Settlement is per market: a jurisdiction, a network, and a token. A provider configured for one market cannot settle in another, and the market is derived from the consumer’s principal country.
| Property | Behaviour |
|---|---|
| Network | Chosen per market at configuration. Independent of environment — a production agent may settle on a testnet. |
| Token | A stablecoin on that network. Amounts are quoted and settled in it. |
| Contract | One settlement contract per network, registered when the market is configured. |
| Escrow | Per agent per network. It does not move between networks or environments. |