QENOVRA Whitepaper.

What is QENOVRA?

QENOVRA is a public blockchain and product stack for AI-agent payments and commerce. The core idea is not to give an AI unrestricted access to a user's private key. Instead, an Agent should operate within explicit authorization, budget, destination and time limits defined by the user.

A second loop lets the Agent become a provider: accept work → perform work → deliver → receive payment → account for costs and commission → show the user's net income.

System architecture

Capabilities already verified

• Public RPC: rpc-testnet.qenovra.com
• Explorer: explorer.qenovra.com
• Faucet: qenovra.com/faucet.html
• Developer Portal: qenovra.com/developers.html
• Wallet network addition, Faucet, A→B transfer, gas receipt, contract deploy/read/write/event/revert/source verification have been verified.
• Standard Hardhat and Foundry workflows completed deployment, interaction and verification. A 100-transaction stability run completed 100 successful / 0 failed transactions.
• Validator, Observer and Explorer completed controlled OS upgrade/reboot recovery. Sampled same-height block hashes and app hashes between Validator and Observer matched.

AI should complete service transactions, not only answer questions

The first implementation covers automated service purchase, merchant quote and delivery, payment authorization, delivery checks, receipts, retry handling, escrow timeout refund, restart recovery and duplicate-charge protection. Micropayments include channel limits, cumulative signed vouchers, batch settlement and close/refund behavior. PoAC includes paid-evidence registration, signature/receipt verification, Merkle proof support, deduplication and dispute flags.

AI Trading Agent + AI Service Agent

Model and API costs must be accounted for before execution

• An eligible new user receives a one-time 1.00 Promo AI Credit. The current baseline uses a 30-day expiry and the credit is non-withdrawable, non-transferable and non-exchangeable.
• AI calls are pre-authorized. If balance or budget is insufficient, the OpenAI call is not made.
• After a response, settlement uses actual token usage and releases unused reservations.
• The default customer charge is approximately actual provider cost × 2.0, configurable server-side.
• Single-task, daily and monthly budget protections are supported. Internal accounting uses integer nano-USD.

A separate total 25% commission design applies when an Agent generates actual realized net income for a user. Before release, this must be unified with Billing/Accounting into one authoritative ledger and settlement policy.

The wallet is the main user entry point

The target is a native, self-custody, multi-account, multi-chain wallet rather than a web shell. Key requirements include preserving existing wallets during app updates, randomized recovery-word verification, mnemonic/private-key/QR import, backup and recovery, prices and percentage changes, token discovery and new-token notices, asset detail, receive QR, send, history, network switching, DApp permissions, AI Work Center and automatic update detection.

V5 Native Core, AI Work Center and Billing are currently being developed on parallel branches. Final integration will start from the accepted main baseline, create an RC integration branch and resolve core-file conflicts before device acceptance.

Future Intent / Capability / Proof layer

QSL aims to let a user or Agent describe what should happen while Capability and permission boundaries define what is allowed to happen. Solver/Prover components then execute or prove the result across settlement networks. The foundation and deterministic Genesis E2E test pack have implementation work, but production privacy proof systems, a decentralized Solver network and production cross-chain settlement must not be presented as live today.

Planned QEN utility and Genesis V0.1 baseline

Planned utility includes mainnet gas, AI-agent operation and service settlement, PoS validation, Agent Commerce / micropayment / Solver-Prover economic coordination and ecosystem incentives.

How to participate today

Next product-development sequence

1. Wallet V5 native core
2. Deep QENOVRA wallet integration
3. Agent Identity
4. Spending Policy
5. Unified AI Billing
6. Service Discovery
7. Quote Protocol
8. User-goal decomposition
9. Escrow / Payment Authorization
10. Agent automatic payment
11. Automatic delivery
12. PoAC V2
13. Automatic acceptance and settlement
14. Wallet bills / receipts

Later stages include micropayments, Agent Store, Agent earning workflows, Developer SDK, multi-validator infrastructure, security audit and Mainnet preparation.

Hard gates before Mainnet

• Multi-validator Testnet plus consensus failure, recovery and upgrade validation.
• Freeze Mainnet Genesis, Chain ID, QEN issuance and allocation contracts, with reproducible hashes.
• Snapshot / State Sync, backups, cross-region disaster recovery and recovery drills.
• Independent security review of Chain / Wallet / Agent Payment / Billing / Escrow / PoAC.
• Production Android / iOS signing, migration and real-device acceptance.
• Limited real-value gray release, monitoring, incident response and Bug Bounty.