Tokeda Criticism

Blockchain and Network Utilization

One of the primary criticisms of on-chain tokenization is that it consumes precious blockchain and UTXO space so I’ll lead off with that. Let’s see how Tokeda compares.

Specification Fantasy

The Tokeda proposal is organized with 16 pages that makes general statements about Tokeda, describing token philosophy and use cases and how Tokeda fulfills them. It then finishes with 3 pages of specification (pages 17 to 20), and finally includes an appendix with 10 pages of extended use cases.

“Specification Fantasy” Examples

Token Capabilities (page 16)

Exchange

Atomic exchange is not defined. It seems likely that atomic exchange (Alice sends Bob token X and Bob sends Alice token Y atomically) would be very difficult since token transfer is itself not atomic, unless Trent is the issuer for both tokens.

Issuer Best Practices — Key Rotation

Issuer key compromise is an ever present risk. Even if multisig addresses are used, best practices is to allow rotation of key material in the case where a Tokeda signatory changes, or due to personnel changes within a signatory agency.

Issuer Best Practices — “Cold” key storage

Tokeda issuer keys must be used to sign every transfer so offline key storage seems to be impossible. However, if this same key is compromised, it seems that it can be used for any Tokeda operation including minting new tokens.

Questions

(the questions seem endless but here are a few)

What if…

  1. Alice needs change (in tokens)?
  2. Alice sends a token-decorated UTXO to someone who is not Trent?
  3. Alice wants to combine UTXOs?
  4. Alice’s request to send to Bob is denied by Trent?
  5. Trent makes a mistake?
  6. Validators spot a mistake? Is there a protocol to communicate that?
  7. Validators lie about a mistake? (Are fraud proofs possible)

How is…

  1. Bob identified in the Tokeda metadata?
  2. Trent choosing the output script when sending to Bob?
  3. The “inner payload” defined for anything but the initial token creation?
  4. Trent going to communicate transfer problems to Alice (and Bob)?
  5. Alice going to get the BCH in a Tokeda UTXO back?

Conclusion

Although much of Tokeda is completely unspecified, it seems to propose a system where token holders control a UTXO that should only be spent to the issuer, who has the opportunity to apply arbitrary policy before forwarding the spend to its actual destination. It is therefore an authority-based, SPV capable system. However it ineptly deploys the power of authority-based systems resulting in problems easily solved by other authority systems.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store