G'day folks,
Firstly, it is our (I am speaking both on behalf of Tokenized and myself, where appropriate) contention that one token protocol will become the global standard for financial instruments and non-regulated utility tokens. However, I imagine there will be a few other token protocols that are more suited to/operate in certain niches.
I'd also like to prime your thinking with a quote from SJ to highlight the core design philosophy of the Tokenized protocol...something that I feel has not been well considered in all other token/smart contract protocols.
"You've got to start with the customer experience and work backwards to the technology." - Steve Jobs
Before I designed the Tokenized Protocol, I had spent quite a bit of time analyzing the potential value proposition of smart contracts, and Bitcoin/DLT/blockchain more generally. I had written a number of white papers on potential business models that used smart contracts/tokens, and spent a long time thinking through the customer experience from the perspective of all sorts of potential issuers and token holders, for the entire lifecycle of many common financial instruments. To summarize, I built the Tokenized Protocol with the customer in mind, not the technology.
Some important questions we think are worth asking when considering the pros and cons of various solutions:
- What makes a 'smart' contract better than a traditional contract?
- Are there opportunities to improve the way that contracting is done on a systemic level?
- Why do we need Bitcoin for smart contracts?
- Are there opportunities to improve the way that the global financial system operates?
- What products/services can be disintermediated by a DLT-based smart contracting system?
- How is AML/CTF managed effectively?
- What are non-negotiables with respect to law?
- How do regulators/government agencies interact with this system?
- How do agents of commercial entities interact with smart contracts?
- What is important to a token holder over the lifecycle of the contract?
- What is important to an issuing entity over the lifecycle of the contract?
- How low can you drive the costs of issuing, managing, and trading smart contracts?
- Where should the scope limits of the token protocol be drawn?
- What are the common features shared by various contracts across jurisdictions/legal systems?
- Which terms and conditions can be interpreted/enforced by software? What cannot?
- How can the design be optimized for performance? cost? simplicity? privacy? accountability? interoperability?
We have answered all of those questions, and more, and spent a lot of time balancing the choices/parameters. However, I don't believe it is in the company's (Tokenized) best interest to reveal all of our conclusions/reasoning at this point, but suffice it to say, we are confident our design is the optimal solution, and we look forward to competing in the market.
For bitcoin itself, a customizable locking script on a per-txn/output basis works beautifully. However,
most financial instruments have a number of 'contract-wide' terms and conditions that issuers/token holders want to control...and those terms and conditions can and do change over time. To better understand this, I suggest having a look through a few shareholder agreements, trust deeds, and debenture agreements. I am sure you will quickly see all sorts of terms and conditions that affect/restrict ownership status and secondary trading. These types of terms and conditions are common to most financial instruments, and can be codified such that software can interpret and enforce. However, it requires an approach like the Tokenized Protocol to solve well, and L1 tokens will not be able to solve the problem in a competitive manner. Think about what happens when you need to amend a contract-wide term that has tens of millions, or even billions, of tokens in circulation... Now have a look at how the Tokenized Protocol would accomplish this task:
https://tokenized.com/docs/protocol/actions#action-contract-formation
We suggest that a basic token with a basic contract-wide locking script, with most of the terms and conditions contained inside a referenced agreement (e.g. pdf), does not offer much value. It remains a largely manual task to issue, manage, and trade tokenized financial instruments. The real value of smart contracts is making all of the terms and conditions codified and 'smart', so that software can automate many of the routine administrative processes, and for the commercially relevant actions/events to be recorded to the blockchain by the agents that were involved.
To better illustrate our line of reasoning, I think it is worth thinking through one important and common example.
Example: When a private company has a requirement for all secondary transactions (shares) to be approved by the board of directors or shareholders. More info:
"
Board Approval Right. A right of first refusal is a useful device for controlling ownership of stock only to the extent that the company or its assignee is willing and able to spend the necessary funds to purchase the shares. Otherwise, the shares can be sold to the proposed buyer. As secondary transactions have increased in popularity and valuations have grown, it has become increasingly common for bylaws to have a separate requirement for board of directors approval of any transfer, with only limited exceptions such as estate planning transactions." [from
https://www.cooleygo.com/secondary-sales-of-private-company-stock/]
How would you specify that right/restriction in code? Perhaps a multi-sig script with each of the board of directors signing-off on each transaction? What happens if a director leaves the company? What about when the shareholders need to sign-off on the trade? Does that simply become a resolution via email that then gives permission to an admin key to approve a transaction? Not really an improvement over what we have today...
What about when a company goes from private to public? How do you coordinate contract-wide amendments when there are millions of token holders? Perhaps the shareholders can use custody services to manage admin like this because of the inherent limitations of such a system? I suggest that this is simply pushing the important terms and conditions/commercial actions,
that can be codified, off-chain and into non-codified and manual processes using email, or the like....what a missed opportunity!!!
Who really cares about a non-custodial solution where the user controls the private keys to an on-chain share certificate, if the real record of ownership is contained in an email trail and pdf agreement...
What about an expiration date for a contract? Some tokens need an expiration date, but what happens if that expiration date needs to change?
What about the issuance of a different class of shares?
We have considered all of these questions and built the necessary features/functionality to allow for maximum accountability and for
ALL of terms and conditions (where possible) to be on-chain and codified. Where any commercially meaningful action takes place, the Tokenized Protocol ensures there is one source of on-chain truth to record the agent(s) making the action, what the action is, and the resulting change to the state of the contract. And it can do so with software controlling their rights to do so. If you look carefully at our publicly available docs, you can see how we've solved these problems. Although there are a few things we haven't shared publicly just yet..
With all that said, we do see a lot of value in harnessing OP_PUSH_TX for reducing risk wrt to the operation of the smart contract agent, and some other components of the Tokenzied Protocol. As well as using sCrypt to improve the development experience for building locking scripts for our customers.
I also have a lot more to say on this topic that we can dive into, depending on how the conversation flows. I am also more than happy to answer questions/concerns/etc.
EDIT: a few typos/grammatical errors.
