Vitalik-inspired AI payment system can send expired deposits to its treasury

The Ethereum Foundation’s Oct. 1 announcement that zkAPI is running on mainnet provides a concrete financial-control test for the private AI-payment framework coauthored by Davide Crapis and Vitalik Buterin: how can a user reclaim unspent funds if the billing server stops responding?

While zkAPI, a metering system for APIs, features an onchain withdrawal route that operates independently of server clearance, a user’s ability to recover their balance depends on their specific spending state and whether they can initiate an exit before time runs out. The system’s pause capabilities and expiring notes introduce distinct boundaries around that financial control.

Open Anonymity developed the implementation alongside the Ethereum Foundation. Crapis and Buterin published the initial design on Feb. 11, and the foundation’s October announcement credits the development team for turning that concept into software and smart contracts. Etherscan records the creation of the vault linked in the announcement on Sept. 30, one day prior to the public release.

Although the announcement states the linked vault holds USDC credits, the current mainnet manifest indicates the vault actually uses native ETH, with balances calculated in whole gwei. Activity on the blockchain explorer similarly reflects ETH-denominated deposits and payouts.

CryptoSlate previously covered the proposal in February. The rollout on mainnet now gives these withdrawal rights, deadlines, and settlement dependencies real-world significance.

Two routes out of a prepaid balance

In the current protocol, deposits fund a note. The user’s wallet retains the private spending state locally, applying cryptographic proofs to authorize metered services without triggering an onchain transaction for every individual API request. As usage is settled, the server signs a successor state reflecting the remaining balance. A critical dividing line exists between an unused spending state and a predecessor that has already authorized a request, as the latter can be challenged if an escape payout is attempted.

This structure makes the spending state vital for recovery. The vault verifies withdrawal proofs against its rules, but the wallet must hold the necessary data to prove the balance it wishes to withdraw. Safeguarding the note and its recovery documentation is mandatory to substantiate a balance following an interruption.

The cooperative path, known as a mutual close, relies on server clearance. A separate server signing key authorizes the withdrawal, and the wallet incorporates that signature into its proof. The vault then reviews the proof and disburses the remaining balance to a designated address specified within it, which can differ from the original funding address.

The second option is an escape withdrawal, which wallets can launch without clearance signatures. Rather than instantly releasing funds, the vault removes the note from active circulation and logs a pending payout.

Public mainnet parameters establish a challenge period of 86,400 seconds, or 24 hours. If no valid challenge is executed prior to this deadline, the system finalizes the process by sending the recorded balance to the user’s destination, while routing the remaining deposit-minus-balance share to the treasury, provided the transfers succeed.

Consequently, a server outage does not entirely eliminate the documented withdrawal mechanism. Users with a valid spending state can exit without securing fresh authorization. The waiting window allows the system to catch any attempts to withdraw using a state that has already authorized services.

Every spending state relies on a nullifier—a cryptographic identifier designed to prevent reuse. To contest an escape attempt, a challenger submits an initial request proof featuring the same nullifier as the withdrawal attempt, proving that the state has already authorized consumption.

The vault code specified in the mainnet configuration retains the historical active root of the request for verification purposes. A valid challenge filed before the deadline cancels the pending payout and returns the note to active status without applying any separate financial penalties.

This challenge protects settlements from unauthorized withdrawals using already-spent states by establishing prior authorization, though the accuracy of the provider’s billing remains a separate issue. Restoring a note also leaves any missing successor signatures unresolved.

This distinction is crucial during disputes. While the escape route bypasses the need for server clearance, it prevents users from claiming arbitrary balances. If a state used for an exit has already authorized a request, a valid challenge redirects the note back into the recovery workflow.

When usage has already been authorized, provider accounting and server-signed successor states remain integral to reclaiming leftover balances. A successful challenge reactivates the note without settling contested bills or guaranteeing refunds.

Pause powers, expiry and the value of the balance

The vault codebase grants administrative pause capabilities. Deposits, mutual closes, and new escape initiations all depend on this status. As a result, permissionless exits can be blocked from starting if the vault is paused.

However, pending escape finalizations, challenges, and expiry claims are not subject to this pause switch. Users who have already initiated an escape hold a different status than those who have yet to begin the process.

While the code equips administrators with these powers, no actual use of the pause switch is documented here. For users attempting to secure refunds during service outages, administrative pause control remains an external dependency affecting availability.

Expiration introduces another crucial timeline. The mainnet configuration mandates a 30-day note lifespan, though the vault rounds the deposit time plus this lifespan upward to the nearest daily boundary. Consequently, a note’s actual expiration may occur slightly after 30 full days have elapsed.

Once an active note expires, the contract allows it to be closed via an expiry claim, transferring the entire recorded deposit directly to the treasury. This rule differs from standard withdrawals, where proved remaining balances go to the user. Notes already marked as pending withdrawal are ineligible for active-note expiry claims.

For funds remaining inside active notes, prepaid cloud AI creates a time-sensitive claim window. State recovery and timely closures dictate whether users can access the withdrawal path before notes qualify for treasury collection.

Denominating the system in ETH also impacts asset ownership between sessions. According to the native billing documentation, deposits do not function as stablecoin balances nor are they automatically swapped into USDC; their fiat reference value fluctuates alongside the price of ETH.

Dollar-denominated inference fees are settled via price quotes. Browsers and servers verify pinned Chainlink ETH/USD feeds from finalized chain states, bind those quotes into the authorization, and maintain that fixed rate across settlement and recovery phases. Measured dollar usage is subsequently converted into capped charges denominated in whole gwei and rounded upward.

Locking in an accepted quote prevents restarts or recovery attempts from repricing prior authorizations, but it does not stabilize the dollar value of the user’s remaining ETH. For individuals prepaying for cloud inference services, the service bills and the underlying balances operate under different denominations.

The trust that remains

The mainnet manifest selects OA-org key issuance paired with OpenRouter inference. Provider usage receipts and billing server signatures for successor states remain operational components of settlement. While Ethereum supplies the exit framework, users still depend on trustworthy chain views, compatible proof software, retained wallet data, and timely challenger actions.

The cryptographic framework introduces additional assumptions. The manifest references the note-bound Groth16 circuit and setup files outlined in the repository. Setup documentation notes that keys were generated by a single party without a multi-party computation ceremony. While matching artifact hashes verify which files are deployed, the secure destruction of setup secrets remains an unverified trust assumption.

The manifest explicitly labels the integration as experimental and unaudited. These disclosures limit the level of security assurance tied to the implementation, meaning mainnet availability does not guarantee that every live recovery scenario will function smoothly.

Inference providers continue to observe prompt contents, and network metadata may still allow correlation. Such billing privacy considerations remain distinct from underlying withdrawal rights.

Ultimately, control over prepaid AI funds relies on completing an exit from a valid balance before active notes expire. The escape route provides an alternative to server clearance, though its practical utility depends on effective state recovery and vault availability when required.

Frequently Asked Questions

• What is zkAPI? zkAPI is a billing system designed for metered APIs that incorporates private AI-payment architecture coauthored by Davide Crapis and Vitalik Buterin.
• Can I recover my funds if the billing server stops working? Yes, the system features an onchain escape withdrawal route that does not require server clearance, provided you initiate it before deadlines or note expiration.
• What currency do the vaults use? Although initial announcements mentioned USDC credits, the current mainnet manifest operates using native ETH, with balances calculated in whole gwei.
• What happens if a note expires? Once an active note expires, it can be closed via an expiry claim that routes the full recorded deposit to the treasury.