Frequently asked questions.

Zava is a privacy-preserving savings-and-credit reputation system on Stellar. You deposit funds into a shielded vault, prove consistent weekly savings with a zero-knowledge proof, and unlock a credit tier that lenders can query on chain — all without revealing your amounts, wallet history, or identity to the lender.

Freelancers, gig workers, remote contractors, and anyone paid in crypto whose income does not fit the salaried-employment shape traditional credit models expect. If you save consistently but have no bank-recognised paper trail, Zava turns your on-chain savings behaviour into a credit signal.

• 1. Install the Freighter browser extension (freighter.app) and fund it with testnet XLM using the built-in faucet.
• 2. Open Zava and click "Launch App". Freighter will pop up twice — once to approve the connection and once to sign an identity message. The signature stays in your browser.
• 3. Set a display name so the dashboard has something to greet you with.
• 4. Head to Deposit, and deposit into the Zava vault. Each deposit tags a "week number" — the circuit will later prove you saved consistently across N weeks.
• 5. After 8 qualifying deposits at the same range threshold, go to Credit Proofs and generate your first ZK credit tier claim.

Zava has no platform fee. Stellar network fees are a fraction of a cent per transaction. On testnet everything is free.

Zava is currently on Stellar Testnet. Mainnet deployment requires the smart-contract Merkle-tree fix (currently using SHA-256, upgrading to Pedersen or Poseidon2) and a security audit of the credit issuance logic. Testnet gives you the full experience end-to-end at zero real cost.

A cryptographic proof that lets you demonstrate a statement is true without revealing the data that makes it true. On Zava, your browser generates an UltraHonk proof asserting "I saved at least $X per week for N consecutive weeks." A verifier smart contract on Stellar checks the proof and issues you a credit tier — without ever seeing the individual deposit amounts.

• The exact amount you saved each week — the proof only reveals "≥ range threshold".
• Which of your on-chain commitments correspond to which deposit amounts.
• Your wallet's total balance across time.
• The private "secret" that binds each commitment to you — it lives only in your browser and is deterministically derived from a Freighter signature.

• The fact that a deposit happened (an opaque commitment gets added to the vault Merkle tree).
• The deposit amount at the moment of the transfer, because Stellar transfers carry an amount field. This is a known limitation of transparent asset transfers.
• The wallet address that made the deposit (required by Stellar for signature authorisation).
• The credit tier once you claim it (needed so lenders can query it).

Your wallet address, the credit tier issued to it (Medium / Low / VeryLow), the savings range you proved (e.g. "R20 = ≥ $20/week"), the number of active weeks proven, and the calculated loan cap. They cannot see your actual deposit amounts, individual commitments, or transaction timing.

Your Freighter wallet is secured by a 12-word recovery phrase. Restore that phrase on any device and your entire deposit history, credit tier, and vault balances come back with it. Zava never holds your keys or your funds — the vault contract only releases funds to whoever can produce a valid proof of ownership.

• Zava uses browser localStorage only as a cache — never as a source of truth. Everything critical is recoverable from two places you can rebuild from anywhere: your Freighter seed phrase, and the on-chain event log.
• The wallet secret is derived deterministically from a Freighter signature. The same wallet on any device produces the exact same secret. That secret is what unlocks your commitments — no server keeps it, no session token stands in for it.
• Every deposit emits an on-chain event with an AES-GCM-encrypted note. Your scan key (also derived from the same signature) decrypts it. Every partial withdrawal emits a similar event for the change UTXO. So even if you wipe localStorage, the next time you sign into Zava the app rescans on-chain events, decrypts the notes, and everything reappears.
• Scenario: laptop breaks, Freighter phrase safe → install Freighter on new device, sign in to Zava, deposits and credit tier reappear within seconds.
• Scenario: localStorage cleared, device fine → Freighter extension is unaffected. Signing in re-derives the secret, rescans events, rebuilds the cache.
• Scenario: Freighter phrase lost → funds are lost. This is the standard self-custody trade-off; Zava has no way around it because Zava never held your keys.

• zava.secret.v1.{address}: the derived secret, cached to avoid re-prompting Freighter every page load. Regenerated on demand from a Freighter signature if missing.
• zava.name.v1.{address}: your display name. Cosmetic only.
• zava.savings.v1.{address}: a list of your deposits for fast UI rendering. Source of truth is on chain; this is just a cache.
• zava.change.v1.{commitment}: change UTXO metadata from partial withdrawals. Now also emitted as an encrypted event on chain, so localStorage loss no longer means losing change tracking.
• zava.note.v1.*: sender-side backup of encrypted deposit notes. Recipient does not need them — they read notes from on-chain deposit events.
• None of these values are secrets that only exist here. Wiping localStorage costs you nothing more than a rescan next time you sign in.

Zava currently supports XLM (Stellar's native asset) and USDC (Circle's testnet stablecoin). Each asset has its own vault contract — XLM deposits go to one vault, USDC to another, so their Merkle trees stay independent.

The vault holds your tokens and records each deposit as a cryptographic commitment (a Pedersen hash of your secret and the amount). It also stores a "nullifier binding" so you can later prove you own a specific deposit without revealing which one. The amount you deposited is stored in the vault; the linkage between amount and depositor stays hidden behind the hash.

