Technical Whitepaper · Agentic Payments · Consent-Gated Compute

The Paid FASTQ to VCF Agent

An x402 request settles USDC, an ERC-8356 grant proves the specific reads may be processed, an ERC-8004 identity says who is paying, and only then does a GPU variant-caller run. Payer, consenting subject, and acting agent are held as three distinct principals. Proven end to end on Sequentia, faucet-free.

Author Daniel Uribe, Founder and CEO, GenoBank.io
Date August 12, 2026
Protocols x402 · ERC-8004 · ERC-8356 (Metamorphic Consent)
Pipeline Clara Parabricks DeepVariant, FASTQ to VCF
Stack GenoBank.io · biofs-node · Sequentia 15132025
Version 1.0
Status. Live pilot. The full path ran end to end on Sequentia on August 11, 2026: a $10 USDC settlement moved on-chain (payer to treasury), the ERC-8356 consent check passed, and the GPU variant-caller was dispatched. The pilot is a single-operator self-consent run; the negative tests, not the happy path, are what prove the gate.
3
Protocols composed
$10
USDC settled per job
6
Fail-closed checks
~3s
Settlement finality

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.

ProtocolQuestion it answersPrimitive
x402Was the provider paid, and can it prove settlement?HTTP 402 challenge plus an EIP-3009 signed USDC transfer
ERC-8004Which registered agent identity is transacting?A trustless agent registry that says the clara-parabricks agent exists, is active, and accepts x402
ERC-8356May 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.

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.

  1. 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.
  2. 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 resourceHash over those biocids.
  3. 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.
  4. Consent before money. Against the live ConsentGrant contract, the node checks that the grant is active, that checkAccess passes for the variant-calling purpose and the derive operation over the server-computed resourceHash, and that the grant's grantee equals the payer. Any revert or mismatch fails the request closed.
  5. Settle. Only now does the USDC move, by broadcasting the signed transfer and waiting for on-chain confirmation.
  6. Dispatch. Only after a confirmed settlement is the job forwarded to the GPU executor.
Principle

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.

Why gasless matters here The payer is an autonomous agent, not a person funding a wallet with native gas on every chain it touches. EIP-3009 lets the agent sign a dollar transfer and let the provider's relayer carry the gas, so onboarding a paying agent does not require it to first acquire the chain's native token.

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.

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.

Fix

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 inputExpectedObserved
Billable FASTQ job, no payment headerRefuseHTTP 402, payment required, no job created
Billable FASTQ job, malformed payment headerRefuse before settleHTTP 402 at parse, nothing spent
Payer not equal to grantee, valid grantDenyConsent denied, payer not grantee
Grant for reads A, request resolves to reads BDenycheckAccess false on resourceHash mismatch
Revoked grantDenyGrant not active
Non-billable job type, no headerPassAccepted, 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.

Result

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.

ComponentAddress 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)
PipelineNVIDIA 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

  1. Deploy or point to a 6-decimal, EIP-3009 USDC and an ERC-8356 ConsentGrant on the target chain; record both addresses.
  2. Mint a purpose-bound grant whose grantee equals the paying wallet and whose scope covers the exact FASTQ biocids to be processed.
  3. 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.
  4. 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.
  5. Run the negative matrix and watch each refusal: no header, malformed header, payer not grantee, wrong scope, revoked grant.
  6. Submit the paid job and confirm on-chain settlement to the treasury, then confirm the GPU dispatch and the resulting owner-held VCF biocid.
  7. 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

  1. Coinbase. x402: an open, HTTP-native payment protocol using the HTTP 402 status code. Protocol specification and facilitator documentation, 2025.
  2. EIP-3009: Transfer With Authorization. Ethereum Improvement Proposal, gasless signed token transfers.
  3. Uribe, D. ERC-8356: Purpose-Bound Third-Party Data Consent. ethereum/ERCs pull request 1921, 2026. https://github.com/ethereum/ERCs/pull/1921
  4. Ethereum ERC-8004: Trustless Agents (Draft), agent identity and payment-capability registry.
  5. Entriken, W. and Uribe, D. Biosample permission token with non-fungible tokens. 2020.
  6. Uribe, D. and Waters, G. Privacy Laws, Genomic Data and Non-Fungible Tokens. Journal of the British Blockchain Association, 2020.
  7. NVIDIA. Clara Parabricks accelerated genomics: DeepVariant germline pipeline. Product documentation, version 4.7.0.
  8. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 7 and 17.
  9. U.S. HIPAA Security Rule, 45 C.F.R. §164.312.
  10. GenoBank.io. BioFS Protocol and Sequentia BioRouter whitepaper. https://genobank.io/whitepapers/biofs-protocol-v2/
  11. GenoBank.io. Reference implementation: ConsentGrant.sol, the mintable EIP-3009 test token, and the x402 gate modules. https://github.com/Genobank/biorouter-contracts
  12. Sequentia Network Explorer verified ConsentGrant. https://explorer.sequentias-test.genobank.io/address/0xD526E4d6e449A091D18900DC9ACb183e9556F714