Private financial coordination for teams operating on Starknet.
_{PREPARE INTENT · AUTHORIZE WITH A WALLET · VERIFY A RECEIPT · REVEAL ONLY THE PROOF}

Live workspace · 90-second reviewer path · Architecture · Threat model · Decision record · Mainnet readiness · Film library

---

The reviewer promise

In ninety seconds, you should know what Veyra does, where privacy lives, who can authorize a state change, what proves settlement, and what remains deliberately unfinished.

Veyra is an institutional operating layer for private financial coordination. It turns a team’s private operating record—payroll roster, approvals, policies, claims, allocations, bids, and milestones—into a controlled sequence that stops at the wallet boundary. Only a user-owned Starknet wallet can authorize a transaction. Only a verified receipt can settle a route. Only a settled route can issue a constrained proof.

PERSISTED INTENT  →  WALLET AUTHORIZATION  →  SUBMITTED TRANSACTION  →  CONFIRMED RECEIPT  →  SELECTIVE PROOF

This repository is designed to make that sequence inspectable. It is not a landing page with a backend attached; it is a full-stack product, a proof-boundary model, a Cairo commitment package, a test suite, an operations guide, and a transparent record of what still requires a real owner-operated mainnet release.

---

The 90-second path

Time	Do this	What it demonstrates
00:00	Watch the 90-second 4K60 Demo	The official submission film: Veyra’s privacy thesis, protocol members, and judge-facing product path.
01:30	Open the live workspace	Routes, roles, operations, wallet state, proof ledger, Launchpad, Private Markets, and Veyra Agent are product surfaces—not mock cards.
02:00	Read the architecture	The browser, account API, database, wallet, RPC provider, and Cairo registry sit in distinct trust domains.
02:30	Verify the evidence	Follow the exact code paths for receipt verification, proof gating, risk enforcement, and the Mainnet evidence package.

---

Film library

Playback note. GitHub sanitizes external HTML <video> embeds in repository Markdown, which can leave a film heading with no visible player. The previews below are intentionally clickable: each opens the original MP4, while the live Veyra Documentation room provides the native, inline video players.

Film 01 — The thesis

The stable 30-second teaser establishes Veyra’s visual system and its private-to-proof operating principle. Play the original MP4 or watch inline in the Veyra Documentation room.

Demo — 90-second 4K60 judge cut

The official 90-second 4K60 Demo gives judges a concise pass through Veyra’s privacy thesis, protocol members, Mainnet evidence surfaces, and wallet-to-receipt boundary. Play the official Demo or watch inline in the Veyra Documentation room.

---

What the system is built to protect

Four non-negotiable invariants

Invariant	Why it matters	Code-backed behavior
The wallet signs; Veyra coordinates.	A workspace tool must not quietly become a key custodian.	No seed phrase, private key, recovery phrase, or keystore is accepted or stored.
A hash is not a receipt.	A submitted transaction can remain pending, fail, revert, or target the wrong network.	Receipt lookup classifies confirmed, reverted, or unknown; no local hash is treated as finality.
A proof is smaller than the private record.	Public verification should not reopen a private roster or sealed bid book.	Proof creation is settled-route gated and the public query returns a constrained summary.
Policy must run on the server.	A decorative warning can be bypassed; an enforced rule cannot be skipped through a client call.	Role, approval, treasury, lifecycle, and bid-risk checks execute in tRPC/database paths.

Read the complete Threat Model and Security Posture for assets, attack scenarios, controls, residual risk, and explicit non-goals.

---

Visual architecture

Domain	Purpose	Trust boundary
React + Vite client	Workspace UI, route composition, wallet state, documentation, public proof/claim views.	The client is never the authorization authority.
Express + tRPC API	Typed procedures, membership/role checks, lifecycle controls, audit records, receipt lookup.	Server resolves user + workspace; protected actions do not trust client-supplied identity.
MySQL/TiDB + Drizzle	Workspace coordination state: routes, recipients, policies, claims, markets, audit, transaction references.	Workspace predicates constrain records; secrets are out of scope.
Starknet wallet	Account, network, user review, signature, and submission.	User-controlled signing authority.
Starknet RPC	Public receipt execution and finality lookup.	Receipt is a verification input, not a signing mechanism.
Cairo registry	Non-custodial route and settlement commitment records.	No token custody or transfer semantics.

The deep architecture package includes OAuth sequence diagrams, entity model, state machines, role matrix, deployment topology, configuration contract, and exact source paths: docs/ARCHITECTURE.md.

---

STRK20 protocol alignment

Veyra is aligned to the public STRK20 reference model rather than treating privacy as a visual label. STRK20 is a note-based pool: registration and wallet-owned note discovery precede private balances and transfers, zero-knowledge proofs are verified by the protocol, and public deposits, withdrawals, and timing remain visible. The product therefore separates intent, wallet authorization, submitted hash, verified receipt, and selective proof instead of collapsing them into one optimistic status.

