OAuth vouchers for recipient linking and sender-signed disclosures for receipt metadata.
Authentication
Section titled “Authentication”Boon uses different auth models for different surfaces.
Recipient link vouchers
Section titled “Recipient link vouchers”Recipients prove GitHub or X ownership through OAuth. The Worker signs an EIP-712 Link voucher that the contract verifies.
Voucher fields:
providerHash bytes32handleHash bytes32recipient addressnonce uint256deadline uint256Domain:
name: Boonversion: 1chainId: 8453verifyingContract: 0xfb6662AdaF0611a94322634d5B86203Cfb59d5e8The Worker reads live linkNonce and linkedWallet before signing. The hosted claim flow refuses ordinary already-linked handles.
Sender disclosure signatures
Section titled “Sender disclosure signatures”Optional sender disclosure lets the sender of a known boon opt into public disclosure metadata on that receipt.
Endpoints:
POST /api/v1/boons/:txHash/disclosureDELETE /api/v1/boons/:txHash/disclosureBoth require a signature over:
Disclosure(bytes32 txHash,string action)Domain:
name: Boon Disclosureversion: 1chainId: 8453verifyingContract: 0xfb6662AdaF0611a94322634d5B86203Cfb59d5e8The Worker checks the recovered signer against the indexed tipper for the receipt. If the subgraph cannot verify the receipt, disclosure writes are refused.
x402 payment auth
Section titled “x402 payment auth”Paid graph endpoints use x402 payment headers rather than app sessions or API keys. See x402 protocol.