The Ethereum Foundation's Oct. 1 announcement that zkAPI is running on mainnet gives the private AI-payment design coauthored by Davide Crapis and Vitalik Buterin a concrete financial-control test: how does a user get unspent money back when the billing server stops cooperating?
zkAPI, a billing system for metered APIs, documents an onchain withdrawal route that does not require the server's clearance. But a user's ability to recover a balance depends on which spending state they hold and whether they can start an exit in time. The implementation's pause powers and expiring notes put boundaries around that control.
Open Anonymity built the implementation with the Ethereum Foundation. Crapis and Buterin published the underlying design on Feb. 11; the foundation's October announcement credits the team that turned it into software and contracts. Etherscan records the announcement-linked vault's creation on Sept. 30, a day before the announcement.
The announcement describes its linked vault as holding USDC credits. The current mainnet manifest identifies that same vault as native ETH, with balances accounted for in whole gwei. Its explorer activity also shows ETH-valued deposits and close payouts.
CryptoSlate's February coverage examined the proposal. The mainnet implementation now gives withdrawal rights, deadlines and settlement dependencies practical significance.
Two routes out of a prepaid balance
Under the current protocol, a deposit funds a note. The wallet keeps the private spending state locally and uses proofs to authorize metered service. Individual API requests do not each move money onchain. 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 that has already authorized a request: the latter can be challenged if used to seek an escape payout.
That arrangement makes the spending state central to recovery. The vault can check a withdrawal proof against its rules, while 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 withdrawal 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 checks 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 handing over the money.
The public mainnet configuration specifies 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, provided 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 supplies an original request proof with the same nullifier as the attempted withdrawal. The proof establishes that the state 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 difference matters in a dispute. The escape route removes the need for the server's withdrawal clearance, but it does not let a user choose an arbitrary balance and have the contract accept it. If the state being 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 powers, expiry and the value of the balance
That vault code gives the owner a pause switch. Deposits, mutual close and initiation of new escape withdrawals all check it. An exit that needs no 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 is different 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.
The post Vitalik-inspired AI payment system can send expired deposits to its treasury appeared first on CryptoSlate.