Reference	What Veyra takes from it	What Veyra deliberately does not copy
STRK20 by Example	Registration, note discovery, public/private edges, actions, phases, proofs, and compliance boundaries.	It does not claim that a public receipt proves private-note discovery or recipient delivery.
STRK20 Starter Kit	WalletAccountV6-era Wallet API concepts, explicit wallet actions, and the rule that demo helper values stay labeled as demo.	It does not import the starter’s echo helper or placeholder contract as production settlement logic.
Starknet privacy source	The separation between SDK, discovery, proving, pool, anonymizer, E2E, and audit layers.	It does not present an unaudited custom anonymizer or fund-moving Cairo contract as shipped infrastructure.
STRK20 skills · Awesome STRK20	A maintained map of the official Wallet API, Privacy SDK, helper-contract, and ecosystem references.	It does not copy external repositories wholesale; only source-verified, regression-tested behavior belongs in Veyra.

This distinction is intentional. A generic Starknet execute call is not equivalent to the official private wallet action, and a locally prepared route is not a Mainnet result. Veyra remains Mainnet-only, wallet-owned, receipt-first, and fail-closed when a wallet lacks the required STRK20 capability or protocol registration.

---

Product system

Surface	What it coordinates	Enforcement boundary
Private payroll	Recipient routes, schedules, approvals, transaction references, audit, and proof eligibility.	Only permitted roles mutate routes; settlement requires approvals and verified receipt status.
Treasury and operations	Per-token/network policy, daily limits, approval thresholds, schedule state, health, and CSV audit exports.	Policy evaluates before protected route workflow persistence.
Claims and selective proof	Time-bounded claim records and receipt-gated proof slugs.	No proof before settlement; public proof excludes private allocations and roster data.
Launchpad governance	Projects, commitments, allocations, milestones, release requests, readiness, and operator controls.	These are coordination records until a wallet-approved, externally confirmed execution exists.
Private Markets	RFQs, sealed bid commitments, encrypted-term fields, risk policy, alerts, portfolio math, and lifecycle.	Live window, deadline, amount, concentration, cap, capacity, accepted-allocation, and role checks run server-side.
Documentation	Film library, operating model, security posture, architecture, reviewer guide, and decision record.	Every material claim points to source, product state, or an explicit owner-operated boundary.

---

State is evidence, not decoration

State	What is true	What is deliberately not implied
Persisted	An authenticated workspace record exists.	A transfer, signature, or public transaction exists.
Unsigned	A claim, allocation, proposal, or proof candidate has been prepared.	A wallet has approved it.
Wallet pending	The app has reached the user-owned authorization boundary.	The user will approve or the transaction will succeed.
Submitted	A unique transaction hash is bound to a route and network.	The receipt is final or the route is settled.
Confirmed receipt	RPC reports succeeded execution plus accepted finality.	Private roster, allocation, or bid data becomes public.
Demo Mode	Deterministic local explanation state is visible.	Mainnet evidence exists.

The lifecycle itself is enforced, not merely displayed. See the exact route and market state diagrams in Architecture, then inspect transitionPaymentRoute, confirmBlockchainTransaction, createShareableProof, updatePrivateMarketStatus, and commitPrivateMarketBid in server/db.ts.

---

The decisions behind the product

Veyra’s most important design choices are constraints, not feature claims. It uses a wallet-owned signing boundary rather than custodial key handling; a receipt-derived confirmation state rather than a locally trusted hash; a proof surface smaller than the private operating record; server enforcement rather than dashboard-only warnings; a non-custodial Cairo registry rather than pretending to ship an audited escrow; and Demo Mode as explanation rather than evidence.

Read the complete Decision Record to understand the trade-offs, consequences, and intentional non-goals.

---

Proof of work

Evidence	Where to inspect	What it proves
Product	Live workspace	The designed operational surface and state language are live.
Film	Direct players in the Film library	Product narrative and end-to-end guided context.
Backend	server/routers.ts · server/db.ts	Protected procedures, workspace scoping, policy and receipt gates, persistence, audit behavior.
Lifecycle logic	shared/operations.ts	Shared market transition, risk, policy, disclosure, and scheduling logic.
Data model	drizzle/schema.ts	Typed tables for workspaces, routes, claims, policy, launch governance, markets, transactions, and audit events.
Cairo boundary	contracts/veyra_payroll	Non-custodial commitment registry and its explicit deployment boundary.
Verification	pnpm test && pnpm build	175 Vitest tests across 42 files and a passing production bundle build at the latest hardening verification.

---

Documentation map

Document	Purpose
Reviewer Guide	Exact 90-second evaluation path, inspection tasks, and evidence levels.
Architecture	System context, trust domains, OAuth sequence, persisted model, role matrix, lifecycle, deployment, and code map.
Threat Model	Assets, threat scenarios, controls, residual risks, and non-goals.
Decision Record	Product/engineering trade-offs that keep Veyra’s claims honest.
Operations Guide	Controls, reviewer path, local verification, release gates, and incident posture.
Cairo Registry README	Contract scope, build, Sepolia workflow, and production limits.
Evidence Handoff	Completed assets and user-owned mainnet/repository release steps.

