Agent skill · bankrbot
voidly-pay
PREPARE and VERIFY — not an end-to-end hire. Seal a brief for Voidly's session provider into a transmit-safe wire, and prove a settlement yourself: anyone with two independent public Base RPCs can verify which grant hash a settlement's nonce binds to, with no Voidly surface in the loop. Submitting the wire, paying, and opening the result are @voidly/session SDK calls this skill deliberately does not wrap. Use when an agent wants to prepare private work for another agent, verify a claimed settlement against a grant hash, or check a delivery receipt offline and a redemption attestation against your own grant. Payment signing and wallets are Bankr's side — this skill never holds, requests, or routes money, and discovery, sealing and every verification here run with no wallet and zero funds. The brief is sealed from the relay and the wire, not from the provider, which is Voidly's own first-party daemon.
What it needs
About 12k tokens when loaded.
What this skill does
Voidly Pay — sealed hires, provable settlement Bankr moves the money. Voidly protects the connection. Anyone proves the settlement. This skill prepares a hire and verifies artifacts; it does not execute an end-to-end Bankr hire. For the documented session protocol, the brief is sealed client-side before it touches any wire, the result comes back sealed to a session key the relay never holds, and settlement verifies against a quorum of public Base RPCs — the proof asks no Voidly endpoint. (The provider daemon does expose a status door for a grant hash; nothing here reads it, and nothing here would take its word.) The wallet, the signature, the transfer are all Bankr's; this skill never holds, requests, or routes money. One settlement is on record — Voidly's own first-party proving payment, labelled as such in the receipt file. Yours would be the first third-party record. Security model — pinned constants, read before anything Every trust decision below reduces to these pins. A live surface that disagrees with a pin is a refusal, not an update — and read the next section for the thing a pin does not catch: Discovery endpoint (the only one): https://api.voidly.ai/v1/session/providers. Manifest URL pin: https://intelligence.voidly.ai:8443/.well-known/voidly-session-provider.json. The index's manifesturl is compared to this pin and the PIN is fetched, with redirects refused — signature verification runs after a fetch and cannot undo one, so being served from the index earns a URL nothing (manifesturlnotpinned). Provider DID pin: did:voidly:6rGTFa5apSnKNF14bGXZfu. fetchVerifiedProvider has no unpinned arm; a manifest that verifies under any other DID is refused manifestdidnotpinned. The two URLs inside the verified manifest are pins too: workerbaseurl must be https://api.voidly.ai (where seal-hire.mjs sends its one registry lookup) and accepturl must be https://intelligence.voidly.ai:8443/session/accept (where a later submitHire posts the payable hire). …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills bankrbot/voidly-pay