ATLAS RWA
Real-World Asset Infrastructure
Bringing programmable ownership to real-world assets.
Issue and administer tokenised assets where eligibility, ownership and distributions reconcile to the legal record automatically.
- ERC-1400 patterns
- Eligibility registry
- Event sourcing
- Waterfall maths
- Audit lineage
Issuance, compliance and distribution infrastructure for tokenized real estate, invoices, private credit and treasury assets.
What the product is built around.
ATLAS treats the token as a representation of a record, not the record itself. The registry is the source of truth for the asset; the contract enforces who may hold it; and every state change on either side produces a reconcilable, timestamped entry.
Compliance in the transfer path
Eligibility is enforced at transfer time against live investor status, so a lapsed accreditation blocks a transfer rather than being caught in a quarterly review.
Registry as source of truth
On-chain supply reconciles to the off-chain asset record continuously, with breaks surfaced as exceptions instead of discovered at audit.
Distributions as a pipeline
Waterfall calculation, tax treatment and payment execution run as one auditable process with a reproducible result.
What makes this hard.
Tokenizing an asset is the easy part. The hard part is everything the token implies: who is allowed to hold it, what happens at a distribution, how ownership reconciles against the off-chain legal record, and how a regulator or auditor reconstructs any of it twelve months later.
- 01
Token supply and the legal ownership record drift apart with no reconciliation process
- 02
Investor eligibility is verified once at onboarding and never re-checked
- 03
Distributions are calculated in spreadsheets and paid manually
- 04
Transfer restrictions live in prose, not in the transfer function
- 05
Reporting for auditors requires rebuilding history from block explorers
What the system does.
ATLAS treats the token as a representation of a registry record rather than the record itself. Eligibility is checked inside the transfer path against live investor status, so a lapsed accreditation blocks a transfer instead of surfacing in a quarterly review. Distributions run as a reproducible pipeline, and the ownership ledger is append-only so any historical position is a replay.
Transfer restrictions enforced against live eligibility, not a cached list
On-chain supply reconciled to the registry continuously, breaks raised as exceptions
Waterfall calculation reproducible to the cent from a snapshotted input set
Jurisdiction rules versioned per asset class with automatic holder re-sweeps
Append-only ownership ledger, so auditors replay rather than reconstruct
ATLAS RWA, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Assets under registry
$126.4M
Tokens issued
34
Verified investors
812
Distributions YTD
$4.91M
Asset registry
Commercial Property
Real estate · Netherlands
$38.40M
- investors
- 184
- target yield
- 7.2%
Private Credit
Private credit · Luxembourg
$29.60M
- investors
- 241
- target yield
- 11.4%
Treasury Portfolio
Treasury · United States
$24.80M
- investors
- 302
- target yield
- 4.8%
Infrastructure Asset
Infrastructure · Sweden
$18.20M
- investors
- 96
- target yield
- 8.6%
Registry detail
| Asset | Class | Jurisdiction | Valuation | Tokenized | Holders | Compliance | Status |
|---|---|---|---|---|---|---|---|
| Harbour West IndustrialRE-2041-A | Real estate | Netherlands | $38.40M | 86% | 184 | Verified | Live |
| Meridian Credit Fund IIPC-1187-B | Private credit | Luxembourg | $29.60M | 100% | 241 | Verified | Live |
| T-Bill Ladder 3MTR-0904-C | Treasury | United States | $24.80M | 100% | 302 | Verified | Live |
| Nordvik Receivables 04IN-3312-A | Invoices | Sweden | $18.20M | 62% | 96 | Review | Issuing |
| Cordova Plaza RetailRE-2088-D | Real estate | Spain | $11.40M | 0% | 0 | Pending | Draft |
| Akselos Trade NotesIN-3401-B | Invoices | Singapore | $4.00M | 34% | 48 | Flagged | Paused |
6 of 34 registry records shown · valuations shown for illustration and refreshed on the asset's stated cycle
Registry by asset class
- Real estate39.4%
- Private credit23.4%
- Treasury19.6%
- Invoices17.6%
Onboarding funnel
30D- Invited1,204
- Identity submitted976
- Accreditation verified812
- Subscription signed578
- Funded494
Reconciliation
- On-chain supply
- 126,400,000
- Registry units
- 126,400,000
- Break
- 0
- Last reconciled
- 3 min ago
- Unresolved exceptions
- 2
- Registry version
- v418
- Audit trail
- Complete
Distributions paid
12MCompliance queue
- Accreditation lapsedINV-04812 · transfers gated automatically2h
- Jurisdiction rule changeSG holders · re-check 48 positions6h
- Sanctions screen refresh812 investors · 0 hits1d
- Lockup expiringRE-2041-A · 184 holders unlock in 9 days1d
- Document expiry14 investors · proof of address2d
Issuance lifecycle — Nordvik Receivables 04
- Secondary transfers enabledStep 6
Pending — opens after the 90-day lockup window closes
- Distribution schedule armedStep 5
Monthly waterfall configured · first run in 6 days
- Allocation settledStep 4
62% of supply allocated to 96 verified holders
- Token deployedStep 3
Transfer restrictions bound to the eligibility registry at deploy time
- Legal wrapper executedStep 2
SPV documents hashed and anchored to the registry record
- Asset registeredStep 1
Receivables pool onboarded with third-party valuation attached
Transfer restriction
excerptfunction _beforeTokenTransfer( address from, address to, uint256 amount) internal override { // Eligibility is read at transfer time, never cached. if (from != address(0)) { require(registry.isEligible(to), "ATLAS/HOLDER_INELIGIBLE"); require(!registry.isFrozen(from), "ATLAS/SENDER_FROZEN"); require( lockups[from] <= block.timestamp, "ATLAS/LOCKUP_ACTIVE" ); require( registry.jurisdictionAllowed(to, assetClass), "ATLAS/JURISDICTION_BLOCKED" ); } super._beforeTokenTransfer(from, to, amount);}Interface states
UI statesNo assets registered
Register the first asset to create a registry record and begin issuance.
Register assetEmpty stateReconciliation break detected
On-chain supply differs from registry units by 1,200. Issuance is paused until the break is resolved.
How it is put together.
The compliance registry is a separate service from the token contract on purpose: eligibility changes constantly, contracts should not.
- 01
Issuer Console
Registry management, issuance configuration, distribution runs and reporting.
- Next.js
- React
- TypeScript
- 02
Compliance Service
KYC/KYB orchestration, accreditation state, jurisdiction rules and sanctions screening.
- Node.js
- Rules engine
- Webhooks
- 03
Registry Core
Asset records, ownership ledger, valuation history and reconciliation against chain state.
- PostgreSQL
- Event sourcing
- Audit log
- 04
Issuance Engine
Supply configuration, lockups, vesting schedules and distribution waterfalls.
- TypeScript
- Decimal maths
- Queue
- 05
Smart Contracts
Permissioned token with eligibility-gated transfers and forced-transfer controls.
- Solidity
- ERC-20
- ERC-1400 patterns
- 06
Blockchain & Indexing
Event indexing for cap-table reconstruction and auditor lineage.
- EVM
- Indexer
- Immutable log
What the product does.
The capability set the demonstration is built around.
Asset registry
Structured records for each asset with valuation history, documents and legal references.
Investor onboarding
KYC/KYB collection, accreditation checks and jurisdiction-aware eligibility rules.
Token issuance
Configurable issuance with supply caps, lockups, vesting and transfer restrictions.
Compliance status
Continuous eligibility monitoring with automatic transfer gating on status change.
Ownership ledger
Cap-table view reconciling token holders against the off-chain ownership record.
Distributions
Waterfall modelling, pro-rata calculation and batched payment execution.
Reporting
Auditor-ready exports with full lineage from position back to originating event.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
The token and the legal record can silently diverge
Both sides are event-sourced and reconciled on a schedule. A break becomes a blocking exception that pauses issuance rather than a number nobody notices until audit.
Eligibility is dynamic but contracts are immutable
The contract holds no investor data. It calls an eligibility registry at transfer time, so status changes take effect immediately without redeploying anything.
Distribution maths must be reproducible to the cent
Waterfall calculation runs on fixed-point decimals with the full input set snapshotted. Re-running a historical distribution produces a byte-identical result.
Jurisdiction rules differ per asset class and change without notice
Rules are declarative and versioned per jurisdiction and class. A rule change triggers a re-sweep of affected holders and gates transfers that no longer pass.
Auditors need to reconstruct any position at any past date
Nothing is updated in place. The ownership ledger is append-only, so any historical state is a replay rather than a reconstruction.
The stack behind it.
Token contracts
- Solidity
- Foundry
- ERC-20
- ERC-1400 patterns
- Transfer restriction registry
- Forced-transfer controls
- Slither
Eligibility & compliance
- Node.js
- Rules engine
- KYC/KYB APIs
- Sanctions screening
- Versioned jurisdiction rules
- Holder re-sweeps
- Webhooks
Registry core
- PostgreSQL
- Event sourcing
- Append-only ownership ledger
- Point-in-time replay
- Valuation history
- Optimistic concurrency
- Row-level security
Issuance & distributions
- TypeScript
- Fixed-point decimal maths
- Waterfall engine
- Lockup and vesting schedules
- Snapshotted input sets
- Job queue
- Redis
Chain integration
- EVM
- Event indexer
- Reorg-safe cursors
- Cap-table reconstruction
- Supply reconciliation
- Break exception queue
Audit & reporting
- Immutable audit log
- Document hashing and anchoring
- Position lineage
- Auditor pack export
- Object storage
- OpenTelemetry
Issuer console
- Next.js
- React
- TypeScript
- Tailwind CSS
- Server Components
- Virtualised cap-table grid
- RBAC
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
One asset, one jurisdiction, proving the issuance and compliance path end to end.
- Single asset class and jurisdiction
- Investor onboarding with accreditation checks
- Permissioned token with transfer gating
- Manual distribution run
Multiple asset classes with automated administration.
- Multi-class registry with valuation history
- Automated distribution waterfalls
- Continuous eligibility sweeps
- Investor portal with documents
Multi-jurisdiction issuance with institutional reporting and controls.
- Multi-jurisdiction rule engine
- Auditor-ready lineage exports
- Multi-chain issuance, one canonical ledger
- Secondary transfer venue with eligibility-aware matching
Where it could go next.
Directions this system would extend into.
- 01
Secondary market venue with eligibility-aware matching
- 02
Automated NAV updates sourced from third-party valuation providers
- 03
Multi-chain issuance with a single canonical ownership ledger
- 04
Investor portal with self-service documents and distribution history
- 05
Programmable covenants that enforce asset-level conditions on transfer
Tokenizing real assets where the on-chain record has to reconcile to the legal one?
We built ATLAS RWA to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.