---

Veyra Agent — sealed coordination on Mainnet

Veyra Agent is a dedicated Starknet protocol member for wallet-assisted commit–reveal coordination. It is not an autonomous custodian and it does not hold private keys. The browser prepares a round payload; the connected Starknet wallet signs each state-changing call; the deployed Cairo coordinator records the lifecycle and exposes read-only state for inspection.

CREATE ROUND → OPEN COMMIT WINDOW → COMMIT POSEIDON HASH → CLOSE WINDOW → REVEAL VALUE → RESOLVE RECIPIENT

Mainnet evidence	Verified reference
Veyra Agent coordinator	0x07d0e03a…a9d61f69
Declared class	0x44d4d37b…d2fc91
Declaration receipt	0x0667be71…732bbaa
Lifecycle resolution receipt	0x02ab82ec…c76a0a5

The lifecycle evidence demonstrates contract deployment, state transitions, commitment matching, and resolution. It does not prove that wallet callers are anonymous, that revealed values are private after reveal, or that public transfers disappear. Those limits are intentional and are repeated in the product UI so reviewers can distinguish contract state from a broader privacy claim.

Current protocol members

Member	Role	Evidence posture
Private Payroll	Coordinate recipient routes, approvals, schedules, and receipt-gated proof.	Workspace state is separate from wallet-authorized settlement.
Launchpad	Govern private project rooms, allocations, milestones, and release intent.	Mainnet contract and receipt links are exposed in the dedicated panel.
Private Markets	Coordinate RFQs, sealed bid commitments, risk policy, and settlement lifecycle.	Contract state, bid state, and settlement evidence are separated.
Private Primitives	Explain and prepare privacy-oriented STRK20 boundaries.	Wallet-owned discovery and privacy limitations remain explicit.
Veyra Agent	Coordinate sealed decisions through commit–reveal–resolve.	Mainnet deployment and lifecycle receipts are linked above.

Operating boundaries

Veyra coordinates; the wallet authorizes. No seed phrase, private key, recovery phrase, or keystore is accepted or stored.

A submitted hash is not a receipt. Product evidence distinguishes prepared intent, submitted transaction, confirmed receipt, and selective proof.

A public receipt is not private-note proof. STRK20 discovery, registration, proving, public edges, and recipient privacy are separate claims and must be evidenced separately.

Run the system

Prerequisites

Use Node.js 22, pnpm 10, a MySQL/TiDB database you control, and the Manus OAuth environment contract defined in server/_core/env.ts. Keep DATABASE_URL, JWT_SECRET, OAuth settings, RPC credentials, and all wallet material outside the repository.

pnpm install
pnpm dev

Run the product verification suite and production build:

pnpm test
pnpm build
pnpm start

For schema work, generate and apply migrations only against a database you control:

pnpm db:push

For the separate Cairo registry:

cd contracts/veyra_payroll
scarb build

---

Manual Vercel frontend deployment

The repository includes a Vercel-ready frontend deployment package. It serves the Vite application from Vercel and rewrites same-origin API and storage paths to the managed Veyra backend, preserving Veyra’s same-origin tRPC account contract without exposing backend secrets to the browser.

Included	Intentional boundary
vercel.json, .env.vercel.example, and docs/VERCEL_DEPLOYMENT.md	Vercel hosts the client and proxies /api/*; the managed backend retains the database, protected API, Veyra account verification, receipt verification, and server-only credentials.

Before a manual Vercel deployment, set only the documented safe public Vite values. The deployed account flow uses same-origin /api/* rewrites to the managed backend; it does not require an external OAuth callback allowlist. The deployment guide provides the exact import, environment, verification, and rollback-safe sequence.

---

Release posture

Ready now	Requires owner-operated evidence or further engineering
Full-stack workspace, typed API, database model, protected workflow, lifecycle semantics, audit events, policy/risk controls, documentation system, product films, Vercel judge path, three verified public STRK20 pool receipts, and Cairo commitment source.	Recipient-wallet private-note discovery for the historic transfer, any fund-moving Cairo interface, independent contract review, and owned production observability.

Root strk20.json contains exactly three verified successful Mainnet STRK20 privacy-pool transaction hashes. These public receipts establish pool interaction, not Veyra-originated recipient-note delivery; the historic recipient outcome remains explicitly unresolved. No transaction hash, deployed contract address, settlement status, audit result, or testimonial is fabricated in this repository.

For STRK20 program context, see the Starknet STRK20 Private Sprint page 1.

---

Veyra
_{PRIVATE FINANCIAL COORDINATION · WALLET → RECEIPT → PROOF}

MIT License

References