Receipts

A third-party agent that paid GBLIN daily, on-chain

This is a transaction record, not an endorsement. Since mid-July an ERC-8004 agent registered on Base as id 59895 — operated by a different party — has bought GBLIN's signed risk attestation (/api/x402/attestation, $0.003 USDC via x402): a few exploratory calls on 18 July, then once a day at the same minute, as an input of a decision rule its operator publishes as a hash-pinned file. Below is every settlement, as it sits on Base.

Update, 21 August 2026: the daily purchases stopped. The last settlement is 16 August at 15:17 UTC. This is not us going quiet about a lost customer: the payer's own transparency log shows its entire x402 settlement step stopped that minute — the same run also stopped paying its own endpoint (markovianprotocol.com/signal/latest) — while its signal entries keep flowing, so the agent is running and only the payment step is down. We verified our side first (a real paid call on 21 August: 402 challenge, EIP-3009 settlement, EIP-712 signature and all five contract fields check out) and told them. The table below stays as it is.

Honest scale: this is one recurring payer. We publish it not because it is large but because it is checkable — anyone can re-derive this table from public data in a minute (method in the page source). Payer wallet: 0x89cA143c42c22D0B0D24D6d2BFe00050331C6ef8. Recipient (GBLIN fee wallet): 0x0ebA5d314F4f5Dcb7A094953Fa9311a45172dd1B.

Checkable from both ends: the payer runs a witnessed transparency log and records each purchase in it. Where we could match a settlement to a log entry, the leaf column links to that entry's inclusion proof on log.markovianprotocol.com. The two records are kept by two different operators; they should agree, and where they don't we say so.

Snapshot as of 2026-08-17, corrected 2026-08-18 and 2026-08-19 (29 settlements on 26 distinct days; 28 matched to a log leaf, 1 without one). Correction: the first version of this page listed 21 settlements starting 26 July; it had read only the first page of explorer results and dropped 8 earlier ones (18–25 July). Fixed here, stated here. Update 2026-08-19: the four settlements of 9–12 August now have leaves (#7469–#7472). The operator found the cause on its side — a retired local copy of its log server was still bound to the port the stamp client posts to, and won the race for exactly those four days — and re-submitted the four claims through the real pipeline on 18 August. Their leaf content carries the original settlement dates; the log append timestamp is 18 August, because that is genuinely when they entered the tree. We verified each leaf's transaction hash against the on-chain settlement before linking it. One settlement still has no leaf: the first of the two 08:22 calls on 18 July (tx 0x7b29…, 08:22:09 UTC) — it was settled by a different sender than the payer's stamp client, so it most likely never reached their pipeline; the operator's record shows two calls that day and ours shows three, and we leave both records as they are. We do not characterise the counterparty's reasoning beyond what its own public files state; the operator was notified before this page went up and can ask for changes at any time. What the attestation is and how any agent can verify one: /risk-gate. Our own wallets are excluded from every public counter we publish; the payer above is not ours.