Back to AadhaarChain
Identity Solana ONDC Agents

A digital identity you carry,
not one you keep asking for.

Today, proving who you are in India means handing over your Aadhaar each time and asking a central portal to vouch for you. AadhaarChain inverts that: verify once, anchor a wallet-bound proof on Solana, then decide what to reveal, to whom, and for how long. This explainer shows how the trust substrate works and how three apps — ONDC Buyer, ONDC Seller, and FlatWatch — consume it.

How to read this

Nine tabs on the left, in order. Why sets the premise, Substrate–Proof show the mechanism, the three app tabs show consumption, and Agents + Boundary close the loop.

One sentence each

AadhaarChain verifies you once and issues wallet-signed proofs. ONDC Buyer/Seller use those proofs to gate commerce. FlatWatch uses them to make society finance accountable.

00 / 09

01 · Premise

The problem with centralised identity.

Today

Every vendor, bank, broker, society, and marketplace pings a central portal, receives your full Aadhaar profile, and keeps a copy. You re-do KYC everywhere. You can't see who has your data, can't revoke it, can't carry it across borders.

The bet

Verify once at the government source, anchor a wallet-bound proof on Solana, then re-use it everywhere as a short-lived, audience-bound, consent-scoped signature. Reveal only what's needed.

CENTRALISED · TODAY You Gov portal Bank Vendor Society App Re-verify every time. Full data copied. No revocation. DECENTRALISED · AADHAARCHAIN You + wallet AadhaarChain substrate ONDC Buyer ONDC Seller FlatWatch Any new app verify once Verify once. Prove selectively. Revocable. Portable.
The same person, two regimes. Left, identity flows to every counterparty. Right, identity stays with the user; only short signed proofs cross.
01 / 09

02 · Architecture

The trust substrate, end to end.

AadhaarChain splits into a trust producer (the only place that ever sees raw Aadhaar/PAN/OCR) and a trust consumer contract that downstream apps speak. Raw identity never crosses the dashed boundary.

TRUST PRODUCER · AADHAARCHAIN Raw Aadhaar / PAN / OCR stays inside this boundary. Verifier(s) OCR · doc check Trust state store wallet → status FastAPI gateway · :43101 /api/identity · /trust · /proof-token Frontend dashboard · :43100 verify · sign · review · revoke Solana anchor (aadhar-solana) registry · oracle · credentials · reputation Never on-chain: raw Aadhaar/PAN/OCR, transferable identity credentials. User wallet Phantom · Solflare TRUST CONTRACT GET /trust POST /proof-token ONDC Buyer · :43102 search · cart · checkout · buyer agent ONDC Seller · :43103 catalog · orders · payouts · seller agent FlatWatch · :43104/05 society ledger · receipts · challenges · audit Shared agent control plane · :8100 Claude Agent SDK · audit · approvals
Orange paths carry signed identity proofs and trust reads. The dashed orange ring is the data boundary — what is inside never leaves; what is outside never enters as raw evidence.
02 / 09

03 · Interface

The contract apps actually call.
EndpointPurpose
GET /api/identity/{wallet}/trustReturns verified, pending, unverified, or revoked + a safe summary.
POST /api/identity/{wallet}/proof-tokenIssues a 5-minute, audience-bound challenge — only if wallet is verified.
POST /api/identity/proof-token/verifyChecks the exact message, wallet, audience, expiry, and ed25519 signature.
GET /api/identity/status/{verification_id}Status, plus review and revocation paths inside the producer.
The two-step proof. An app never gets a reusable identity blob. It gets a challenge for a specific purpose (e.g. buyer_checkout_identity_proof), the user's wallet signs it, the gateway verifies. The proof is meaningless to anyone else and expires in minutes.
03 / 09

04 · Sequence

Identity proof signing.

Every high-trust action across the portfolio — checkout, publish a listing, raise a society challenge, an agent write — is gated by this same eight-step sequence.

User · wallet App frontend App backend AadhaarChain gateway 1 · "Sign identity" (purpose attached) 2 · POST /proof-token (wallet, audience) 3 · 5-minute challenge (only if verified) 4 · ask wallet to sign exact message 5 · ed25519 signature returned 6 · POST /proof-token/verify (msg + sig) 7 · ok → backend trusts this purpose 8 · "Identity signed" · action unlocked
Time flows down. Each step labels itself directly — no legend required.
Frontend "Identity signed" badges are guidance. Any real state change is re-enforced server-side by re-reading trust and re-verifying the proof.
04 / 09

05 · App I

ONDC Buyer — the consumer side of decentralised commerce.

What it solves

An ONDC buyer app where the shopper is identified by a portable wallet identity rather than a marketplace account. Discovery, cart, and checkout degrade gracefully for unverified users; high-trust actions unlock only when an identity proof is signed for that specific checkout.

Routes

SearchPage → ResultsPage → ProductDetailPage → CartPage → CheckoutPage → OrdersPage. Plus AgentChatPage at /agent. Signs purpose buyer_checkout_identity_proof.

