Integration reference · evidence checked 2026-07-22
A reusable reliability contract for a facilitator.
The AsterPay work shows how route reliability, signed outcomes, and replay-resistant reconciliation can fit around an x402 facilitator without putting MAKO in custody or payout execution.
- Repository evidence
- Reliability envelope, signing, verification, reconciliation
- Public evidence
- Signer registry partner record observed
- Sampled wire
- 402 observed; reliability field not observed
- Commercial claim
- No customer or revenue claim
The integration problem
Settlement and service quality are different facts.
A facilitator can issue payment requirements and observe settlement. The buyer still needs an attributable answer about route quality, the delivered response, and whether the evidence can be verified later.
Attach bounded route reliability
A versioned envelope carries score, confidence, sample window, expiry, and the source of the observation.
Bind the payload to an allowed signer
Canonical bytes, EIP-191 signing, signer recovery, expiry, and maximum age make the envelope independently reviewable.
Reconcile without replay
Nonce checks, date-scoped idempotency, and signer policy let an operator record an outcome without granting MAKO custody or payout authority.
Evidence register
What exists, what was observed, and what remains unproven.
Each layer supports a different claim. The strongest statement is the narrowest one that all available evidence supports.
| Layer | Evidence | Supported conclusion |
|---|---|---|
| Repository implementation | Reliability model, canonical serialization, signing and recovery, expiry, allowed-signer checks, reconciliation, nonce handling, and tests under services/asterpay. | The integration contract exists in MAKO source and can be reused as an implementation reference. |
| Public signer registry | On 2026-07-22, AsterPay’s public registry returned HTTP 200 and listed “MAKO Pulse” in partner records. | A public AsterPay-controlled artifact referenced MAKO Pulse at that timestamp. |
| Sampled 402 response | On 2026-07-22, the public demo route returned HTTP 402. Its sampled extensions exposed payment-identifier, not reliability. | The sample established an x402 challenge, but not live reliability emission on that route. |
| Commercial status | No invoice, contract, attributable external payer, traffic ledger, or customer authorization is presented. | No paying-customer, revenue, transaction-volume, or broad-production claim is made. |
Reusable architecture
What another facilitator can take forward.
The reference is most useful as a narrow contract pattern, not as implied proof that every AsterPay route uses it today.
Version a compact reliability extension.
Keep score, confidence, sample window, observations, expiry, source, and signature fields bounded and machine-verifiable.
Publish the signer policy.
Recover the signer from canonical bytes and compare it with a facilitator-controlled allowlist or public registry.
Separate issuance from reconciliation.
Use idempotency and nonces to record outcomes while leaving settlement, custody, and payout control with the facilitator.
Test the actual wire surface.
Repository code, registry evidence, and a sampled response answer different questions; a go-live gate must verify the target route itself.
Apply the pattern
Bound the next integration to eight routes.
The 14-day facilitator pilot maps this contract to a real route surface, produces a go/no-go decision, and keeps all access read-only.