Sunanda Vempati
Resume
Architecture

How I think about blockchain architecture

I approach blockchain architecture as system design across trust boundaries, not as isolated smart-contract development.

01Architecture philosophy

From requirements to operations

Contracts are one layer of a blockchain system. The trust model is decided before them, and operations continue long after them.

Many blockchain incidents are not coding errors but unexamined trust assumptions — an admin key, an oracle, a bridge, a deployment step — that nobody designed for.

  1. Requirements
    Business outcome, regulatory context, operators and users
  2. Trust Model
    Who is trusted for what — keys, oracles, bridges, custodians, admins
  3. Architecture
    Contract boundaries, token lifecycle, chains and upgrade model
  4. Smart Contracts
    Implementation against agreed interfaces and invariants
  5. Security Controls
    Role separation, privileged paths, pause and recovery
  6. Integration
    Backend, APIs, wallets, custody and compliance services
  7. Deployment
    Deterministic, scripted, verified on every network
  8. Operations
    Runbooks, monitoring and controlled change after launch
02System domains

The shape of the systems I design

Each domain has a characteristic flow and a characteristic set of questions it has to answer.

Token Infrastructure

Lifecycle
  1. Token
  2. Deployment
  3. Vesting
  4. Staking
  5. Treasury
  6. Bridge
  7. Multi-chain

A token is a system, not a contract. Issuance, release schedules, incentives, treasury custody and cross-chain supply each carry their own roles, failure modes and operational owners.

  • Who can mint, pause or upgrade — and through which multisig
  • Vesting and staking contracts that cannot drain treasury under edge cases
  • One canonical supply across every chain the token lives on
  • Identical, verifiable addresses so integrators trust what they see
Applied in RBC / FRK

Real-World Assets

Compliance
  1. Asset
  2. Identity
  3. Compliance
  4. Registry
  5. Token
  6. Controlled Transfer
  7. Custody

RWA tokens must enforce off-chain rules on-chain. Transfers are only valid between verified identities, under jurisdictional and lock-up rules, with privileged agents for recovery and enforcement.

  • Identity and claim verification before any balance moves
  • Modular compliance rules that can evolve without redeploying the token
  • Agent permissions: freeze, force-transfer and recovery, tightly scoped
  • Institutional custody with approval policies for issuer and treasury flows
Applied in RealProton

DeFi Protocol

Solvency
  1. Collateral
  2. Oracle
  3. Lending
  4. Borrowing
  5. Interest
  6. Liquidation
  7. Treasury

Lending protocols are solvency machines. Every design decision — collateral factors, oracle choice, liquidation incentives — is ultimately about keeping the system over-collateralised under stress.

  • Oracle freshness, manipulation resistance and fallback behaviour
  • Collateral-ratio thresholds tuned per asset risk profile
  • Liquidations that remain profitable to execute in volatile markets
  • Reserve accounting and recovery paths when positions go under
Applied in USDAO

Blockchain-backed Metaverse

Ownership
  1. Digital Identity
  2. Wallet
  3. Digital Assets
  4. NFT
  5. Ownership
  6. Smart Contracts
  7. On-chain Interaction
  8. Metaverse Ecosystem

When blockchain is the foundation of a metaverse rather than a feature, identity, assets and ownership become shared primitives. Every other component — DAO, DeFi, the experience itself — trusts what the contracts say a user is and owns.

  • Identities that evolve without losing ownership or authenticity
  • Explicit ownership models for every asset type
  • Permissioned metadata changes, so tokens keep their meaning
  • Interfaces other components can rely on as the ecosystem grows
Applied in Maavatar
03Architecture decision records

Decisions, with their trade-offs

Context, decision, reasoning, trade-off and impact — the parts of a decision that matter after the code ships.

ADR-01Why CREATE2?Deterministic deployment gives one predictable address on every EVM network — easier to integrate, verify and trust.
Context
Multi-chain tokens are easier to integrate, audit and trust when the contract lives at the same address everywhere.
Decision
Deploy through a CREATE2 factory with identical init code on every EVM network, moving chain-specific configuration into protected post-deploy initialisation.
Why
  • Address = keccak256(0xff ‖ deployer ‖ salt ‖ keccak256(initCode)) — deterministic and computable before deployment.
  • Identical addresses require an identical deployer (usually a factory at the same address) and identical init code, including constructor arguments.
  • Chain-specific configuration should move out of the constructor into post-deploy initialisation, so init code stays the same.
  • Salts and deployer keys become part of the release process — they need the same care as any other deployment secret.
Trade-off
Determinism pushes configuration into initialisation functions, which must then be protected against front-running and double-initialisation.
Impact
One verifiable token address across EVM networks, and releases that can be reproduced and checked before deployment.

Applied in: RBC / FRK · G Future Tech multi-chain token infrastructure