Connect wallet Phantom · Solflare Search /search Product /product/:id Cart /cart Checkout trust-gated Order placed /orders/:id CHECKOUT GATE 1 · read trust(wallet) 2 · if verified → enable button 3 · request proof-token 4 · wallet signs message 5 · gateway verifies signature 6 · server-side commerce policy applies /agent — Buyer agent (Claude Agent SDK) talks to shared agent control plane :8100 "Find me X under ₹Y, prefer verified sellers" → tool-calls search/cart high-trust writes require fresh identity-proof on the chat surface every agent action lands in the audit log
Five steps to a placed order. The checkout gate expands one of those steps; everything else stays unchanged whether the user is verified or not.

Buyers are pseudonymous-but-verifiable — the seller never sees Aadhaar, only that this wallet has a verified identity and signed for this checkout. The same wallet works across any ONDC node.

05 / 09

06 · App II

ONDC Seller — trust-gated catalog and payouts.

What it solves

Onboards sellers using their wallet identity. Listings, price changes, order acceptance, and payouts are gated on verified trust plus an audience-bound signature — so a buyer (or a society) can be confident the vendor they transact with is the same accountable identity that signed up.

Action policy

View · draftauth / wallet subject
Publish · edit · priceverified + server policy
Accept · dispatch orderverified + server policy
Payout / configverified + server policy
Agent-originated writeverified + approval + audit
Login + wallet /login Dashboard trust badge · KPIs Catalog draft · publish Orders accept · dispatch Payouts · Config /config SERVER-SIDE ENFORCEMENT GATEWAY Vercel / Netlify serverless · sellerBackendEnforcement.ts 1 · session check 2 · re-read trust 3 · enforce seller policy 4 · audit + proxy commerce Catalog, order, and payout writes are accepted only if all four pass. Frontend gating alone is never trusted in production.
The frontend (top row) is where the seller works. The bottom strip is where their work is actually authorised. The three vertical orange arrows mark every action that hits the enforcement path.

Combined with on-chain reputation signals from aadhar-solana, this is the substrate for a trust score per seller: verified identity + signed actions + reviewed history.

06 / 09

07 · App III

FlatWatch — accountable society finance.

The problem

In Indian housing societies, committee members handle the maintenance fund. Cash transactions, opaque vendor sourcing, and missing receipts make it trivial to skim money or favour friendly vendors. Residents see a charge — they don't see where it went.

The fix

Every society transaction is online and signed by a named, AadhaarChain-verified committee member. Receipts are uploaded and OCR-reviewed. Residents can raise challenges. Sourcing happens through ONDC: society opens a bid, ONDC sellers compete, the winning quote is paid against a receipt. A Chat Guard agent flags anomalies in real time.

Resident views · raises challenge Committee member verified · signs spends Society ledger /transactions · /receipts · /challenges every row has a signed identity Chat Guard agent Claude Agent SDK · /chat flags anomalies · drafts disputes Audit · /audit resolve challenge · annotate receipt Sourcing bid · ONDC Buyer society opens bid for material checkout signed by committee ONDC sellers compete verified vendors quote trust score visible Receipt → ledger tx · vendor wallet · order id automatic reconciliation Why this kills corruption no anonymous spend — wallet + name on every row sourcing must go through ONDC bids verified vendors only · trust score visible residents can challenge any line AI flags large or odd withdrawals to the group every receipt is OCR-matched to a tx nothing in the ledger is mutable without audit
People on the left, ledger in the middle, ONDC sourcing on the right. Orange arrows are signed (identity-bound) writes; gray arrows are reconciled receipts that close the loop.
07 / 09

08 · Intelligence

The AI & UCP layer.

All three apps share one Claude Agent SDK runtime — the agent control plane on port 8100. Each app exposes an agent surface. UCP — Google's Universal Commerce Protocol — is the message contract that lets buyer and seller agents negotiate without a human in the loop while still respecting identity gating.

Shared agent control plane · :8100 Claude Agent SDK · tool registry · approvals · audit re-reads trust before every write tool Buyer agent search · compare · negotiate via UCP human signs checkout Seller agent respond to UCP offers · draft listings writes require verified + audit FlatWatch Chat Guard anomaly detection · dispute drafting flags to all residents UCP
Three agents, one runtime. Every write is re-checked against AadhaarChain trust before it lands.
Why this is safe. Even an autonomous agent cannot do anything a human hasn't authorised. Every write tool re-reads trust at call time, and irreversible steps require a fresh human-signed identity proof. The agent is a co-pilot, not a key holder.
08 / 09

09 · Boundary

What crosses, what doesn't.

Crosses to apps

Trust status (verified, pending, unverified, revoked); safe summary (wallet, audience-bound proof receipt); signed challenge plus verification result; audit references and revocation events.

Never leaves AadhaarChain

Raw Aadhaar or PAN numbers; OCR text; verifier internals; transferable on-chain identity credentials; anything that would let a downstream app re-identify the user against the government registry.

Where this is going

Today the active trust producer is the FastAPI gateway. The aadhar-solana Anchor program suite — identity registry, verification oracle, credential manager, reputation, staking — is the long-term substrate. Once the bridge (verification event schema, signer/oracle identity, attestation format, revocation propagation) is verified, trust state moves on-chain and the same trust contract keeps working. Apps don't need to change. The identity becomes truly yours: anchored on a public chain, portable across borders.

09 / 09