RBC / FRK
Multi-chain Token Infrastructure
Token infrastructure deployed and validated across multiple EVM networks with deterministic CREATE2 addressing, a LayerZero OFT-oriented cross-chain model, deployment automation, contract verification and audit handoff — designed with Solana in scope.
- 01 Context
- 02 Problem
- 03 Architecture
- 04 Design Decisions
- 05 Smart Contracts
- 06 Security
- 07 Integrations
- 08 Deployment
- 09 Challenges
- 10 Solution
- 11 My Contribution
- 12 SME / Technical Leadership
- 13 Technologies
- 14 Architecture Takeaways
Context
RBC and FRK are token programmes I work on as a Blockchain Consultant at AppMindsGlobal. Both tokens needed to exist on more than one network, with a release process that could be repeated, verified and handed to auditors with confidence.
Problem
Launching a token on several chains usually produces different addresses per network, independently minted supplies and hand-run deployments. That makes integrations fragile, supply hard to reason about and audits harder to scope. The challenge was to make a multi-chain token behave like one system.
Architecture
The token is deployed through a deterministic CREATE2 pattern so each EVM deployment resolves to the same address. Cross-chain movement follows a LayerZero OFT-oriented model: each deployment is peered with its counterparts, and transfers debit on the source chain and credit on the destination, keeping one logical supply. Deployment and verification are scripted per network so every chain is configured the same way.
Deterministic deployment
CREATE2 derives the address from the deployer, a salt and the init-code hash. Keeping those identical across chains yields identical token addresses — so wallets, explorers and integrators recognise the token everywhere by one address.
Cross-chain supply
An OFT-style token treats each chain's contract as part of one supply. Bridging is a message between trusted peers rather than a wrapped IOU, so supply accounting stays consistent.
Deployment automation
Scripted, per-network deployment removes manual variance between chains and makes redeployments reproducible.
EVM and Solana
EVM networks share the CREATE2 model; Solana does not. On Solana, tokens follow the SPL model with program-derived accounts, so the architecture keeps one product specification with chain-appropriate implementations.
Design Decisions
| Decision | Why |
|---|---|
| Deterministic CREATE2 deployment | Same address on every EVM chain simplifies integration, verification and trust. |
| OFT-oriented bridging over a custom bridge | Reuses established cross-chain messaging instead of building and securing a bespoke bridge. |
| Scripted, per-network deployment | Removes manual variance between chains and makes redeployments reproducible. |
| Verification as part of release | A deployment is not done until the source is verified on each network. |
Smart Contracts
| Component | Responsibility |
|---|---|
| ERC-20 token | Core fungible token logic and supply |
| OFT / bridge layer | Cross-chain debit / credit between peered deployments |
| CREATE2 deployer | Deterministic, repeatable contract addresses |
| Deployment scripts | Network configuration, peering and verification |
Security
- Review of privileged roles — ownership, peer configuration and any mint / pause authority.
- Validation that only configured remote peers can deliver cross-chain messages.
- Per-network checks of deployed addresses and configuration.
- Audit handoff package: scope, contracts, deployment process and assumptions.
Integrations
- One token address shared with wallets, explorers and integrators across EVM networks.
- Cross-chain peer configuration aligned across every supported network.
Deployment
- Deterministic CREATE2 deployment on each EVM network.
- Deployment automation repeating the same steps and configuration per chain.
- Post-deployment validation of addresses, peers and parameters.
- Source verification on each network's block explorer.
Challenges
- Keeping init code identical across chains while still allowing per-chain configuration.
- Making peer configuration complete and correct on every network before transfers are enabled.
- Designing across EVM and Solana, whose account and deployment models differ fundamentally.
Solution
A token system designed to be deployed, not merely written: deterministic addresses, one cross-chain supply model, automated deployment and verification, and a clean audit handoff.
My Contribution
What I personally worked on
- Deployed and validated the token infrastructure across multiple EVM networks using CREATE2-based deterministic addressing.
- Worked on the ERC-20, bridge and LayerZero OFT-oriented architecture.
- Built and ran deployment automation and contract verification.
- Prepared and supported the audit handoff.
Delivered by the broader project / team
- Token economics and commercial decisions — client
- Independent security audit — external auditors
SME / Technical Leadership
- Architecture decisions on deterministic deployment and cross-chain supply
- Technical consulting and requirements clarification with the client
- Deployment planning and sequencing across networks
- Security considerations for privileged roles and peer configuration
- Communication with audit stakeholders through the handoff
Technologies
Architecture Takeaways
- Design the deployment, not just the contract.
- Determinism makes systems auditable and integrations boring — in a good way.
- Cross-chain security is configuration security: peers and verifiers are part of the attack surface.