Yes. Withdraw and Partial Withdraw are both live in the dashboard. Withdraw releases the full amount of a specific deposit; Partial Withdraw releases a portion and creates a "change" commitment for the remainder. Both require a valid ZK proof — no one but you can spend your deposits.

A withdrawal marks that deposit's nullifier as spent. When you next claim credit, that week counts as withdrawn_weeks (not active_weeks). Your tier is calculated from active_weeks only, so withdrawing before proving credit reduces the tier you can claim.

The Receive page generates a URL containing your public Zava ID and scan key plus a fresh random nonce. Share it with anyone. When they open it, they can send you a payment that lands directly in the vault as a commitment tied to that nonce. You decrypt the note using your scan key to recover the deposit.

You pick a "savings range" (R5 = ≥ 50 XLM/week, R20 = ≥ 200 XLM/week, up to R500 = ≥ 5,000 XLM/week). The ZK circuit proves that you deposited at least that much for N consecutive weeks. Your tier depends on N: 8 weeks unlocks Medium, 12 weeks Low, 24 weeks VeryLow. Longer track record = lower risk tier = higher loan cap.

• 8 to 11 active weeks: Medium tier — 2× loan multiplier.
• 12 to 23 active weeks: Low tier — 4× loan multiplier.
• 24+ active weeks: VeryLow tier — 6× loan multiplier.
• Under 8 weeks: no tier issued.

loan_cap = active_weeks × range_lower_bound × tier_multiplier. Example: 12 active weeks at range R20 (200 XLM/wk) at Low tier (4×) → 12 × 200 × 4 = 9,600 XLM. All values are on chain in the ZavaCredit contract — nothing off-chain, nothing hand-waved.

Every CreditRecord expires 90 days after it is issued. This is a deliberate design choice — credit is time-sensitive, and a snapshot from six months ago does not reflect your current discipline. Re-prove when it expires, or when you want to reflect new savings behaviour.

The circuit enforces strictly monotonic week numbers (no reordering, no double-counting) with a maximum gap between consecutive weeks. If you skip a week, the sequence breaks — you have to start counting toward the tier threshold from the next uninterrupted run. Consistency is the entire signal.

No. The circuit asserts that every one of your N deposits was at least the range threshold you claim. If you deposited 100 XLM but claim range R20 (200 XLM/wk), the circuit rejects. You can always claim a lower range than you actually saved at — that just gets you a smaller loan cap.

Borrower shares their wallet address. Lender pastes it into the Lender Portal (or queries the ZavaCredit contract directly with any Soroban client). The portal reads the on-chain CreditRecord and shows tier, active_weeks, withdrawn_weeks, and loan cap. No credentials, no API keys, no gatekeeper.

• The borrower's wallet address.
• Their credit tier (Medium / Low / VeryLow).
• The savings range they proved (R5 to R500).
• active_weeks count and withdrawn_weeks count.
• loan_eligible_stroops (Zava's suggested loan cap in stroops).
• verified_at and expires_at timestamps.

The borrower's individual deposit amounts, their vault balance, which commitments they own, their withdrawal history in detail, or any identity beyond the wallet address itself.

Every tier issuance is preceded by a real UltraHonk proof verified on chain by a Soroban smart contract. The verification uses Stellar Protocol 26's native BN254 host functions — not a stub, not a wrapper, not "coming soon." You can watch these verifications happen live at /proof-log or filter for `honk verified true` events on Stellar Expert.

Zava does not manage loans, escrow, or repayment. It only issues credit signals. Default handling is the lender's responsibility, defined in whatever off-chain or on-chain agreement they set up. Zava's scope is: prove savings discipline, expose a tier on chain, get out of the way.

Stellar is a layer-1 blockchain optimised for payments — 3–5 second finality, sub-cent fees, native support for issued assets. Protocol 26 (Yardstick, live May 6 2026) added BN254 host functions via CAP-74, which is exactly what UltraHonk verification needs. Zava is one of the first projects to make production use of those precompiles.

Stellar's smart contract platform. Zava's savings ledger, honk_verifier instances, credit verifier, ZavaCredit, and shielded vault all run as Soroban WASM contracts. All contract source lives in the open repo.

Circuits are written in Noir 1.0.0-beta.9. Proofs use Barretenberg 0.87.0 UltraHonk (Aztec's reference SNARK). The on-chain verifier is a Rust port pinned to a specific audited commit. Browser proofs use @aztec/bb.js 0.87.0 — byte-identical output to the CLI prover, so a proof generated in your browser is guaranteed to verify the same way a CLI proof would.

Entirely in your browser, off the main thread, inside a Web Worker. Your secret never leaves the tab. The worker does the Pedersen hashing, executes the circuit witness, and produces the ~14 KB proof. Only the proof and public inputs get sent to Stellar — your amounts and private witnesses stay local.

The official Stellar browser wallet extension — the Stellar equivalent of MetaMask. It holds your keys, signs transactions, and lets you connect to apps. Zava derives your identity secret from a Freighter signature at connect time; that signature is what makes your vault recoverable on any device you log into with the same wallet.

Yes. Frontend, backend, and Soroban contracts are all public. Contracts + Noir circuits: github.com/Zavapa/Zava-contract. App: github.com/Zavapa/Zava. Audit the credit formula, the circuit assertions, and the verifier crate rev pinning yourself.