ADR-02Why ERC-3643?Compliance-oriented tokenization: transfers only succeed between verified identities under modular transfer rules.
Context
Securities-style real-world assets cannot be freely transferable bearer tokens. The token must know who may hold it.
Decision
Model regulated assets as ERC-3643 permissioned tokens: identity registry, claim topics, trusted issuers and a modular compliance contract, with tightly scoped agent roles.
Why
  • Transfers are gated by an identity registry: sender and receiver must hold verified on-chain identities.
  • Claim topics and trusted issuers define which attestations (e.g. KYC, jurisdiction) are required.
  • A modular compliance contract enforces rules — country restrictions, holder limits, lock-ups — without changing the token.
  • Agent roles support freezing, forced transfers and wallet recovery, which regulated assets need but which must be tightly governed.
Trade-off
Compliance adds gas cost and integration complexity, and concentrates power in agent roles — so custody and role design matter as much as the token.
Impact
Transfer eligibility is enforced at protocol level, and compliance rules can evolve without redeploying the token.

Applied in: RealProton · compliance-ready RWA tokenization

ADR-03Why ERC-1155?Flexible multi-token contracts for identities, tiers and dynamic digital assets in one place.
Context
Ecosystems with identities, tiers and many asset types need more than one-token-per-contract NFTs.
Decision
Represent identities, NFT tiers and digital assets as ERC-1155 token classes, with metadata evolution restricted to permissioned paths.
Why
  • One contract can hold many token classes — identities, NFT tiers and fungible or semi-fungible assets.
  • Batch transfers and mints reduce gas and simplify multi-asset interactions.
  • Per-token metadata URIs support dynamic metadata, but mutation rules must be designed explicitly.
  • Wallet and marketplace support is broad, which matters for ownership users can actually see.
Trade-off
Flexibility moves design burden into the contract: what each token ID means, who may change its metadata, and how supply is controlled must all be defined up front.
Impact
Many asset types in one contract, batch operations, and identities that evolve while ownership stays stable.

Applied in: Maavatar · blockchain-backed metaverse identities and assets

ADR-04Why LayerZero / OFT?One logical token supply across networks, moved by messaging between trusted peers rather than wrapped copies.
Context
A token that lives on several chains needs a single, coherent supply rather than a set of unrelated wrapped copies.
Decision
Use a LayerZero OFT-oriented model with explicitly peered deployments instead of building a custom bridge.
Why
  • The OFT pattern debits on the source chain and credits on the destination, keeping total supply consistent across chains.
  • An adapter variant can wrap an existing token with lock-and-release where the original contract cannot change.
  • Each deployment must be explicitly peered with its remote counterparts; unpeered contracts must reject messages.
  • Security depends on verifier (DVN) and executor configuration — defaults should be reviewed, not assumed.
Trade-off
Messaging infrastructure removes the need to build a bespoke bridge, but introduces an external trust dependency that must be documented for stakeholders.
Impact
One logical supply across chains, with the cross-chain trust dependency made explicit and documented for stakeholders.

Applied in: RBC / FRK · LayerZero OFT-oriented bridging and cross-chain supply

ADR-05Why Fireblocks?Institutional custody and policy-driven approvals for the most privileged asset operations.
Context
Institutional issuers need to operate privileged roles — minting, treasury moves, agent actions — without single-key risk.
Decision
Hold privileged roles in policy-controlled Fireblocks vaults separated by responsibility — issuer, treasury, transfer vault, legal — with multisignature approvals.
Why
  • MPC-based custody removes single private keys from operational flows.
  • Vault separation maps naturally to responsibilities: issuer, treasury, transfer vault, legal / administrative.
  • Policy rules and approval quorums turn operational procedures into enforced controls.
  • Contract roles should be designed with the custody model in mind, not bolted on afterwards.
Trade-off
Custody platforms add operational dependency and cost; the benefit is auditable, policy-driven control over the most dangerous transactions.
Impact
No single key can execute issuer, treasury or agent actions, and every privileged approval is auditable.

Applied in: RealProton · G Future Tech wallet and treasury architecture

ADR-06EVM + SolanaOne product spec, two execution models — chain-appropriate implementations rather than forcing one chain's patterns onto the other.
Context
Serving users on both ecosystems means designing one product across two very different execution models.
Decision
Keep one product specification with chain-native implementations: CREATE2 and ERC-20 contracts on EVM, SPL tokens and program-derived addresses on Solana.
Why
  • EVM contracts own their storage; Solana programs are stateless and operate on accounts passed into each instruction.
  • Deterministic addresses: CREATE2 on EVM, program-derived addresses (PDAs) on Solana — similar goal, different mechanics.
  • Tokens: ERC-20 contracts per token on EVM vs the shared SPL Token / Token-2022 programs with mint and token accounts on Solana.
  • Tooling, fee models, account rent and upgrade authority all differ — so do the security review checklists.
Trade-off
A shared product spec with chain-specific implementations is usually safer than forcing one chain's patterns onto the other.
Impact
Each chain follows its own execution and security model instead of a lowest-common-denominator port.

Applied in: AppMindsGlobal multi-chain engagements

