Vara Network

every ecosystem has things people wish someone would build. better tools. clearer documentation. infrastructure that stays maintained. useful ideas that are still too early to make money. eventually, someone has to decide which of those things deserves funding. that is why @VaraNetwork referendum #90 matters moree it asks whether the community should have its own treasury, with funds belonging to the network and spending decided by vara holders through referendums. when you use an ecosystem, you notice things a roadmap can miss. a frustrating onboarding step. a missing integration. a tool everyone needs but nobody has a clear incentive to maintain. a community treasury could give that work a route to funding. but we should be precise about this vote. vara already has treasury functionality and spending tracks. referendum #90 records whether the community wants a treasury put to use. it moves no funds and changes no network rules. an aye supports the principle. funding sources, budgets, and individual spending decisions would still need to be worked through separately. that is where the harder work begins. community control means reading proposals, questioning costs, and checking whether funded work actually helped anyone. can we question a proposal from someone we like? give maintenance the same attention as a new launch? admit when something we supported has not worked? those habits would matter as much as the money. i would want anyone requesting funding to explain the need, the cost, the deliverables, and how progress can be checked. new contributors should have a fair chance. previous recipients should expect questions about results. what makes #90 meaningful is the responsibility it asks holders to consider. do we want to help decide what gets funded, and stay involved after the vote? if you hold vara, read the proposal. think about what you would want a treasury to support and what standards you would expect. bring those expectations into the discussion. read the proposal and check the live voting status: 👇

spent some time reading about zkAPI today and kept thinking about what happens when this goes beyond one operator right now the idea is fairly simple: deposit once on @ethereum, prove you can pay, and get short-lived API access without attaching your wallet or identity to every request but say I want to use that balance across different services maybe an AI model, an RPC, an image generator and a VPN all of them need to know that the same private credit hasn't already been spent elsewhere ethereum can keep track of it, but checking L1 before every API call would be painfully slow - one operator could maintain the state offchain, but then every provider is back to depending on the same middleman I wonder if eth.vara.network could sit between these two options not for the prompts or the actual inference. those should still go directly from the user to the provider each provider could run its own Vara.eth program in parallel - those programs would handle their own pricing, reservations and usage receipts, while messaging one shared registry program that only tracks nullifiers before accepting a request, the provider's program asks the registry whether the nullifier has already been used. if it hasn't, the registry records it, and the provider gets that result back pre-confirmed by the validators the provider can then serve the request without waiting for Ethereum finality once the request is complete, it submits a signed receipt, any unused amount is unlocked, and the final balance eventually settles on Ethereum the user gets one private balance that works across independent services. each provider remains in control of its own program, but the same credit can't be accepted twice anywhere this seems like a fairly natural use of vara.eth the provider programs can run independently and in parallel, while the registry gives them one shared view of spent nullifiers. the provider can cover execution through reverse gas, and ethereum remains the place where the actual funds live proof verification needs to be benchmarked, providers would need a common receipt format, and the security assumptions around accepting a pre-confirmation but the direction feels overall useful zkAPI has made private API payments possible - the next interesting question is whether those credits can work across an open market of providers instead of staying behind one operator open to questions, so feel free to drop them below

wrote about vara.eth preconfirmations, then built the full flow to see what it actually feels like ~200ms preconfs. five order-book programs. @ethereum settlement. a passkey wallet. all measured live. go build 👇