Every asset you tokenize is an obligation you service for its entire life
Platform development gets priced as a project. Contracts, an identity registry, an investor portal, an admin console, payment rails. The work is well understood, and a competent team can scope it.
Then the first asset goes on, and the shape changes. Issuance ended; servicing did not. For a note with a five-year term, you now owe periodic work for five years. For a fund, interest for ten or more. For an evergreen vehicle, indefinitely.
So the question that decides whether a platform is a business is not whether you can build it. It is your cost per asset per year, and whether your fees cover it for the life of every asset you accept.
What servicing cost scales with
Four things, and the omission matters more than the list.
Holders. Onboarding, verification renewal, statements, tax documents, lost wallet recovery, and the question volume any investor base generates.
Periods. Every distribution, valuation, reporting cycle and reconciliation run.
Jurisdictions. Withholding differs by holder location and status, eligibility rules differ by offering route, reporting obligations differ by regulator.
Asset classes. Lifecycle events do not transfer between types. A property has valuations, refinancing and a sale. A credit facility has interest accrual, amortisation, covenant events and workouts. A fund interest has capital calls, waterfalls and a wind down.
What servicing cost does not scale with is asset value. That single fact drives most of the economics.
Which is why small assets lose money
Platform fees typically scale with asset value, assets under management or issuance size. Servicing cost scales with holders and periods.
A large asset with a handful of institutional holders is cheap to service and pays real fees. A small asset with several hundred retail holders pays modestly and carries the heaviest support load on the platform. That is the worst combination available, and the deal most platforms are tempted to accept early, because it demonstrates the fractional ownership story.
The discipline that follows is unglamorous: establish a minimum viable asset size, work out the holder count at which per holder costs exceed your fee, and decline below the line. Honest scoping means saying so at the pitch stage rather than discovering it in year two, when the asset cannot simply be removed.
The costs that stay silent until they are not
Several failure modes on a tokenization platform produce no error. The system keeps working while quietly breaking, and you learn about it through a complaint.
Verification claims expire. Identity attestations carry expiry dates, and when one lapses the holder becomes unable to transfer with nothing to tell them. You need a pipeline tracking expiries, prompting renewal and reissuing claims, plus a support path for whoever hits it mid-transaction.
Claim issuers change. If an issuer's signing key is compromised or the relationship ends, verification breaks for everyone they attested to. Write that procedure before you need it.
Reconciliation drifts. Contract state and the corporate register diverge slowly through edge cases nobody catalogued, and without a scheduled comparison the gap surfaces during an audit.
Distributions go unclaimed. Holders change wallets, lose access, or do not act. The accounting and the obligation persist.
Valuations go stale. Where an asset needs periodic valuation, a missed cycle affects reporting, redemptions and anything priced off net asset value.
Each needs a monitor rather than a feature. If nothing is watching, the first signal is an investor who cannot do something they expected to.
The second asset class is where platforms get rebuilt
Identity, eligibility, the register, payment rails, and support are common across asset types. Lifecycle logic is not.
Build the first asset's lifecycle into the core and the second class becomes a fork: two platforms to maintain, two reconciliation processes, two sets of upgrades to review. Build the common layers as shared services with lifecycle logic pluggable above them, and the second class is a module.
This gets decided before the first issuance, because retrofitting extensibility costs more than designing it, and the pressure to ship the first deal is exactly when the shortcut gets taken.
Corporate actions are the recurring work with a human in it
Distributions look like an on-chain operation and mostly are not. Each holder's amount depends on withholding that differs by jurisdiction and status, so the calculation sits off-chain in systems that know what the contract does not. The chain pays a figure decided elsewhere.
Capital calls are harder, because the holder owes rather than owns. Assessing whether a transferee can fund a call is a credit judgement, and the remedies for failure sit in the governing documents.
Forced transfer and recovery are necessary and must never be casual. A court orders a transfer, a holder loses wallet access, a screening match requires a freeze. Each needs a named approver, a constraint on their authority and a record of every use.
Each is a workflow with an approval step, not a function call.
Privileged capability, and what you hold at the end
Minting, freezing, forced transfer, recovery and upgrades each need a named holder, a technical constraint such as a multisig with a timelock, and a written trigger. Independent review should cover the registries, the compliance modules, the role assignments, the upgrade path, and the off-chain services rather than the token contract alone, and it should repeat after every change to deployed logic rather than once before launch.
On ownership: you should end up holding the keys, the repositories, the deployment scripts, the infrastructure configuration and the documentation, with another team able to operate the platform from that alone. A system recording investor positions in assets with ten-year lives is a poor thing to make dependent on one supplier's continued existence, and that dependency reprices itself at every renewal.
When the economics say do not operate
We build these platforms, so weigh our bias accordingly.
If you have one asset and a small investor base, subscription documents and a competent administrator cost less, carry no key custody obligation, and present no contract attack surface. If you want to issue rather than operate, using an established platform as an issuer avoids the entire servicing function, at the cost of fees and a roadmap you do not control. And if nobody in the structure needs to distrust the operator, a register maintained by an administrator on conventional systems does this job at a fraction of the running cost.
Each of those is a legitimate answer, and reaching one during scoping is cheaper than reaching it after a build.
Price it per asset, per year
Build the model before the platform. For a representative asset: holders, expected support volume, distribution frequency, jurisdictions in the holder base, valuation cycles, reconciliation effort, and the share of compliance operations, investor relations and finance time it consumes. Then compare that annual figure against the fees that asset generates, across its full expected life rather than its first year.
Run it for your largest plausible asset and your smallest. The second number matters more, because a platform's economics are set by the smallest asset it agrees to carry.
RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work on a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including cases where issuing through an existing platform is the better answer, and security review is continuous rather than a single sign-off.
📖 Read the full blog: https://www.rwaltz.com/blogs/rwa-tokenization-platform-development-what-you-build-and-what-you-then-operate
Connect with RWaltz:
LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com
Top comments (1)
This is a useful framing because tokenization is often sold as an issuance project when the durable work is servicing and compliance operations. I’d put expiry monitoring, reconciliation, jurisdiction-specific distribution rules, and exception handling in the first lifecycle design, not in a later operations backlog. The platform becomes trustworthy when those obligations are observable before a holder discovers the failure.