HandCash / Tokenized Consideration
A deep dive into the HandCash / Tokenized partnership and implications for DXS
Last updated
A deep dive into the HandCash / Tokenized partnership and implications for DXS
Last updated
HandCash recently announced they will be using Tokenized for their fungible token platform.
This prompted another DXS deep dive into Tokenized’s offering. As always, we will share our thinking publicly in the hope that the whole industry can benefit from our due diligence.
But first, let’s anticipate HandCash’s product roadmap and implications for DXS:
HandCash feature
Implications for DXS
HandCash enables Business Wallets, allowing connected apps to outsource their address / balance / token management and transaction broadcasting functions
Reduced latency for margin return and profit return transactions
Greater security for our margin and liquidity addresses
Reduced in-house technical burden (no more broadcasting to miners)
Improved scalability
Simplified token management (simple API)
HandCash integrates USDC. The UI allows users to select which account to view, BSV or USDC. The UX remains the same.
Circle act as the liquidity provider / trust holder of USDC
HandCash act as the Tokenized USDC ‘issuer’
Tokenized host the USDC smart contract agent on Handcash’s behalf
USD backed trading gives users a familiar and intuitive trading experience.
Excessive volatility of the settlement unit is eliminated, allowing traders better control of their trading capital
Liquidity fundraising is more attractive to OLP liquidity providers. 10% APR in USDC carries less risk than 10% APR in BSV
HandCash enables credit card onboarding of USDC in their web and mobile app
Credit card funding allows anyone with a debit / credit card to top up USDC instantly
HandCash pays BSV transaction fees on behalf of its users. It is no longer necessary for users to have BSV
No transaction fees make a trader’s profit and loss more intuitive while eliminating the requirement for a user to already have BSV
HandCash provides in-app deposit addresses for USDC, EUROC and USDT (Tron). In the case of USDT (Tron), deposited amounts are automatically exchanged for USDC and credited to the user’s wallet
The ability to deposit major cryptos (in particular USDT Tron) and have them swapped to USDC gives anyone with a crypto exchange account one hop access to HandCash apps. The addressable market of users is enormous
HandCash enables App Hosted Wallets, allowing connected apps to provide limited feature set wallets secured to Google Logins
Users can be onboarded instantly, even if they don’t have a HandCash wallet
The above feature list is certainly compelling. Additionally, HandCash is the preferred wallet of DXS traders:
Can we conclude from this that HandCash solves all DXS problems and DXS has a clear path to viral growth?
Quite possibly, but going full HandCash could prove to be risky. To understand how we assessed this risk, let’s first consider the Tokenized protocol:
The foundation of the Tokenized protocol is the Smart Contract Agent (SCA). Every token has its own SCA.
A SCA is a P2PKH bitcoin address AND an off chain state machine (smart contract), run by (or on the behalf of) the token’s issuer. The state machine receives input information (bitcoin transactions) and responds with deterministic output (bitcoin transactions). Each SCA’s ruleset is publicly codified and as a result, anyone processing the same inputs will arrive at the same output (state).
What is the implication? Token settlement is completely transparent. Rules / state can only be violated in public and such violations are necessarily signed by the SCA itself.
Once reaching this level of understanding, you’d start asking the following questions (don’t worry, we asked them for you):
DXS: The Tokenized documentation indicates that the SCA uses the first seen rule and is more authoritative than the blockchain itself. In the event of a reorg double spend, will the SCA still follow the first seen transaction?
Tokenized: Yes, since the SCA is the single source of truth it doesn't need to wait for consensus with other parties, like miners do. As soon as the SCA settles a transfer it is settled. The worst that can happen is the transfer transaction is double spent and not mined into a block (which means the settlement transaction is too, since it is dependent) and the SCA or administrator will have to post a reconciliation to the blockchain to show what happened, since the settlement will no longer be on the blockchain.
DXS: And this reconciliation is a manual process?
Tokenized: Yes, it is manual right now, though the SCA or parties involved could share the settlement transaction off chain to show it was settled. We have plans to enable the SCA to do it automatically.
DXS: It appears that the blockchain isn’t used for doublespend protection but solely as a public immutable log allowing the SCA’s state to be derived / audited by anyone?
Tokenized: Yes, the blockchain is basically a ledger and public broadcast system.
DXS: The documentation reads like the SCA is not p2p at this stage. Will it eventually run the same paymail / p2p standard as HandCash and MoneyButton do?
Tokenized: We are still building the p2p functionality. It will be with peer channels as agents should be more independent and can't use paymail effectively. You will be able to submit a transfer to the SCA and it will respond with the settlement and merkle proofs. We are aiming for these features to be ready in October.
DXS: How could a SCA violate its own rules? For example, could a SCA create a fake request transaction, like transfer tokens to a user (tokens don’t exist) and then approve it with a response transaction?
Tokenized: Clients have to trust that any response transactions (signed by the SCA) are valid, so long as they follow the specification, meaning they are formatted properly and are syntactically correct. A custom implementation of an SCA could do whatever it wants, but the point of having it on chain is that it is auditable so they would be signing evidence of their fraud on chain. The idea is that there is trust required for the issuer no matter what because regardless of what happens on chain the issuer must still maintain whatever backs the instrument off chain, so if they are going to be fraudulent, then the blockchain can't stop that.
DXS: How private is Tokenized relative to native satoshis? It appears that requests and responses to and from the static SCA address are all in plaintext. Encrypting these payloads wouldn’t make any sense right?
Tokenized: Right, if the payloads were encrypted then they wouldn't be auditable. There are ways to encrypt it so that the SCA can provide auditors with access, but that kind of muddies the waters.
DXS: From a token holder’s perspective, how much privacy is there? We seem to recall that Tokenized is using an enhanced Benford’s wallet implementation? Does that mean when sending 100 tokens to a user, this amount is broken up and sent to different addresses (all controlled by the user)?
Tokenized: The protocol is just as private as bitcoin for holders as you can just use whatever addresses you want. You can spend an entire balance from an address and use change addresses in the same way as bitcoin. And yeah, our wallets don't technically use Benford's law, but randomly breaks amounts into "whole numbers" (ending in zeros) mixed with completely random numbers. It uses orders of magnitude and randomizes them so that no matter how much the input is it will break it into different orders of magnitude amounts so it is nearly impossible to determine which outputs are which.
Delivery could take longer than expected. Paymail / p2p are not implemented yet, nor are features such as automatic reconciliation
Tokenized has not been implemented in production yet. Any potential issues will likely remain unforeseen until Tokenized is in production (also exacerbating 1)
Tokenized actions (mint, transfer, redeem etc) will not work if the SCA goes offline. Contrast this with the STAS protocol that only relies on miners for all actions while leaning on an indexer for checks that can be run by any 3rd party
Tokenized does not use bitcoin for settlement. Tokenized only uses bitcoin for public auditability. The Tokenized philosophy is basically: “if there is dependence upon a 3rd party anyway, such as for issuance and redemption, then why not use that 3rd party as a SCA to make token actions more simple”. The problem with this philosophy is that a user must now trust (but can verify) two parties - the miners AND the SCA as an oracle, instead of trusting only miners through a non-authoritative indexer.
Vendor lock-in with Tokenized, meaning that we should either trust the Tokenized team to maintain our SCA or maintain it ourselves as an open source software.
Inheritance of an array of legal responsibilities and the need to directly resolve disputes stemming from the fact that Tokenized is custodial in nature. Similar to this, read Centi’s position on avoiding the legal implications of being a ‘payment processor’ vs being a ‘cash handler’
Continued development of Fiorin wallet, USDC / USDT ERC20 bridge and STAS tooling so we can pull the trigger on USD-backed trading on DXS as soon as possible
Consider including USDC-Tokenized to USDC-STAS bridge feature within Fiorin wallet
Keep an eye on the HandCash / Tokenized integration (in particular the HandCash roadmap). Remain open to transitioning token protocols if our concerns turn out to be unjustified and HandCash starts to generate serious network effects
Look to integrate Tokenized for address / key management for our BSV cold wallets
