On-chain vs Off-chain Boundaries for RWA Compliance

Hook (keep visible before “see more”) In regulated tokenization, the hardest design decision is not the token standard. It is drawing a hard line: what must live on-chain, and what must never leave the off-chain compliance stack. 1. Why this boundary decides whether your RWA is real Real-world asset (RWA) programs fail in two opposite ways: Failure A — Everything on-chain Teams put PII, documents, workflow state, and “KYC JSON” into contract storage or events “for transparency.” Consequences: GDPR conflict: public, replicated, hard-to-erase personal data Irreversible disclosure: you cannot recall a mainnet event Wrong trust model: the ledger becomes a CRM with worse UX and worse legal posture Failure B — Everything off-chain The “token” is a row in Postgres with a wallet UI. Transfer rules live in PDFs and if-statements inside a private API. Consequences: No cryptographic enforcement: a compromised API can mint/move value Weak audit story: “trust our logs” is not what public-chain investors buy Regulated theater: compliance language without enforceable state Permissioned RWA needs a third path: Proofs on-chain. People off-chain. Enforcement in the token path. 2. A precise definition of the boundary Question | On-chain answer | Off-chain answer Who may hold? Identity registry / verification flag | KYC case file, vendor results. What may move? `canTransfer` + modules | Product policy, fee quotes, UX. What is the balance? Token ledger | Portfolio projections, fiat mirrors. What is the person? Hash / reference only | Name, docs, address, tax IDs. What if RPC dies? State unchanged, txs queue | BFF retries, degraded reads. What if BFF dies? Rules still enforced on next tx | Onboarding pauses; chain still gates. One sentence: Off-chain decides and evidences. On-chain enforces and proves. If your backend can silently bypass transfer rules, you do not have a compliance token — you have a trusted database with a wallet skin. 3. What belongs on-chain (checklist) Put on-chain only what must be globally consistent, adversarial-resistant, and auditable without trusting a single app server: Eligibility state — wallet verified / revoked (not the passport) Transfer constraints — pause, caps, jurisdiction/suitability modules Token economics — balances, supply, settlement semantics Agent roles (SoD) — who may register identity, mint, pause, force-transfer Events — immutable operational breadcrumbs (IdentityRegistered, Transfer, Paused) In an ERC-3643 / T-REX–style design, the chain answers: “Is this wallet allowed to send or receive right now?” It does not answer: “What is this person’s full legal file?” 4. What belongs off-chain (checklist) KYC/AML documents and raw PII Case management, reject reasons, analyst notes Sessions, MFA, device posture Wallet binding to an application user Bank/CRM/document-store integrations Product UX states: pending / approved / rejected / chain-error Heavy analytics and portfolio charts Store references and hashes. Drive human workflow. Only then call a privileged compliance path to register or revoke on-chain. 5. End-to-end flow (VaultGuard mental model) Investor signs up (BFF session + MFA) Binds wallet (wallet ↔ user integrity header) Submits KYC reference (document stays off-chain) Compliance reviews → approve/reject in issuer console On approve: compliance agent registers identity hash on-chain Token path: _update / transfer → registry + modular compliance Events → BFF audit trail + UI status + explorer link sequenceDiagram actor Investor participant UI as Next.js participant BFF as Spring BFF participant KYC as KYC refs participant RPC as RPC/Anvil participant IR as IdentityRegistry participant TK as PermissionedToken Investor->>UI: sign up / KYC UI->>BFF: session + doc reference BFF->>KYC: store hash/ref (no raw PII on-chain) Note over BFF,IR: issuer approve BFF->>RPC: registerIdentity(hash) RPC->>IR: verified wallet Investor->>UI: subscribe / transfer UI->>RPC: signed tx RPC->>TK: transfer gated by canTransfer TK-->>BFF: events / receipt 6. Threats this boundary reduces (and what it does not) Threat and Boundary effect: API compromised: Still cannot make unverified wallet receive if gates hold. PII breach on chain: Avoided if PII never written. Insider abuse: Reduced by SoD roles + timelock on upgrades. Key leak of one agent: Blast radius limited vs god-owner. Wrong human approval: Still possible — process risk remains off-chain. Architecture reduces technical bypass. It does not replace legal authorization, vendor diligence, or key custody discipline. 7. Interview / diligence questions that expose a weak boundary Can an unverified wallet receive if the API is compromised? Can we delete or minimize PII without breaking the ledger? Who can pause, register identity, or force-transfer — are roles separated on-chain? What is reconstructible from chain events alone vs what requires the BFF? Is upgradeability justified, and who holds UPGRADER_ROLE (timelock)? If answers are fuzzy, the architecture is fuzzy. 8. How VaultGuard RWA applies this Public PoC (active development - Layer | Stack | Responsibility): On-chain: Solidity, Foundry, ERC-3643 / T-REX–style | Registry, modular compliance, token gates, SoD agents. Off-chain: Java Spring Boot BFF | KYC refs, session, wallet binding, issuer ops. Client: Next.js, Wagmi/Ethers, MetaMask, Vercel | Investor + issuer UX. Rule of the house: no raw PII on-chain — hashes and registry proofs only. Demo: https://rwa-tokenized-compliance-system-fro.vercel.app/ Contracts: https://github.com/andreilopes11/rwa-tokenized-compliance-system-blockchain Backend: https://github.com/andreilopes11/rwa-tokenized-compliance-system-backend Frontend: https://github.com/andreilopes11/rwa-tokenized-compliance-system-frontend This is the same instinct used for years in banking architecture: clear trust zones, least privilege, auditability — now expressed as EVM state + BFF workflows. 9. Closing RWA compliance is not “add KYC to a token.” It is architecture: a deliberate on-chain / off-chain boundary, enforced by code, reviewable by auditors, and respectful of data protection. I build this in public while expanding from enterprise solution architecture into Solidity / EVM. If you work on tokenization, regulated DeFi, or Web3 solutions in the EU — let’s compare boundary diagrams. Educational content — not legal advice. Regulatory authorization remains the issuer’s responsibility.