Architecture decisionsArchitecture considerations I work with
Framed as lightweight architecture decision records: the context, what I weigh, and the trade-off I accept.
ADR-01Why CREATE2?
Multi-chain tokens are easier to integrate, audit and trust when the contract lives at the same address everywhere.
- 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-offDeterminism pushes configuration into initialisation functions, which must then be protected against front-running and double-initialisation.
Applied in: RBC / FRK · G Future Tech multi-chain token infrastructureADR-02Why ERC-3643?
Securities-style real-world assets cannot be freely transferable bearer tokens. The token must know who may hold it.
- 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-offCompliance adds gas cost and integration complexity, and concentrates power in agent roles — so custody and role design matter as much as the token.
Applied in: RealProton · compliance-ready RWA tokenizationADR-03Why ERC-1155?
Ecosystems with identities, tiers and many asset types need more than one-token-per-contract NFTs.
- 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-offFlexibility 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.
Applied in: Maavatar · blockchain-backed metaverse identities and assetsADR-04Why cross-chain architecture?
A token that lives on several chains needs a single, coherent supply rather than a set of unrelated wrapped copies.
- 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-offMessaging infrastructure removes the need to build a bespoke bridge, but introduces an external trust dependency that must be documented for stakeholders.
Applied in: RBC / FRK · LayerZero OFT-oriented bridging and cross-chain supplyADR-05Why Fireblocks?
Institutional issuers need to operate privileged roles — minting, treasury moves, agent actions — without single-key risk.
- 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-offCustody platforms add operational dependency and cost; the benefit is auditable, policy-driven control over the most dangerous transactions.
Applied in: RealProton · G Future Tech wallet and treasury architectureADR-06EVM + Solana
Serving users on both ecosystems means designing one product across two very different execution models.
- 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-offA shared product spec with chain-specific implementations is usually safer than forcing one chain's patterns onto the other.
Applied in: AppMindsGlobal multi-chain engagementsADR-07Crypto-backed vs RWA-backed models
Financial infrastructure that accepts both crypto and real-world assets as collateral has to treat them as different risks inside one system.
- 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-offSharing infrastructure across both models reduces duplication, but only if risk parameters, pricing and liquidation are configured per collateral type.
Applied in: USDAO · G Future Tech financial infrastructureADR-08Blockchain-backed metaverse architecture
In a blockchain-backed metaverse, the chain is the source of truth for identity and ownership — so its design shapes the whole product.
- 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-offPutting more on-chain increases trust and interoperability but adds cost and rigidity; the architecture has to evolve as product requirements change.
Applied in: Maavatar · Blockchain SME and core technical contributor