RWA / DIGITAL ASSETS
PROPELOO engineers real-world asset tokenization systems — from legal wrapper architecture and compliance-gated token contracts to primary issuance infrastructure, secondary market design and the oracle and cap table systems that make tokenized assets investable. Minting a token is the easy part.
Minting a token is trivial. Investor whitelisting, KYC/AML enforcement on-chain, transfer restrictions complying with securities law, oracle pricing, primary issuance mechanics, secondary market design, dividend logic, cap table management — each a separate engineering problem. Most RWA projects ship the token and discover the other 95% of the engineering work during their first investor onboarding. PROPELOO designs the full compliance, settlement and liquidity infrastructure before the first line of Solidity is written.
A tokenized asset is not a token. It is a compliance infrastructure, a settlement system, a liquidity design and a legal wrapper — with a token as the interface.
ERC-3643 or ERC-1400 token contracts with on-chain transfer restrictions, investor registry and permissioned transfer logic that cannot be bypassed at the contract level.
End-to-end investor onboarding pipeline — document verification, liveness checks, accreditation verification, sanctions screening and ongoing AML monitoring integrated with the on-chain identity registry.
Primary token sale mechanics — subscription windows, allocation management, payment acceptance (fiat and crypto), pro-rata distribution and cap table initialisation.
Secondary trading infrastructure — AMM pool design for tokenized assets, order book integration, transfer restriction-aware trading and liquidity provider incentive mechanics.
On-chain dividend and coupon distribution, voting mechanics, capital call logic, corporate action announcements and automated payment to verified token holder wallets.
Real-time on-chain cap table reflecting current token ownership, investor concentration reporting, transfer history, regulatory audit trail and jurisdiction-specific compliance reports.
Tokenization is a solved problem. Designing the ownership, compliance, settlement and liquidity infrastructure around it isn't.
A token without a legal wrapper connecting on-chain ownership to enforceable real-world rights is not an investable asset — it is a database entry. Legal structure comes first.
Axiom:
KYC gates implemented only at the frontend or API layer can be bypassed by direct contract interaction. Transfer restrictions and investor whitelists must be enforced at the EVM level using ERC-3643 or equivalent.
Axiom:
Tokenized assets without secondary market infrastructure are illiquid digital certificates. Primary issuance mechanics, secondary AMM design and redemption windows must be architected before the token standard is chosen.
Axiom:
Every RWA protocol depends on external price feeds or NAV oracles. Oracle manipulation is the primary attack vector. Multi-source aggregation, TWAP and deviation circuit breakers are architectural requirements.
Axiom:
These choices determine the regulatory posture, secondary market viability and investor experience. Most cannot be changed post-deployment.
Impact: Off-chain compliance is bypassable. For regulated securities, on-chain enforcement is the only architecture that satisfies most legal structures.
Impact: Securities regulations in most jurisdictions require transfer restrictions. Permissionless secondary markets create regulatory exposure.
Impact: Off-chain-only compliance creates a regulatory gap that sophisticated investors and regulators will identify.
Impact: Oracle compromise equals protocol compromise. NAV manipulation enables arbitrage attacks against the entire system.
Impact: Secondary market design determines the real value of tokenization. Without it, digital securities offer minimal advantage over paper instruments.
Impact: Each jurisdiction multiplies KYC requirements and legal counsel cost. Launch with one jurisdiction and expand with validated compliance model.
Fractional ownership of commercial or residential property — SPV structure, on-chain cap table, ERC-3643 transfer restrictions, NAV oracle and investor distribution mechanics.
Tokenized LP interests with accreditation gates, lock-up period enforcement, on-chain waterfall distribution logic and secondary transfer restrictions.
Short-duration debt instruments backed by trade receivables — originator verification, on-chain maturity enforcement, automatic settlement at maturity and yield distribution.
Tokenized carbon offset certificates with provenance tracking, registry integration, on-chain retirement mechanics and verification against double-counting.
Commodity-backed tokens with custodian oracle integration, proof-of-reserve mechanics, partial ownership, auditor attestation on-chain and physical redeemability logic.
Tokenized private credit instruments with borrower identity verification, covenant tracking, interest payment distribution and default waterfall logic enforced on-chain.
Technology selection follows legal structure, compliance requirements and target investor base.
Stack: Solidity, ERC-3643 (T-REX), ERC-1400, Hardhat, Foundry, OpenZeppelin
Stack: Synaps, Onfido, Chainalysis, Elliptic, Sumsub, Identity Registry
Stack: Chainlink Data Feeds, Chainlink CCIP, Pyth Network, Institutional Price APIs, TWAP Oracles
Stack: PostgreSQL, Redis, AWS, Docker, Kubernetes, Event Streams
Stack: The Graph, Custom Indexers, Cap Table DB, Compliance Reporting API, Audit Trail Storage
Stack: Slither, Foundry Fuzz Testing, Trail of Bits, OpenZeppelin Defender, Tenderly, Datadog
A tokenized asset system holds real legal and economic value. Every layer is a potential attack surface.
NAV and price oracle manipulation enables attackers to purchase tokenized assets below market value or drain AMM liquidity pools. TWAP oracles, multi-source aggregation, deviation thresholds and circuit breakers are required for every price-dependent operation.
Compliance gates implemented only at the API layer can be bypassed by direct contract interaction. ERC-3643 on-chain identity registry enforcement ensures transfer restrictions apply at every interaction path, including direct contract calls.
Inadequate investor identity verification creates regulatory liability for the issuer. The compliance layer must integrate with authoritative identity providers, maintain AML screening, and preserve audit trails for regulator review.
Upgradeable token contracts with insecure admin keys give complete control over investor holdings to the key holder. Governance-controlled upgrades, timelocks and multi-sig admin with minimum 48-hour delay are required for any system holding investor assets.
Token transfer logic baked into immutable contracts cannot adapt to new regulatory requirements. Compliance parameter governance, jurisdiction-specific rule modules and legal counsel review of all transfer restriction logic are required before deployment.
KYC data including identity documents, financial information and personal details requires encryption at rest, field-level encryption for sensitive fields, strict access controls, data residency compliance and GDPR-aligned deletion procedures.
Asset type analysis, jurisdiction selection, SPV structure review, legal counsel coordination and regulatory surface mapping before any technical architecture is defined.
Investor eligibility rules, KYC/AML provider selection, identity registry design, transfer restriction logic specification and regulatory reporting requirements.
Token standard selection (ERC-3643 vs ERC-1400), contract system architecture, upgrade strategy, oracle integration specification and access control model.
Primary issuance mechanics, subscription management, payment processing, investor onboarding pipeline, cap table initialisation and allocation logic.
Secondary trading infrastructure — AMM pool design or order book integration, liquidity provider mechanics, transfer-restriction-aware trading and fee structure.
Internal security review, Foundry fuzz testing of transfer restriction invariants, third-party smart contract audit, compliance review and testnet deployment.
Production deployment, investor portal launch, cap table go-live, regulatory reporting pipeline activation, monitoring infrastructure and on-call protocol.
Yes — in almost every case. A token without a legal wrapper connecting on-chain ownership to enforceable real-world rights is not a security — it is a database entry. The legal structure (typically an SPV, trust or fund) defines what the token holder actually owns and how that ownership is enforced off-chain. We design the technical architecture alongside legal counsel, not after.
ERC-3643 (also known as T-REX) is a token standard designed specifically for permissioned security tokens. It embeds an on-chain identity registry that every transfer must validate against — so transfer restrictions based on investor accreditation, jurisdiction and KYC status are enforced at the contract level and cannot be bypassed by direct contract interaction. Standard ERC-20 tokens require off-chain compliance layers that can be circumvented.
Yes — ERC-3643 enforces transfer restrictions at every transfer call through on-chain identity registry validation. The token contract checks the sender and recipient against a compliance module before executing any transfer. This applies to direct contract calls, not just frontend-initiated transactions. For ERC-20 tokens, transfer restrictions can only be enforced at the API layer, which is bypassable.
KYC/AML is enforced through an on-chain identity registry that maintains a whitelist of verified investor wallet addresses. When an investor completes KYC through an integrated provider (Synaps, Onfido, Sumsub), their verified wallet is added to the registry. Every token transfer checks this registry. Ongoing AML screening monitors wallet transactions for suspicious patterns and can trigger registry removal, which immediately restricts future transfers.
Yes — but secondary market design for tokenized securities requires compliance-aware infrastructure. A compliant secondary market must verify both buyer and seller KYC status before executing a trade. This can be implemented as a permissioned AMM, a compliant order book or an OTC trading facility. Listing on permissionless DEXs like Uniswap is generally incompatible with securities compliance unless transfer restrictions prevent non-KYC'd wallets from receiving tokens.
Yes — distribution contracts can push stablecoin or token payments to all verified token holders at a specified snapshot, proportional to holdings. This requires integrating a stablecoin payment rail, maintaining a current holder registry for snapshot calculation and designing the distribution contract to handle holders who cannot receive payments (e.g., sanctioned addresses). Tax reporting implications of on-chain distributions must be reviewed by the issuer's legal counsel.
Oracle failure can freeze pricing-dependent operations (e.g., AMM pricing, NAV-dependent redemptions). Oracle manipulation can enable asset draining through mispriced trades. Mitigations: use multi-source aggregation across at least 3 independent oracles, implement deviation thresholds that pause trading on abnormal price moves, use TWAP prices for any security-critical calculation rather than spot prices, and design circuit breakers that default to the last validated price during outages.
Cross-border compliance requires jurisdiction-specific rules within the compliance module. ERC-3643 supports per-investor compliance attributes including jurisdiction, which the transfer restriction logic evaluates. US investors require Regulation D or Regulation S compliance. EU investors may require MiFID II product governance compliance. Each jurisdiction's rules are encoded as compliance module logic and updated through a governance-controlled upgrade path as regulations evolve.
A security token represents ownership of or a financial claim on a real-world asset — equity, debt, revenue share or fund participation. It is regulated as a security in most jurisdictions. A utility token provides access to a platform, service or product. The Howey Test (US) and equivalent frameworks in other jurisdictions determine classification. Misclassifying a security token as a utility token creates significant regulatory liability. We work alongside legal counsel on every RWA engagement to ensure correct classification.
A full RWA tokenization system — legal structure, KYC/AML pipeline, ERC-3643 token contracts, primary issuance infrastructure, investor portal, oracle integration and cap table reporting — takes 16–28 weeks from architecture sign-off to production launch. The legal structural work and KYC provider integration typically run on the critical path. Systems that include secondary market infrastructure add 6–10 weeks. We deliver in milestone-based sprints with testnet deployment at each stage.