HandCash / Tokenized Consideration

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:

Going full HandCash is tempting

Medium can’t do tables… Please visit our FAQ if you’d like to read this post in all its glory (including links).

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 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):

Questions for Tokenized

Double spend resolution

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.

Scalability

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.

Fraud prevention

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.

Privacy

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.

Concerns with HandCash / Tokenized integration

1. Delivery could take longer than expected. Paymail / p2p are not implemented yet, nor are features such as automatic reconciliation
2. Tokenized has not been implemented in production yet. Any potential issues will likely remain unforeseen until Tokenized is in production (also exacerbating 1)
3. 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
4. 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.
5. 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.
6. 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’

DXS actions

1. 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
2. Consider including USDC-Tokenized to USDC-STAS bridge feature within Fiorin wallet
3. 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
4. Look to integrate Tokenized for address / key management for our BSV cold wallets