Asset tokenization costs: how to build a project budget

Asset tokenization allows certain rights to be represented in a digital record and operations involving them to be managed through software. For a company considering an issuance, the budget needs to cover both launch and subsequent administration: defining the product, building the technology and organizing investor onboarding, payments and recordkeeping.

The total cost depends on the right being issued, the jurisdictions involved, the participants and the required functionality. The network fee for creating a token is only one item. A useful estimate separates initial investment, recurring expenses and usage-based charges, showing what each provider includes and what the issuer will contract directly.

What the budget covers

Before comparing amounts, distinguish the underlying asset from the instrument offered to investors. A property, for example, may be connected to a debt offering or shares in a company. Each structure involves different rights, documents and processes. The token needs to represent those rights under the applicable legal structure; creating it does not by itself transfer ownership of the property.

BIS Bulletin 72 places tokenization along a continuum of economic, legal and technical challenges. For budgeting, this has a practical implication: describing the transaction first helps identify the work its digital representation requires. The asset value alone does not describe that work.

The scope of the budget also needs to be agreed. Buying a property, carrying out construction work or providing capital to a company belongs to the underlying transaction. Keeping those amounts separate from structuring, issuance and administration expenses avoids presenting the capital raised as the technology cost.

The items a tokenization budget should include

Legal and tax structuring

This work establishes the rights investors receive, the party accountable to them and the documents, records and participants the transaction requires. Depending on the project, it may include setting up or adapting an entity, contracts, offering documentation and tax analysis. The estimate should identify each adviser's deliverables and any third-party charges, taxes or fees excluded.

Country is not a single input. Identify where the asset is located, where the issuer is incorporated and the markets in which the product will be offered. These questions guide local review; they do not all create identical obligations, and different projects may require different structures.

Technology and integrations

The technical scope includes token rules and the tools investors and administrators will use. Specify who can issue, transfer or redeem; how operations are approved; and what happens if a key is lost or a record needs to be corrected under the applicable procedure.

Integrations also require work. Connecting payments, identification, accounting or a custodian involves exchanging data, handling errors and testing the complete journey. An asset tokenization proposal should distinguish initial configuration, specific adaptations, licences and the handover of documentation and access. This makes it possible to compare scope beyond the number of screens.

Identification, custody and payments

Investor onboarding may require identity verification, checks on legal entities and eligibility controls. When external services are involved, ask about setup fees, minimum charges, included usage and manual reviews. The number of people starting registration can differ from the number who eventually invest.

For custody and payments, establish who holds the keys, who can authorize movements and how incoming funds are reconciled with token allocations. Request each provider's terms for the intended product and countries, including incident handling and refunds. Integrating a service does not mean its fees are included in development.

Testing and security review

The estimate should specify what is tested and which version it covers: smart contracts, administrative permissions, the application and integrations. If an external review is commissioned, separate its cost from remediation work and verification of fixes. A report on one contract does not automatically cover the entire platform or subsequent versions.

Responsibilities matter alongside the report. Define who controls deployment keys, who authorizes changes and how incidents will be handled after launch.

Distribution and investor relations

Preparing commercial documentation, answering questions and arranging distribution may need a separate budget. If third parties participate, specify their role, any required authorization and the basis for commissions: committed capital, funds actually received or another agreed measure.

Issuing tokens does not bring buyers on its own. A secondary market, if included in the project, needs its own assessment and scope. Technical transferability does not establish that trading exists or allow liquidity to be budgeted as a guaranteed outcome.

Operations and maintenance

Holder support, payments, reconciliation, periodic information and record administration may continue after issuance. Technology expenses should account for hosting, monitoring, support, updates and service continuity. Define who performs each task and which changes fall outside the maintenance agreement.

On Ethereum, gas pays for the computation needed to execute operations. The transaction fee depends on gas consumed and its price; it is not the budget for building or maintaining the product. To estimate this component, identify the expected operations, their frequency, the network and who pays, instead of extrapolating from a single transaction.

How jurisdiction affects the cost

Product classification should precede the selection of a supposed regulatory package. As an example specific to the European Union, Article 2(4) of MiCA excludes crypto-assets that qualify as financial instruments. A proposal offering “MiCA compliance” therefore needs to explain which product and activity it covers.

This example does not establish the rules in other countries. To compare a domestic issuance with an offering across several markets, ask the legal analysis to identify the jurisdictions covered, the intended investors and the conditions for marketing. That definition helps estimate documentation, providers and integrations without assuming one solution works everywhere.

Consider a planning example: a debt issuance with an identified group of investors, one payment currency and a defined administrative process. If its scope expands to new markets, other currencies and transfers between holders, the team needs to assess what can be reused and what additional work documentation, controls and operations require. This is a scope change, not a fixed fee for adding a country.

How to compare the first-year cost

Ask each provider for an estimate covering the same period and assumptions. A useful first-year calculation is: initial expenses + recurring costs for the period + variable costs based on usage + a reserve for identified risks. The reserve should reflect specific dependencies rather than an invented universal percentage.

• Initial expenses: analysis, documentation, configuration, development, integrations, testing and launch work within the agreed scope.
• Recurring costs: subscriptions, hosting, support and operational tasks. Specify when billing starts and which usage is included.
• Variable costs: checks, transactions or services charged by volume. Define the billing unit, minimum charges and any percentage-based fees.
• Dependencies: work still to be defined, requested changes and third-party activities. Identify who prices them and what needs to be resolved to finalize the estimate.

Calculate at least an expected-activity scenario and a higher-volume scenario using the quoted rates. A lower initial price can coexist with higher recurring expenses, while reusable infrastructure may spread some work across issuances. Neither relationship establishes savings without a project-specific calculation.

To avoid double counting, give each item an accountable party, a billing unit and a deliverable or service. Also review taxes, currency, exclusions and exit terms: access to code and data, continuity of records and assistance with changing providers where applicable.

What to send when requesting an estimate

An initial brief can describe the asset and the right to be issued; intended jurisdictions and investors; issuance size and frequency; payment methods; and tasks the issuer will handle internally. Add existing systems, providers already selected and the functionality needed for the first release.

Not everything needs to be decided beforehand. Open questions can form a separately priced analysis phase with defined deliverables. Its outcome should make it possible to decide what to build, what to contract from third parties and how to fund operations after launch.

If you are preparing an issuance, you can share its scope with Metlabs to assess the technology and its dependencies. A comparable budget starts with that common definition; the amounts can then be read alongside the responsibilities and services they actually cover.