Digital Assets
From issuance to the final state.
Digital assets, in this practice, are entitlements a business issues to customers or partners: loyalty points, collectibles, passes, credits and other fungible or non-fungible tokens. ColdAI designs the entitlement and the user journey, integrates tokens with wallets and applications, and builds the admin tooling that keeps every asset accounted for from issuance to retirement. The aim is a programme people use, not a token that merely exists.
The opportunity
Start with a decision
worth improving.
A brand wants a digital entitlement that can be issued, redeemed and tracked. The customer experience must remain coherent when transactions fail, ownership changes or an entitlement is retired.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Design the entitlement
Specify what the digital asset represents, who may hold it and which actions change its state. Select a technical standard based on these requirements rather than market fashion.
Connect the experience
Integrate issuance and transfers with the application's identity and wallet approach. Make transaction state understandable to users, including pending, failed and completed actions.
Manage the lifecycle
Provide administrative tools and reconciliation for the defined asset. Track redemption or retirement and document how support teams investigate a mismatch or disputed action.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Digital-asset and user-journey design
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Token and wallet integration
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Administration and lifecycle reporting
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into consumer digital assets
Two decisions that shape most consumer programmes: whether points belong on a ledger at all, and how people should hold what you issue.
- 01GuideTokenised loyalty points: when they beat a databaseWhen putting loyalty points on a ledger helps and when a database is better: coalition settlement, transfer rules, IFRS 15 accounting and regulatory flags.
- 02Buyer's guideCustodial, embedded or self-custody wallets for consumersA buyer's guide to the wallet behind a consumer digital asset: custodial accounts, embedded MPC wallets, smart accounts and self-custody, scored side by side.
The lifecycle every digital entitlement goes through
Each state needs a rule for who can trigger it, what the user sees and how it is reversed if something fails.
- Issue
Assets are minted or allocated under an approved policy, such as points earned on a purchase or a pass bought at launch.
- Distribute
Assets reach user accounts or wallets, singly or in bulk, with the programme paying network fees where needed.
- Hold and use
Users see balances and benefits in the app; the asset may give access to events, discounts or content.
- Transfer
Movement between users or to partners, only where the programme rules allow it.
- Redeem
The asset is exchanged for a good, service or experience and changes state so it cannot be used twice.
- Retire
Assets are burned, expired or frozen at the end of their life and the programme's records are closed.
Points, collectibles and passes need different designs
The type of entitlement shapes transfer rules, redemption and support long before anyone chooses a token standard.
| Design question | Fungible points or credits | Unique collectibles | Edition passes and tickets |
|---|---|---|---|
| What the holder has | A balance of interchangeable units | A specific item with its own identity and history | One of a set of similar items, usable once or for a period |
| Typical transfer policy | Closed, or gifting within the programme | Often open, sometimes with creator royalties | Restricted or controlled resale to limit touting |
| Redemption | Units burned or returned to treasury | Usually none; the value is ownership or access | Marked as used at the door or on activation |
| Supply control | Issued continuously against spend or activity | Fixed at mint | Fixed per edition or event |
| Typical support question | Where did my points go? | Is this item genuine, and who owns it? | Why was my pass rejected at entry? |
| Main risk | Liability growth and account-takeover fraud | Speculation, copied artwork or misleading metadata | Duplicate use and secondary-market abuse |
Standard selection, such as native tokens versus EVM contracts, comes after these questions and is covered on our Hedera Token Service pages.
Designing for pending, failed and disputed transactions
From a user's point of view, ledger transactions are not instant. A transfer is submitted, reaches consensus and is confirmed back to the application, and any step can fail: the receiving account may not yet be able to accept the asset, the fee-paying account may be short of funds, or a request may time out after it has in fact succeeded. A digital-asset programme feels dependable only if the application models those states explicitly instead of assuming success.
In practice that means idempotent requests, so a retry never issues or burns twice; an in-progress state the user can see; automatic completion or reversal of interrupted operations; and a support view that shows a customer's history in plain language, found by customer account rather than wallet address. These are application concerns, not token features, and they decide whether a programme generates complaints or confidence.
Admin and support tooling to have in place before launch
How ColdAI builds a digital-asset programme
The work follows the lifecycle above and the phases of our Hedera engagement model, from architecture through build, launch and operation, adapted to whichever network the programme uses.
Define the entitlement and the journey
Agree what the asset represents, who may hold it, which actions change its state and what users see at every step, failures included1.
Choose the network, standard and wallet model
Select the token approach, from native Hedera Token Service tokens to ERC-20, ERC-721 or ERC-1155 contracts, and the wallet model, based on the entitlement rather than fashion.
Integrate tokens with the application
Connect issuance, transfer and redemption to the app, the CRM and point-of-sale or booking systems, with sponsored fees and clear transaction states.
Build administration and reporting
Deliver the admin console, reconciliation jobs and lifecycle reports that finance, support and programme teams rely on.
Launch and operate
Release in stages, monitor issuance and failures, and if you prefer not to run it yourself, operate the programme under a retained engagement with monitoring and on-call support2.
Where consumer token programmes go wrong
Perks that start to look like investments
Early signalMarketing talks about value rising, or a secondary market starts pricing points or passes.
MitigationKeep the focus on utility, restrict transfers that add nothing for members and have counsel review classification; our tokenisation hub covers the wider question.
Royalty income that never arrives
Early signalThe business case depends on resale royalties from collectibles.
MitigationTreat royalties as uncertain: payments settled outside the transfer, or on platforms that ignore them, bypass the royalty logic.
Users locked out of their assets
Early signalSupport tickets about lost phones, forgotten logins or accounts that cannot receive assets.
MitigationChoose a wallet model with tested recovery, and allow automatic token association or sponsored set-up so assets always arrive.
Ledger and business records drift apart
Early signalFinance, CRM and ledger balances disagree and nobody owns the difference.
MitigationReconcile automatically, define which record is authoritative for each purpose and give every break an owner.
Frequently asked questions
What counts as a digital asset in this practice?
Entitlements that exist only in digital form and are issued by a business: loyalty points, credits, NFT collectibles, membership and access passes, tickets and similar tokens. Tokens representing property, bonds, commodities or other real-world assets belong to our real-world asset practice, and tokens bound to physical products to our phygital assets work.
Do people need to understand crypto to take part in a digital-asset programme?
No. Most consumer programmes hide the ledger: users sign in with an existing account, the programme holds or manages keys and network fees are paid on their behalf. Wallet details appear only for users who ask to export assets or connect their own wallet. The trade-offs between custodial, embedded and self-custody models are set out in our wallet strategy guide.
Which networks and token standards do you work with for digital assets?
Our digital-asset work covers ERC-20, ERC-721 and ERC-1155 contracts and Hedera Token Service tokens, with multi-chain deployment where a programme needs it. We recommend a network and standard once the entitlement, wallet model and transfer rules are defined, because those requirements usually narrow the choice considerably.
Can issued digital assets be revoked or reversed?
Only if the programme is designed for it and the terms say so. Administrative keys can freeze, wipe or claw back assets in defined circumstances, such as fraud or a mistaken issuance, but those powers must be disclosed, protected by approvals and logged. Assets presented as fully user-owned should not carry hidden reversal powers.
What do you need from us to start a digital-asset project?
A clear description of the entitlement and its audience, a view on how users should hold it, and the rules for transfer, redemption and support. Access to the product owner, to the systems the programme must connect with, such as CRM, point of sale or booking, and to someone in legal or compliance for early classification questions keeps the design phase short.
Sources
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A clear entitlement and audience
- An identity or wallet strategy
- Transfer, redemption and support rules