Embedded wallets are intended to hide much of the blockchain complexity that has historically made crypto products difficult for mainstream users, but simplifying the interface does not remove questions around custody, recovery, compliance and cross-border settlement.
In this TNGlobal Q&A, Itai Turbahn, Vice President of Embedded Wallets at Fireblocks and co-founder of Dynamic, discusses the wallet infrastructure behind TrueMoney’s THBT Phase 2 in Thailand, including TSS-MPC security, assisted recovery, sandbox testing and what would need to change to expand the model across Southeast Asia.
TrueMoney’s THBT Phase 2 is designed so users do not need to manage seed phrases or private keys directly. From a product and infrastructure perspective, what has to happen behind the interface to make an embedded wallet feel as simple as an ordinary consumer payment account?
Three things have to come together to make embedded wallets feel simple for users, and most wallet products still only get one or two of them right.
Firstly, the sign-in process must feel like signing in anywhere else. Dynamic issues wallets through email, social login or passkeys, so opening THBT for the first time will prompt authentication the same way it would for any app, and a device’s own biometrics do the job a seed phrase used to do.
Secondly, the security features working behind-the-scenes have to work harder, while also showing up less. Dynamic’s embedded wallets run on TSS-MPC, threshold signature scheme multi-party computation, where the key exists only as shares held across the user’s device and in Dynamic’s systems. A complete private key is never assembled anywhere, and signing still happens in under a second, fast enough that a payment confirms as quickly as tapping to pay with a card.
Finally, the user experience should be designed such that a user will never have to think about chains at all. Whichever network a product like THBT runs on, the wallet underneath is built for multichain use, so the network decision can sit with the product team rather than the person trying to pay.
Once all three are successfully implemented, the wallet would stop feeling like a Web3 product and more like an account with a balance and a pay button, which is what TrueMoney is aiming for.
Assisted recovery removes one of the biggest usability barriers in self-custody, but it can also create new security and account-recovery risks. How does Dynamic approach recovery without simply shifting the weakest point from private-key management to identity verification, customer support or account takeover?
We specifically designed Dynamic’s recovery protocol to tackle the industry’s common marketing of “simple recovery” which, in reality, refers to calling a support hotline and working through the system, and does not actually remove the weak point. Instead, it simply enables the problem by allowing it to continue to a support agent who is likely to only solve the user issue, but not the root problem.
A Dynamic wallet is secured through distributed key shares, one held on the user’s device and one held by Dynamic, and both are needed to sign. The user’s share can be backed up in encrypted form through a separate service that Dynamic itself cannot decrypt without the user present. When someone has both their device share and their backup, they can recover, and even export their wallet, entirely on their own, without ever needing our side of the key share.
Recovery is not just one identity check that a bad actor could aim at, it is a combination of independent factors. Hence, a support agent resetting a password is never, on its own, enough to move any user’s fund.
The best method to manage this is by setting the threshold. Dynamic supports configurable schemes beyond the default, such as 2-of-3. If made too loose, recovery could become the attack surface, but if too strict, even users could get locked out of their own accounts. As such, this is a deliberate choice for every deployment, and one that TrueMoney’s team worked through with us specifically for THBT.
In an embedded-wallet model like this, what should users understand about who actually controls the wallet and assets at each stage of a transaction? Where do you think consumer products need to be clearer about custody, permissions and responsibility?
Every transaction requires the user’s key share to take part in signing, so nothing can move without the user’s device being involved.
This is what makes embedded wallets self-custody, meaning it is a wallet the person actually owns, rather than a custodial balance sitting inside TrueMoney.
Where the whole industry, including us, still owes people more clarity is in separating that ownership from everything happening around it. Swapping into THBT, or spending it through THBTStore, runs through a regulated operator carrying out that specific service under its own license, in this case Ascend Bit under the Thai SEC’s Sandbox. The wallet and the transaction processing are completely different jobs, so clarity means someone should be able to see this distinction from the moment they act, instead of having to dig for it later.
In practice, consumer trust in this category is won by stating plainly in the interface itself what the user controls, what happens automatically behind the scenes, and making it clear where a licensed third party is brought in.
THBT is being tested under the Bank of Thailand’s Enhanced Regulatory Sandbox, with Phase 2 expanding to as many as 20,000 participants. What technical or operational questions can a sandbox reveal that would be difficult to answer in a closed pilot or laboratory environment?
A small pilot with a few hundred crypto-native testers helps to prove that the system works, but a pool of twenty thousand real participants confirms that the system works for people who have never held a digital wallet before.
This provides a real-world look at the onboarding drop-off instead of a modelled estimate, a genuine volume of recovery and support requests, and the actual mix of everyday transactions, including the cross-border swap for tourists and expats, which is nearly impossible to simulate convincingly in a lab. Equally as valuable, it can also reveal where users tend to get confused, and this is usually never where an engineering team would have initially hypothesised.
Running compliance and reporting continuously under a live sandbox, rather than as a one-time exercise, gives the most realistic feedback for a production in the development stage.
One of the more distinctive use cases is for tourists and expatriates who can swap supported digital assets into THBT for use within the TrueMoney ecosystem. What are the hardest parts of making that cross-border flow practical at consumer scale, particularly around liquidity, compliance, settlement and user experience?
As THBT needs a dependable rate and real depth for the supported assets at the exact moment a user wants to swap, liquidity must come first.
Following very closely behind is compliance, as a user swapping assets from outside Thailand will be touching on more than one jurisdiction’s rules in a single action, so that flow has to run through a properly licensed operator. Ascend Bit’s role in swapping THBT with the six supported digital assets, and the THBTStore purchases, managed under the Thai SEC’s sandbox carries as much weight as the technology underneath it.
Making purchases should also feel instant, so the swap and the spend settlement speed needs to feel like one motion.
And finally, the user experience is the most challenging to uphold while being practical, because when it is working, none of the above should be visible to the user at all. For example, a visitor to Thailand should not need to know what a swap is, what a digital asset is, or what regulatory sandbox is running underneath. True quality user experience means they should be able to simply see their balance convert and spend it. As such, the three former above must be solved before this level of invisibility is possible.
Fireblocks has described the goal as making the blockchain infrastructure effectively disappear from the user’s perspective. Where does blockchain infrastructure actually add enough value to justify the additional complexity underneath, compared with conventional payment rails?
The value of utilising blockchain infrastructure shows up best in three places. Firstly, speed and availability: to ensure money can move continuously on-chain, 24 hours a day, seven days a week without waiting on banking hours or a chain of correspondent banks, and is exactly what the cross-border swap in THBT depends on.
Programmability comes second: compliance rules, transfer limits and policy controls can be built directly into the transaction itself instead of checked after the fact, which is the only reason a regulator lets a sandbox like this run at all.
Third, and perhaps the most underrated, is distribution. An embedded wallet means it sits inside an app people already open every day, so TrueMoney did not have to build a separate rail or make existing users adopt new software. This means the infrastructure can be implemented in a product that is already widely trusted and used.
Complexity is no good on its own, and it can only earn its place by solving something conventional rails genuinely are not able to, which the tourist swap in THBT serves as a fair test of that.
What metrics would tell you that an embedded wallet deployment has succeeded beyond registrations or transaction volume? Are there particular indicators around failed transactions, recovery requests, conversion rates, repeat usage or support burden that you watch closely?
Registrations and transaction volume illustrate how many people showed up and attempted to move money at least once, but the metrics that indicate deployment is working are much quieter than that.
In a perfect world, a well-built system means that most users never have to think about recovery at all, so a rising rate is usually more revealing about onboarding or device continuity, rather than support load.
Failed-transaction rate is more reflective of the problem than raw volume, because it points straight at where the interface or the liquidity underneath is letting users down. Repeat usage, not just a first transaction, is the clearest sign that trust was truly earned rather than just curiosity satisfied. Support tickets tied specifically to the wallet, not the app in general, also honestly show how much complexity was successfully hidden or redirected to a call center.
If this model were extended to other Southeast Asian markets, which parts of the TrueMoney implementation could be reused relatively easily, and which parts would need to be redesigned around local regulation, payment infrastructure and consumer behavior?
The sign-in model, the TSS-MPC security and recovery design, and the multi-chain foundation underneath are not specific to Thailand, and versions of them are already running for consumer products elsewhere.
What has to be rebuilt market-by-market is the compliance layer, because regulators across the region each has its own sandbox and licensing path. The same goes for the licensed partner on the ground executing swaps and compliance, such as Ascend Bit’s role for THBT. Local payment rails, QR standards and everyday payment habits differ enough between markets that the experience itself needs to be localized and not a shortcut translation.
Itai Turbahn is Vice President of Embedded Wallets at Fireblocks, where he leads consumer-facing wallet infrastructure following Fireblocks’ acquisition of Dynamic, the company he co-founded and led as CEO.
Editor’s note: This Q&A has been lightly edited for clarity and TNGlobal house style. The substance of the interviewee’s responses has been preserved.
Share your perspective: TNGlobal welcomes contributed insights and expert commentary from across Asia’s technology and innovation ecosystem. Submit a contribution for editorial consideration, or explore more conversations in our TNGlobal INSIDER and TNGlobal Q&A and Interviews archive.
Asialink’s Patricia Poco-Palacios on scaling MSME lending with credit discipline [Q&A]