RealProton
RWA Tokenization & Compliance Infrastructure
An ERC-3643-oriented real-estate tokenization platform with identity, claim topics, registry, compliance and controlled transfers — operated through a Fireblocks-based multisignature wallet architecture.
- 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
RealProton brings real-estate-linked assets on-chain. Unlike open DeFi tokens, these assets carry investor eligibility, jurisdictional and operational rules that must hold on every transfer.
Problem
A standard ERC-20 cannot express who is allowed to hold an asset, which jurisdictions it may move between, when it is locked, or how an issuer recovers a lost wallet. Those rules had to be enforced on-chain while staying operable by the issuer's teams.
Architecture
The token follows the ERC-3643 model: every holder is tied to an on-chain identity; required claims are defined by claim topics and trusted issuers; an identity registry answers 'is this wallet verified?'; and a modular compliance contract answers 'is this transfer allowed?'. Privileged operations run through agent roles, operated from a Fireblocks vault structure with multisignature approvals.
ERC-3643
ERC-3643 (T-REX) defines permissioned tokens whose transfers succeed only when both parties are eligible and compliance rules pass. It separates identity, eligibility and rules into modules, so policy can evolve without redeploying the token.
Identity & claim topics
Each investor wallet maps to an on-chain identity holding claims issued by trusted issuers. Claim topics define which attestations are required — the token never stores personal data, only verifiable claims.
Compliance & controlled transfers
Token classes and jurisdictional transfer restrictions are enforced through whitelisting, identity validation and locking rules. Agent permissions support administrative transfer operations that regulated assets require.
Fireblocks wallet infrastructure
Operational wallets are separated by responsibility — treasury, transfer vault, issuer and legal — with multisignature approval flows. Privileged contract roles are held by policy-controlled vaults rather than individual keys.
Design Decisions
| Decision | Why |
|---|---|
| ERC-3643 over a custom whitelist token | An established standard for permissioned assets, with identity and compliance separated into auditable modules. |
| Modular compliance | Jurisdictional and lock-up rules change; the token should not need to. |
| Fireblocks vault separation | Maps real operational responsibilities to distinct, policy-controlled wallets. |
| Multisignature for privileged actions | No single person can mint, force-transfer or reconfigure compliance alone. |
Smart Contracts
| Component | Responsibility |
|---|---|
| ERC-3643 token | Permissioned transfers, token classes, locking |
| Identity registry | Maps wallets to verified on-chain identities |
| Claim topics & trusted issuers | Defines required attestations and who may issue them |
| Compliance module | Jurisdictional and transfer-rule enforcement |
| Agent roles | Administrative transfers, freezes and recovery |
Security
- Reviewed agent and administrative permissions — the most powerful and most sensitive surface.
- Participated in test-coverage reviews ahead of audit.
- Prepared bug summaries and supported remediation and redeployment.
- Verified redeployed contracts and configuration.
Integrations
- Fireblocks-based treasury, transfer-vault, issuer and legal wallet flows.
- Contracts connected to backend operational APIs and user workflows.
- Coordination with compliance teams on transfer-rule requirements.
Deployment
- Avalanche-based deployment activities.
- Redeployment and verification following audit feedback.
- Role assignment to custody-controlled wallets after deployment.
Challenges
- Expressing jurisdictional and token-class rules as deterministic on-chain checks.
- Balancing strong agent powers (needed for regulated assets) with tight control over who can use them.
- Keeping contract roles, custody vaults and operational procedures aligned.
Solution
A compliance-ready tokenization stack: identity-gated ERC-3643 tokens, modular transfer rules, and privileged operations executed through a multisignature Fireblocks wallet architecture — prepared for audit and deployed with verification.
My Contribution
What I personally worked on
- Worked on identity, claim-topic, registry, compliance and controlled-transfer components.
- Supported token classes and jurisdictional restrictions: whitelisting, identity validation, locking rules and agent permissions.
- Contributed to the Fireblocks wallet architecture — treasury, transfer-vault, issuer, legal and multisignature flows.
- Participated in audit preparation, test-coverage reviews, bug-summary reporting, redeployment, verification and Avalanche deployment.
Delivered by the broader project / team
- Legal structuring and regulatory interpretation — client and legal advisers
- KYC provider and investor onboarding operations — client
- Independent audit — external auditors
SME / Technical Leadership
- Collaboration with backend, wallet, compliance and product teams
- Requirements clarification: translating compliance rules into contract logic
- Audit readiness: coverage reviews and issue summaries
- Deployment and redeployment coordination
Technologies
Architecture Takeaways
- In RWA, the compliance model is the product.
- Privileged roles need a custody design, not just an onlyOwner modifier.
- Audit readiness is a deliverable — coverage, scope and known issues, documented.