How it works
Privacy layer
Compensation can be paid to a one-time address the public record does not tie to the paying wallet, a service can be bonded without publishing its URL, and the protocol keeps only the data it needs.
A payout address made in this browser by /sdk/bond.mjs
01
Wallet pays
signs the x402 payment with this nonce
02
Publisher
reads the link privately and never publishes it
03
Leaf
(payout, amount, paid)
04
Relayer claims
the USDG lands at the payout address, which needs no gas
A sealed endpoint: what the chain and the board show in place of the URL
Unlinkable payouts
A customer can name a fresh payout address for each payment or each session. The SDK makes one in the browser or the agent with freshPayout(); the key stays with the customer. The payout is bound to the payment by the payment itself: the EIP-3009 nonce the payer signs is keccak256(abi.encode(payout, salt)), so nobody else could have attached it. The payout and the salt travel inside the X-PAYMENT payload. Endpoints that do not run on Infrabond still work: the SDK registers the link at POST /api/v1/payout after the payment settles, and the server checks that the transaction carries AuthorizationUsed(payer, nonce) on USDG.
The publisher reads these links privately. When an epoch is slashed, a payment bound to a payout address counts for that address, and the Merkle leaf is (payout, amount, paid). The published compensation document and the onchain claim name the payout address only. The publisher then submits the claim, or the relayer does on request, so the payout address needs no ETH and never sends a transaction. Compensation.claim lets anyone submit and always pays the leaf's account, so this needed no contract change.
Sealed endpoints
An operator can bond a service whose URL is not public. sealEndpoint draws a random salt, computes the commitment keccak256(salt ++ url), and encrypts the URL and the salt to the prober's public key (ECDH P-256, HKDF-SHA256, AES-256-GCM), published at GET /api/v1/seal. The site and its store only hold the ciphertext. The prober opens it on its own machine, checks the commitment, and keeps the URL in its private catalog. ProbeLog records the commitment as the endpoint hash, and the board shows the commitment with the measurements. The claim works the same way as a public one, from the sealed URL's own /.well-known/bond.json, signed over sealedClaimMessage(commitment, operator).
What a record holds
A probe record is (service, slot, anchor block, anchor hash, ok, ms, reason, response hash). The response hash is the keccak256 of what the prober read; the response itself is never stored or published. For a sealed service, failure text that could name its host is replaced by the reason code. Paid watches keep no payer address in their queue.
Accounts
Go mode uses a passkey account, and it asks for no email, no password and no identity check. The passkey stays on your phone or computer, and its public key decides a new contract account that is not tied to any other address you hold. The relayer pays the gas, so the account never needs ETH from one of your other wallets. Google sign-in exists only when it is switched on, and then it keeps an account identifier and a first name. The privacy policy lists every record we keep.
What stays public
The chain is public. The paying wallet, the payTo address and the amount of every payment are visible in USDG Transfer logs, and the amount in each compensation leaf is visible too. What the layer removes is the published link between a payment and the address that is compensated for it, and the URL of a sealed service. Nobody becomes anonymous through it. A person who controls both the paying wallet and the payout address can still be linked by how they move the money later.