ADR-07Crypto-backed vs RWA-backed modelsCrypto and real-world collateral share infrastructure but need separate risk, pricing and liquidation rules.
Context
Financial infrastructure that accepts both crypto and real-world assets as collateral has to treat them as different risks inside one system.
Decision
Share infrastructure across crypto-backed and RWA-backed collateral while keeping risk parameters, pricing inputs and recovery paths per collateral type.
Why
  • Crypto collateral is liquid and priced continuously, but volatile — liquidation must be fast.
  • RWA collateral is more stable in value but illiquid and priced slowly — it needs conservative ratios and recovery paths beyond liquidation.
  • RWA brings eligibility and transfer rules (e.g. ERC-3643) that crypto collateral does not.
  • Oracle design differs: market feeds for crypto, valuation and attestation inputs for real-world assets.
Trade-off
Sharing infrastructure across both models reduces duplication, but only if risk parameters, pricing and liquidation are configured per collateral type.
Impact
Both models coexist without the volatile asset's rules governing the illiquid one, or vice versa.

Applied in: USDAO · G Future Tech financial infrastructure

ADR-08Blockchain-backed metaverse architectureDecide what the chain is the source of truth for — identity, ownership, interaction — and design everything around it.
Context
In a blockchain-backed metaverse, the chain is the source of truth for identity and ownership — so its design shapes the whole product.
Decision
Put identity, ownership and key interactions on-chain; keep rendering, media and AI off-chain.
Why
  • Decide early what lives on-chain (identity, ownership, key interactions) and what stays off-chain (rendering, heavy media, AI).
  • Model identities and assets as token classes with explicit ownership semantics.
  • Control how dynamic metadata can change, and by whom.
  • Expose stable interfaces so NFT, DAO and DeFi components can build on the same primitives.
Trade-off
Putting more on-chain increases trust and interoperability but adds cost and rigidity; the architecture has to evolve as product requirements change.
Impact
Shared primitives the rest of the ecosystem can trust, without paying on-chain cost for everything.

Applied in: Maavatar · Blockchain SME and core technical contributor

04Security architecture

Security as architecture, not a checklist

Each threat crosses a trust boundary. Controls sit on the boundary, and every control needs a failure response.

  1. Compromised privileged key
    Admin and issuer roles
    Role separation, multisig or custody-held roles
    Pause affected paths, rotate keys, reassign roles
  2. Forged or faulty cross-chain message
    Bridge / messaging layer
    Explicit peers, verifier configuration, rate limits
    Halt the affected route, reconcile supply
  3. Stale or manipulated price
    Oracle input
    Freshness checks, conservative collateral ratios
    Suspend risky actions until prices are trusted
  4. Unsafe upgrade
    Upgrade authority
    Governed upgrades, review and timelock
    Delay window allows detection and rollback
Authority
  • Access control
  • Least privilege
  • Role separation
  • Multisig
  • Timelocks
  • Key management
  • Custody
Runtime controls
  • Pause controls
  • Circuit breakers
  • Rate limits
  • Supply invariants
External risk
  • Oracle risk
  • Bridge risk
  • Upgrade governance
Assurance
  • Testing
  • Static analysis — Slither, Mythril, MythX
  • Audit readiness
  • Monitoring

A framework for reasoning about controls, not a claim that every control exists in every system. Case studies state what was actually applied.

05Cross-chain architecture

Cross-chain design is trust design

A multi-chain token is one system with several execution environments — and every link between them is an assumption.

Questions every cross-chain design must answer
  1. Who attests that an event on the source chain happened — and what does the destination do if that attestation is wrong?
  2. Where does canonical supply live: burn-and-mint across peers, or lock-and-release behind an adapter?
  3. Which remote contracts may send messages, and how is that peer list governed?
  4. What stops a faulty route from draining value — rate limits, pause paths, reconciliation checks?
Applied in RBC / FRK

Reference architecture — networks shown illustrate the pattern, not a list of live deployments.

06Deployment architecture

Deployment is part of the system

Smart contracts are expensive to change after release, so the release itself is designed.

  1. Environment configuration
    Per-network parameters kept out of init code
  2. Deterministic deployment
    CREATE2 for identical addresses across EVM networks
  3. Scripted rollout
    The same automated steps on every network
  4. Post-deploy validation
    Addresses, roles, peers and parameters checked
  5. Source verification
    Verified on each network's explorer
  6. Role handover
    Privileged roles moved to multisig or custody-held wallets
  7. Audit handoff & runbooks
    Scope, assumptions and operational procedures documented
07Architecture principles

Principles behind the decisions

  1. 01

    A token is a system, not a contract.

    Token architecture includes issuance, governance, custody, integrations, deployment, monitoring and operational controls.

  2. 02

    Cross-chain architecture is trust architecture.

    Every bridge introduces assumptions about messaging, liquidity, supply reconciliation and failure recovery.

  3. 03

    Compliance belongs in architecture.

    For regulated assets, identity, claims, transfer restrictions and administrative controls must exist at protocol level.

  4. 04

    Security begins before the audit.

    Threat modelling, role separation, privileged operations, upgrade controls and emergency mechanisms are architecture decisions.

  5. 05

    Deployment is part of system design.

    Deterministic deployment, environment consistency, verification and operational runbooks are production requirements.

  6. 06

    Technology follows system constraints.

    EVM, Solana, LayerZero and ERC-3643 are implementation choices — architecture begins with system requirements.