We tokenize real-world assets.

RWA tokenization is the process of representing ownership of a real-world asset — property, private credit, a fund, infrastructure — as a token on a blockchain, with a legal wrapper behind it that makes the claim enforceable. The token is a claim on the asset issued by a legal entity; the smart contract enforces transfer restrictions on-chain while the legal wrapper makes the claim enforceable off-chain, and the two have to match exactly.

Cost is driven mostly by asset class, jurisdiction scope, investor base, blockchain choice and custodian integration depth — the token contract itself is often the smallest piece. A single-asset, single-jurisdiction an institutional-only product is far lighter than a multi-market platform with retail exposure and secondary markets.

Ethereum mainnet for institutional credibility, Polygon, Base or Arbitrum for cost, Avalanche subnets for permissioned institutional deployments, and Canton Network where privacy between participants is the constraint. The choice depends on where investors already hold assets and how much settlement cost the product can tolerate.

Smart-contract issuance, KYC/KYB/accreditation onboarding, primary subscription and settlement, distribution and waterfall contracts, secondary-market integration or internal matching, reporting exports and an investor-facing portal. The legal structuring itself and the underlying asset custody sit entirely outside the engineering scope — we wire to your counsel's work and your custodian's operations.

For permissioned instruments, ERC-3643 or an equivalent standard is generally the right choice — it has on-chain transfer-restriction enforcement and claim-based identity built in. ERC-20 with transfer hooks works for simpler instruments but becomes brittle as the restriction rules get more detailed. The real question is whether the smart-contract rules mirror the offering-document rules exactly.

Your counsel does. It depends on where you issue, where you sell and what you are issuing, and it is not a question we answer. What we can tell you is what their answer changes on our side, because it changes a lot: the onboarding flow, the whitelist rules and the transfer restrictions written into the contract itself. Those are product decisions made before deployment, not settings adjusted afterwards. Issuers selling into several markets at once generally end up enforcing the strictest overlap on-chain, because the contract can only hold one set of rules.

In most cases, no — permissioned tokens carry transfer restrictions that standard AMM pools can't honour. Secondary liquidity typically runs through approved venues, or internal OTC matching with the restriction checks built in. Permissioned pool designs like Uniswap v4 hooks are emerging but still early.

Through a subscription engine that treats stablecoin and wire settlement as an explicit state machine — pledged, funded, minted, settled — with rollback paths at every step. USDC and USDT handle on-chain settlement, with fiat rails through Bridge, BVNK or Monerium and reconciliation against the custodian of record.

The distribution engine needs explicit exception handling — queued distributions, escrow for lost holders, reversal flows — built in from the start, not discovered after the first failure. Most first-time RWA builds only account for the happy path, which becomes an operational problem the first time a holder loses a wallet or a tax rate changes mid-cycle.

Tokenization earns its place when the asset has real demand and the existing rails are genuinely slow, expensive or closed. Fractional access to assets with a high minimum, secondary liquidity where none existed, automated distributions replacing manual transfer-agent work — these are where the model clearly wins. The strongest platforms we have built started from a specific allocator base that wanted the asset and could not easily get it. We start by mapping that demand, then build the issuance and onboarding around it.