1. Abstract
This whitepaper documents a paid, consent-gated genomic compute agent built on the GenoBank.io stack. A buyer's software agent presents one HTTP request that converts 2 FASTQ files, the forward and reverse reads of a sequencing run, into a VCF of called variants. The request carries an x402 payment header and a reference to an ERC-8356 consent grant. Before any expensive work runs, the node verifies the payment against server-canonical terms, checks that the consent grant authorizes exactly these reads for exactly this purpose, settles the USDC on-chain, and only then dispatches the GPU variant-caller. If any step fails, no money moves and no genome is read.
The design distinguishes three principals that incumbent payment and delegation systems collapse into one. The payer funds the job. The subject is the person whose DNA the reads describe and who consents to their processing. The agent is the session key or runtime that acts. A payment alone answers who is spending money; it never answers whether the data owner agreed. ERC-8356, which GenoBank.io ships as Metamorphic Consent, supplies that missing leg, and the gate binds the two together with a single non-negotiable rule: the on-chain payer must equal the on-chain grantee, and the reads the payment buys must be the reads the grant covers, computed by the server and never taken from the client.
We describe the safe ordering that keeps cheap read-only checks ahead of money and money ahead of the only costly step, the x402 exact scheme built on the gasless EIP-3009 transferWithAuthorization primitive, the consent check against a live ConsentGrant contract, the single choke-point that both submission paths pass through, and the closure of a pre-existing hole in which a request with no payment header ran a genome for free. We then report a live run on the Sequentia chain (identifier 15132025): a $10 settlement mined in one block, moving the balance from the payer to the GenoBank.io treasury, followed by dispatch of an NVIDIA Clara Parabricks DeepVariant germline job against the human reference. The paper closes with the deployment addresses, the fail-closed test matrix, and an honest boundary between what the single-operator pilot proves and what must still be hardened before a second party pays.
2. Paying a Stranger to Read a Genome
An autonomous agent that wants a genome analyzed faces two questions that are usually answered by two different systems, or by no system at all. The first is commercial: will the compute provider be paid, and can the provider prove it. The second is ethical and legal: may these particular reads be processed for this particular purpose, and can the provider prove that too. A credit card answers the first and is silent on the second. A consent form answers the second and is invisible to the machine that runs the job. The gap between them is where most genomic data misuse lives, because the party holding the session key is almost never the person whose body the data describes.
The agentic economy makes the gap sharper. When a model runtime, not a human at a browser, submits the job, there is no consent screen to click and no cashier to ask. The request must carry its own proof of payment and its own proof of consent, both machine-verifiable, both refusable at the moment of access. x402, an open HTTP-native payment protocol, supplies the first. It lets a server answer a request with an HTTP 402 challenge that states a price, and lets the client answer with a signed payment the server can verify and settle without a hosted checkout. What x402 does not carry, and was never meant to carry, is the data owner's permission.
GenoBank.io was built to govern that permission across the whole chain of derived artifacts. A biosample becomes FASTQ under a sequencing laboratory, becomes VCF under a variant caller, becomes an annotated record under an annotation service, and can become embeddings and model weights further downstream. This agent occupies the first transformation, FASTQ to VCF, which is exactly where the raw reads of a person's genome are at their most identifying. Getting the payment and the consent to travel together, and to bind to the specific reads being processed, is the point of the whole exercise.
3. Three Protocols, One Request
The agent composes three protocols, each answering a question the others cannot. Keeping them distinct is what lets the gate be honest about what it knows.
| Protocol | Question it answers | Primitive |
|---|---|---|
| x402 | Was the provider paid, and can it prove settlement? | HTTP 402 challenge plus an EIP-3009 signed USDC transfer |
| ERC-8004 | Which registered agent identity is transacting? | A trustless agent registry that says the clara-parabricks agent exists, is active, and accepts x402 |
| ERC-8356 | May these exact reads be processed for this purpose, and is that still true right now? | A revocable, purpose-bound consent grant with distinct subject, grantee, and agent legs |
The load-bearing insight is that none of the three subsumes the others. A valid x402 payment proves a wallet spent money; it says nothing about whose genome is being read. A registered ERC-8004 identity proves the agent is who it claims; it does not prove the data owner agreed. An ERC-8356 grant proves consent exists; it does not move funds. The agent needs all three, in that order of dependency, and it must refuse if any one is missing.
Text summary (Figure 1) Two legs meet at the grantee. On the consent leg, the subject signs a grant naming a grantee, and the grantee authorizes an agent to act. On the payment leg, the payer funds the job. The gate's single binding rule is that the payer must equal the grantee, checked on-chain by the server. In the single-operator pilot the subject, grantee, and payer are the same wallet, so the binding passes trivially, which is why the negative tests carry the proof.
4. Safe Ordering: Cheap Checks, Then Money, Then Compute
The whole design is an ordering discipline. A GPU variant-calling run is the only expensive step; it costs real dollars and hours. Everything before it is a read or a signature check that costs milliseconds. So the gate arranges the work strictly from cheap to expensive, and it settles money only after every free check has passed, and dispatches compute only after money has confirmed. A step that can reject the request for free must run before a step that cannot.
- Challenge. A request for a billable job with no valid payment header is answered with an HTTP 402 that states the price, the asset, the network, and the destination. No side effects.
- Server-side input pin. The node resolves the exact FASTQ biocids the GPU will consume from its own inventory, keyed by the biosample identifier in the request. It never trusts a client-supplied file path. It then computes a
resourceHashover those biocids. - Payment verify. The signed EIP-3009 authorization is recovered and checked against server-canonical values: the recovered signer becomes the payer, the destination must be the treasury, the asset must be the configured USDC, the amount must meet the price, the network must match, and the validity window must be open. Every client-echoed requirement field is ignored.
- Consent before money. Against the live ConsentGrant contract, the node checks that the grant is active, that
checkAccesspasses for the variant-calling purpose and the derive operation over the server-computedresourceHash, and that the grant's grantee equals the payer. Any revert or mismatch fails the request closed. - Settle. Only now does the USDC move, by broadcasting the signed transfer and waiting for on-chain confirmation.
- Dispatch. Only after a confirmed settlement is the job forwarded to the GPU executor.
Read-only checks precede money; money precedes the expensive step; the expensive step is the only one that costs. A payer who cannot prove consent is refused before a cent moves, and a payer whose payment cannot settle never reaches a GPU.
5. The x402 Exact Scheme and Server-Canonical Verification
The payment uses the x402 exact scheme, whose settlement primitive is EIP-3009 transferWithAuthorization. The payer signs an EIP-712 typed message authorizing a transfer of a fixed value to a fixed destination within a validity window, identified by a random nonce. The signature fixes the payer, the recipient, and the amount, so a relayer can broadcast it and pay gas without being able to alter any term. This is what makes the payment gasless for the payer and safe to relay.
Verification is entirely server-canonical, which is the property that defeats a spoofed challenge. The node reconstructs the EIP-712 digest from its own configured USDC contract, network, and price, recovers the signer, and compares every field to values it controls rather than to anything the client echoed back. A client that inflates the advertised network, swaps the asset, or lowers the amount changes only fields the server discards. The node also reads the token on-chain to confirm the payer's balance covers the amount and that the authorization nonce has not already been used, which blocks replay before settlement is even attempted.
The USDC used in the pilot is a 6-decimal token whose EIP-712 domain is the standard USD Coin domain, so the same client and gate code that target real USDC on a public network work unchanged; only the chain identifier and the verifying contract address differ. This is deliberate. The pilot proves the mechanism on a permissioned chain without a faucet dependency, and the identical code path moves to a public network for real-value settlement with no rewrite.
6. The Consent Gate: Payer Equals Grantee
The consent check is where a valid payment is prevented from buying access to the wrong person's genome. ERC-8356 defines a grant with three named principals and a purpose drawn from a versioned code. The contract's checkAccess view confirms the grant is active, that the requested operation is within the granted operations, that the purpose matches exactly, that the acting agent is the grant's agent, and that the requested resource is within the grant's scope. What checkAccess deliberately does not check is who is paying, because payment is outside its concern.
That is the single most important guardrail in the whole system, and it is enforced by the gate, not by the contract. The gate reads grantCore(grantId), which returns the grantee address on-chain, and requires it to equal the recovered payer. Without this one comparison, anyone holding $10 could pay to run a genome that someone else consented to, because the consent grant and the payment would each be internally valid while pointing at different people. With it, the payment and the consent are welded to the same identity.
An adversarial review of an earlier draft found that verifying the payment and verifying the grant, each on its own, is not enough. A pay-for-A, run-B attack passes both checks in isolation. The fix is two bindings that the server, not the client, controls: the payer must equal the grant's grantee, and the resourceHash the consent covers must equal the hash the server computed over the reads it will actually process. A client-supplied grant identifier is harmless because it can only unlock a grant whose grantee is the payer and whose scope is the server-pinned reads.
The resourceHash binding closes the second half of the same attack. Because the node computes the hash from the FASTQ biocids it resolved server-side, a client cannot present a grant for one biosample and have the node process a different one. The consent, the payment, and the bytes on the GPU all refer to the same reads or the request is refused.
7. Request Lifecycle
Figure 2 traces one paid request from the client to the returned VCF. The ordering in the diagram is the ordering in the code: parse, pin, verify, consent, settle, dispatch. Every arrow that could reject the request for free is to the left of the settlement arrow.
Text summary (Figure 2) The buyer agent posts a job with a payment header and a grant reference. The node resolves the FASTQ biocids and computes a resource hash on its own side. It verifies the signed payment against server-canonical terms and reads the token on-chain for balance and nonce. It checks consent, requiring the grantee to equal the payer. Only after both pass does it settle the USDC to the treasury and wait for the transaction to mine. Only after settlement confirms does it forward the job to the GPU executor, which runs the Parabricks DeepVariant germline pipeline and writes the VCF and BAM to storage scoped to the data subject.
8. One Choke-Point and the Freeloader Hole
Two submission paths can reach the GPU: a direct clara submit endpoint and the general agent job endpoint. If each enforced payment separately, the two would drift, and the one that forgot would be the way in. The design routes both through a single preflight function, so there is exactly one place that decides whether a job is billable and whether it may proceed. A single choke-point is auditable in a way that two parallel gates never are.
Building the choke-point surfaced a pre-existing hole worth naming plainly, because naming it is the point. The gate had been written to engage only when a payment header was present. A request that simply omitted the header was treated as not-a-paid-job and passed straight through to the GPU for free, which also meant it ran a genome with no consent check. The header was being used as the trigger for enforcement, so declining to send it declined enforcement.
The gate now decides billability first, from the job type, before it looks for a header. A billable variant-calling job (FASTQ, BAM, or the HiFi DeepVariant class) with no valid payment header is answered with an HTTP 402 that demands payment, never run for free. Non-billable job types are unaffected and still run without payment. The header is no longer the trigger; the job type is.
This is the difference between a paywall that asks for money and a paywall that can be skipped by not knocking. After the fix, a billable request with no header returns 402, a request with a malformed header returns 402 at the parse stage before any settlement, and a non-billable request continues to pass. All three behaviors were observed directly, not inferred.
9. Settlement: Facilitator or Self-Relay
The gate supports two settlement modes behind one configuration switch. In facilitator mode it hands the signed authorization to a hosted x402 facilitator that broadcasts and confirms. In self-relay mode, used for the pilot, a dedicated relay wallet broadcasts the payer's signed transferWithAuthorization directly and pays the gas. The relay never holds the funds; the USDC moves from the payer to the treasury by the terms the payer signed, and the relay only carries the transaction to the chain.
The relay wallet is deliberately a fresh, single-purpose key funded with a small amount of native gas, not a protocol key and not the treasury. Separating the gas-payer role from the fund-custody role is a small piece of key hygiene that keeps a compromised relay from being anything worse than a stalled settlement. The treasury that receives payment is a distinct cold address.
Self-relay is what makes the pilot faucet-free. Because no external facilitator serves the permissioned chain, the provider relays its own settlements, which means the entire loop, sign, verify, consent, settle, dispatch, closes without depending on any third party's testnet faucet or hosted service. The same switch flips to a facilitator when the agent moves to a public network for production.
10. From Dispatch to VCF
Dispatch forwards the job to a GPU executor over the internal network. The executor runs NVIDIA Clara Parabricks, invoking the DeepVariant germline pipeline against the human reference: it aligns the paired reads, sorts, and calls variants, emitting a BAM and a gVCF. The reads are streamed from cloud storage rather than copied to local disk, in keeping with the GenoBank.io rule that heavy genomic bytes never land on an orchestration host.
Because the outputs are derived from a person's reads, they are not loose files. The pipeline writes each result under storage scoped to the subject's biowallet, in the subject's own namespace rather than a shared pool. In the GenoBank.io model a derived output is then bound into the consent-governed lineage as a biocid, so the VCF and BAM come to share the same address space and consent regime as the FASTQ they came from, and a downstream reader addresses them by biocid under the same machinery that governed the input. Payment bought the computation; it did not buy the bytes, which remain the subject's.
During the pilot this stage also surfaced an unrelated operational fault worth recording for honesty: a stale environment flag on the executor had put the runner into a resume mode that skips the alignment and calling stages and expects pre-existing outputs, so every job failed within seconds until the flag was cleared. The x402 rail was fully proven before this was found, since the failure was downstream of settlement and dispatch. After clearing the flag, the DeepVariant germline run proceeded normally through the genome.
11. The Fail-Closed Test Matrix
A single-operator pilot in which the subject, the grantee, and the payer are one wallet cannot validate its own consent binding, because every equality it checks holds trivially. The proof therefore lives in the negative tests, each of which forces a mismatch and observes a refusal. The following behaviors were observed against the live contracts and the live gate.
| Adversarial input | Expected | Observed |
|---|---|---|
| Billable FASTQ job, no payment header | Refuse | HTTP 402, payment required, no job created |
| Billable FASTQ job, malformed payment header | Refuse before settle | HTTP 402 at parse, nothing spent |
| Payer not equal to grantee, valid grant | Deny | Consent denied, payer not grantee |
| Grant for reads A, request resolves to reads B | Deny | checkAccess false on resourceHash mismatch |
| Revoked grant | Deny | Grant not active |
| Non-billable job type, no header | Pass | Accepted, free path unaffected |
The wrong-purpose, wrong-operation, and impersonated-agent cases were also exercised against the consent contract and denied through the same checkAccess path. The discipline is that fail-closed must be watched, not assumed. Where a self-consent run makes a positive result meaningless, a forced-mismatch refusal is the only evidence that means anything.
12. Deployment and a Proven Run
On August 11, 2026 the full path ran on the Sequentia chain (identifier 15132025). A buyer wallet, holding a balance of the pilot USDC, submitted a paid FASTQ to VCF job for a real biosample. The gate verified the payment, checked consent, settled the USDC to the treasury, and dispatched the GPU variant-caller. The settlement transaction mined in a single block. The payer balance fell by $10 and the treasury balance rose by the same, exactly the amount the payer signed for.
Settlement moved on-chain: the payer balance went from 1000 to 990 USDC and the treasury from 0 to 10 USDC, in one mined transaction. The consent check passed with the grantee equal to the payer and the resource hash equal to the server-pinned reads. The GPU executor then accepted the job and ran an NVIDIA Clara Parabricks DeepVariant germline pipeline against the human reference to completion, producing a BAM, a gVCF, and a VCF written under the subject's owner-scoped storage.
| Component | Address or value on Sequentia (15132025) |
|---|---|
| Pilot USDC (mintable, EIP-3009, 6 decimals) | 0x58B47AfB3B2acE4c79a564A6aa4B28018ad8F4F3 |
| ConsentGrant (ERC-8356) | 0xD526E4d6e449A091D18900DC9ACb183e9556F714 |
| Treasury (payment destination) | 0xf54D5EA2eb0E93d46e8Bd925E0104162B8737722 |
| Price per job | $10 USDC (10000000 in 6-decimal units) |
| Pipeline | NVIDIA Clara Parabricks 4.7.0-1, DeepVariant germline, human reference |
| Settlement finality | ~3 seconds, one block |
The same ConsentGrant bytecode is also deployed on Base Sepolia, where the full consent surface was validated before the Sequentia pilot, and on Avalanche and its Fuji testnet. The path to public, real-value settlement is a configuration change, not a rewrite: point the same gate at a public network, its canonical USDC, and a hosted facilitator, and register the agent's ERC-8004 identity there.
13. Consent, Revenue, and Regulatory Mapping
GenoBank.io's Metamorphic Consent thesis holds that consent to use data about a person is not a static permission captured once at a form. It is an ongoing relationship that must be enforceable at access time, revocable without the cooperation of the party that benefits, and honest about the hard edge where deletion is no longer possible. ERC-8356 is the on-chain expression of that thesis, and this agent is the thesis exercised at the FASTQ to VCF hop. Revocation is operative where it matters: a grant flipped to revoked is denied by the same gate on the next request, so a withdrawn consent stops the next paid job rather than merely being noted after the fact.
Two regulatory anchors follow directly. Under GDPR, the operative triggers are knowledge and ease of withdrawal, and a consent whose withdrawal is honored at the gate on the next access is a far better fit than one whose revocation propagates on a polling delay. The right to erasure is preserved because the reads live in deletable cloud storage addressed by biocid, their derivatives are written to the same deletable, owner-scoped storage, and the on-chain record is a status anchor rather than the genome itself, never an immutable content-addressed store. No DNA is written to a chain at any point; the chain carries consent status, payment, and content-free references.
On revenue, the pilot settles the flat job price to the GenoBank.io treasury. The production revenue model, described in the BioFS Protocol whitepaper, splits payment across the laboratory, the annotator, and the platform and returns a Shapley-weighted Biodata Dividend to the subject's BioNFT, so the person whose reads were processed shares in the value their data creates. The pilot deliberately proves the settlement and consent mechanics first; the multiparty split composes on top of the same x402 settlement without changing the gate.
14. Open Items and Honest Boundaries
The single-operator pilot proves the mechanism. It does not, by itself, make the service safe for a second party to pay, and it is more useful to say where the line is than to blur it.
What the pilot establishes: server-canonical payment verification against a single advertised network; the payer-equals-grantee and server-computed resourceHash bindings; consent checked before money and money confirmed before dispatch; the closed freeloader hole; and a fail-closed test matrix observed rather than assumed.
What remains before a second party pays: authentication on the internal channel from the gate to the GPU executor, and turning on the executor's own payment check so it does not trust its network alone; automated refunds for the case where settlement succeeds but the provider-side compute fails, so a payer is never charged for a run the provider could not deliver; a re-check of grant activity at output time and usage accounting after each run, to close the window between the consent read and the result; per-payer and global concurrency limits and an input-size cap, so pricing cannot be griefed by oversized inputs; per-subject isolation on the output store; and registration of each derived output as a biocid, so the VCF and BAM enter the same owner-bound, consent-governed lineage as their inputs rather than resting only in owner-scoped storage. In the pilot run the outputs were written under the subject's storage namespace but that registration step had not yet run. Each of these is a known item with a known shape, and each flips from optional to mandatory the instant the payer and the subject are different people.
Research that remains genuinely open includes a recommended purpose ontology for clinical and research genomics that maps cleanly onto established data-use vocabularies, and a standard composition pattern between the ERC-8004 agent session and the off-chain access check so that the acting identity is authenticated end to end rather than asserted.
15. Conclusion
A paid genomic compute agent has to answer two questions at once, and answer them for a machine. Will the provider be paid, and may these reads be processed for this purpose. Payment protocols answer the first and are silent on the second; consent forms answer the second and are invisible to the machine. This agent carries both in one request and welds them together with a single rule the server enforces and the client cannot forge: the payer must be the grantee, and the reads the payment buys must be the reads the consent covers and the bytes the GPU reads.
The pilot shows the loop closing on a permissioned chain with no faucet dependency: a $10 settlement mined in one block, a consent check passed, and a variant-caller dispatched, in that order, with every free refusal ahead of the money and the money ahead of the compute. The same code path moves to a public network for real-value settlement without a rewrite. What is left is hardening, and the paper names it rather than hiding it, because the difference between a demonstration and a service is precisely the list of things you were honest about before anyone else's data or dollars were on the line.
Operator checklist
- Deploy or point to a 6-decimal, EIP-3009 USDC and an ERC-8356 ConsentGrant on the target chain; record both addresses.
- Mint a purpose-bound grant whose grantee equals the paying wallet and whose scope covers the exact FASTQ biocids to be processed.
- Configure the gate: paid jobs on, the network, USDC, ConsentGrant, treasury, price, agent address, and either a facilitator URL or a funded self-relay key.
- Confirm the public route accepts POST and reaches the node's job endpoint; the payment payload's network string must match the gate's advertised network.
- Run the negative matrix and watch each refusal: no header, malformed header, payer not grantee, wrong scope, revoked grant.
- Submit the paid job and confirm on-chain settlement to the treasury, then confirm the GPU dispatch and the resulting owner-held VCF biocid.
- Before onboarding a second payer, complete the internal executor authentication, refunds, output-time consent re-check, concurrency and input caps, and per-subject output isolation.
16. References
- Coinbase. x402: an open, HTTP-native payment protocol using the HTTP 402 status code. Protocol specification and facilitator documentation, 2025.
- EIP-3009: Transfer With Authorization. Ethereum Improvement Proposal, gasless signed token transfers.
- Uribe, D. ERC-8356: Purpose-Bound Third-Party Data Consent. ethereum/ERCs pull request 1921, 2026. https://github.com/ethereum/ERCs/pull/1921
- Ethereum ERC-8004: Trustless Agents (Draft), agent identity and payment-capability registry.
- Entriken, W. and Uribe, D. Biosample permission token with non-fungible tokens. 2020.
- Uribe, D. and Waters, G. Privacy Laws, Genomic Data and Non-Fungible Tokens. Journal of the British Blockchain Association, 2020.
- NVIDIA. Clara Parabricks accelerated genomics: DeepVariant germline pipeline. Product documentation, version 4.7.0.
- Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 7 and 17.
- U.S. HIPAA Security Rule, 45 C.F.R. §164.312.
- GenoBank.io. BioFS Protocol and Sequentia BioRouter whitepaper. https://genobank.io/whitepapers/biofs-protocol-v2/
- GenoBank.io. Reference implementation: ConsentGrant.sol, the mintable EIP-3009 test token, and the x402 gate modules. https://github.com/Genobank/biorouter-contracts
- Sequentia Network Explorer verified ConsentGrant. https://explorer.sequentias-test.genobank.io/address/0xD526E4d6e449A091D18900DC9ACb183e9556F714