zkAPI’s Mainnet Launch Tests Recovery Rules for Prepaid AI Balances

The Ethereum Foundation’s Oct. 1 announcement that zkAPI is live on mainnet gives a practical financial test to the privacy-focused AI payment design coauthored by Davide Crapis and Vitalik Buterin: if a billing server stops cooperating, how can a user retrieve funds that have not been spent?

zkAPI is a billing system for metered APIs and documents an on-chain withdrawal route that does not depend on the server. But a user’s ability to recover a balance depends on which spending state they hold and whether they begin an exit in time. The implementation’s pause controls and expiring notes define the limits of that control.

Open Anonymity built the implementation with the Ethereum Foundation. Crapis and Buterin published the underlying design on Feb. 11, and the foundation’s October announcement credited the team that turned it into software and contracts. Etherscan records creation of the announcement-linked vault on Sept. 30, one day before the announcement.

The announcement described the linked vault as holding USDC credits. The current mainnet manifest identifies the same vault as holding native ETH, with balances measured in whole gwei. Its explorer activity also shows ETH-denominated deposits and close payouts.

CryptoSlate’s February coverage examined the proposal. Now that the implementation is on mainnet, withdrawal rights, deadlines and settlement dependencies have practical weight.

Two routes for recovering a prepaid balance

Under the current protocol, a deposit funds a note. The wallet stores the private spending state locally and uses proofs to authorize metered service. Individual API calls do not each trigger an on-chain transfer. As usage is settled, the server signs a successor state representing the remaining balance. The practical dividing line is between an unused spending state and a predecessor state that has already authorized a request: the latter can be challenged if used to seek an escape payout.

That structure makes the spending state central to recovery. The vault can check a withdrawal proof against its rules, but the wallet must still possess the information needed to prove the balance it wants to withdraw. Preserving the note and its recovery records is essential to proving a withdrawable balance after an interruption.

The cooperative route, called mutual close, begins with server clearance. A separate server signing key authorizes the withdrawal, and the wallet includes that signature inside its proof. The vault verifies the proof and pays the remaining balance to a destination bound into it. That destination can differ from the address that originally funded the note.

The second route is the escape withdrawal. A wallet can initiate it without the clearance signature. The vault removes the note from the active set and records a pending payout rather than immediately releasing the funds.

The public mainnet configuration sets a challenge period of 86,400 seconds, or 24 hours. If no valid challenge succeeds before the deadline, finalization pays the recorded balance to the user’s destination and the deposit-minus-balance share to the treasury, assuming the transfers succeed.

A server outage therefore does not automatically eliminate the documented withdrawal path. A user with a usable spending state can seek an exit without obtaining fresh clearance. The waiting period gives the system time to detect an attempt to withdraw from a state that has already authorized service.

Each spending state has a nullifier, a cryptographic identifier used to prevent reuse. To challenge an escape, a challenger submits an original request proof with the same nullifier as the attempted withdrawal. The proof establishes that the state had already authorized usage.

The vault code identified by the mainnet configuration preserves the request’s historical active root for that check. A valid challenge submitted before the deadline cancels the pending payout and restores the note to the active set. It does not impose a separate monetary penalty.

The challenge protects settlement against withdrawing from an already-used state. It establishes prior authorization, while the accuracy of the provider’s measured bill remains a separate question. Restoring a note also leaves any missing successor signature unresolved.

That distinction matters in a dispute. The escape route removes the need for the server’s withdrawal clearance, but it does not allow a user to claim an arbitrary balance and have the contract accept it. If the state used for an exit already authorized a request, a valid challenge can send the note back into the recovery process.

When usage has already been authorized, provider accounting and a server-signed next state remain part of recovering the remaining balance. A successful challenge reactivates the note without resolving the contested bill or guaranteeing a refund.

Pause controls, expiry deadlines and balance value

The vault code gives the owner a pause switch. Deposits, mutual close and initiation of new escape withdrawals all check it. An exit that does not require server clearance can still be prevented from starting while the vault is paused.

Already-pending escape finalization does not have that pause gate. Neither do challenges or expiry claims. A user who has successfully initiated an escape is therefore in a different position from one who still needs to start it.

The code provides these powers; no use of the pause switch is established here. For a user seeking a refund during an interruption, the owner’s pause control remains an availability dependency.

Expiry creates another deadline. The mainnet manifest specifies a 30-day note lifetime, but the vault code rounds deposit time plus that lifetime upward to a one-day boundary. A note’s actual expiry can therefore fall later than exactly 30 elapsed days.

Once an active note expires, the code permits it to be closed through an expiry claim that sends its full recorded deposit to the treasury. That rule differs from a normal withdrawal, where the proved remaining balance goes to the user. A note already in pending withdrawal status does not qualify for the active-note expiry claim.

For funds still in an active note, prepaid cloud AI creates a time-limited claim. State recovery and timely close-out affect whether the user reaches the withdrawal path before the note becomes eligible for the treasury claim.

ETH denomination also affects what the user owns between sessions. According to the native billing documentation, the deposit is neither a stable-dollar balance nor a swap into USDC. Its dollar reference value changes with ETH’s price.

Dollar-denominated inference is charged through a price quote. The browser and server verify a pinned Chainlink ETH/USD round in finalized chain state, bind that quote into the authorization and keep the accepted rate fixed through settlement and recovery. Measured dollar usage is converted into a capped charge in whole gwei, rounded upward.

Freezing an accepted quote prevents a restart or recovery attempt from repricing that existing authorization. It does not stabilize the dollar value of the user’s remaining ETH. For someone prepaying for cloud inference, the service bill and the underlying balance have different denominations.

The trust that remains

The mainnet manifest selects OA-org key issuance with OpenRouter inference. Provider usage receipts and the billing server’s signed successor states remain operational parts of settlement. Ethereum supplies the exit mechanism, while a trustworthy chain view, compatible proof software, retained wallet data and timely challenger operation remain necessary dependencies.

The cryptographic setup carries a separate assumption. The manifest points to the note-bound Groth16 circuit and setup artifacts described in the repository. The setup documentation says the keys were generated by one party and no multiparty ceremony has taken place. Matching artifact hashes establishes which files are being used, while the destruction of setup secrets remains a separate trust assumption.

The manifest describes the integration as experimental and not production-audited. Those disclosures limit the assurance attached to the implementation. Mainnet availability alone does not demonstrate that every live recovery scenario will work.

The inference provider still sees prompt content, and network metadata can permit correlation. Billing privacy leaves those content and network questions separate from withdrawal rights.

For prepaid AI funds, control ultimately rests on completing an exit from a usable balance before the active note expires. The escape route gives users an alternative to server clearance; its practical value depends on state recovery and the availability of the vault when they need it.

Source link