Welcome to the fourth (and final post) in our series on strategies to navigate the present and future landscapes of composable organizations.
You can read Part one here. Part two here. Part three here.
This piece takes into account the work of previous blogs and extends it by looking at specific strategies or blueprints for building web-3 native organizations. These blueprints can be used by folks looking to kickstart a new project or by veterans looking to power-up an old project. The article traces along the approach at Upside to building these organizations by gaining an understanding of the features required to build a minimum viable community, then uses these features to demonstrate composability, and concludes with a general summary of how this composability is packaged into the building processes at Upside.
Characteristics for Minimum Viable Communities
The evolution of concepts like community design, token design, and blueprints for Web3-native Organization did not happen overnight, nor did it arise without consideration for preceding contexts. Tracking back to Gall's Law, we know that any complex system that works inevitably arises from a simple system that works. This brings into focus Alexis Ohanian's notion of a Minimum Viable Community (because we can't have a complex community that works without a simple community that works), which emerged from his time observing the growth of the Reddit community.
We also know about the ways design and architecture and composability converge thanks to the work of R. Buckminster Fuller. In the book Pattern Thinking, Daniel López-Pérez crystallizes this relationship, noting "[i]n the space between the physical and the conceptual dimensions of architecture, lines, models, words and concepts serve as mediums from which to explore design as a process of translation, a search for new relationships and generalized principles that can contribute to disciplinary knowledge." This brings into view an idea offered by Tina He, Co-Founder and CEO at Station Labs, which serves as a key requirement for a thriving ecosystem for Web3-native organizations more than a year ago.
Early efforts to accomplish this goal – creating standardized suites of governance templates that support different objectives and structures – was undertaken by Wassim Alsindi, who developed TokenSpace as an effort to categorize the regulatory qualities of different cryptocurrencies back in 2019.
In this figure, Wassim uses a toy model to demonstrate the relative characteristics of Bitcoin (BTC), Ethereum (ETH), Ripple (XRP), EOS (EOS), Litecoin (LTC), Bitcoin ABC (BCH), Tether (USDT), Stellar (XLM), Tron (TRX) and Binance Coin (BNB) as unique assets behaving in a three dimensional plane. One axis depicts a token's Securityness. Another axis depicts a token's Commodityness. A third axis depicts a token's Moneyness. The specification of these tokens – their features, their behaviors in the real world, and their relative differences to other tokens – provide us with a composite understanding of each token.
For those looking to build their own tokens, there is another lesson that can be gleaned from this analysis, as well. That is, based on their features, their behaviors in the real world, and their relative difference to other tokens, each token will be uniquely situated to accomplish some set of behaviors better than other tokens with different designs. It is the same with fiat currency and legacy organizations. In some contexts, gold will be a better exchange of value than USD or market monies. In some contexts, an LLC will be more desirable than a C-Corp or a nonprofit. For additional reading that helps provide a more comprehensive overview of the conceptual ways the incorporation of computational technology can be used to create uniqueness among a set of given features, I recommend this article by Walter Maner.
The broader acknowledgment that one set of features will necessarily have a situation it is most (or least) suited for is a great entrypoint into the next topic about how to design tokens for specific outcomes.
Demonstrating Composability With Models and Features
Broadly speaking, composability is a system design principle that deals with the inter-relationships of components. In the context of Web3 and tokenization, composability covers quite a broad space. Currencies are composable. Organizations are composable. Incentives are composable. Even identity is composable.
Rooted in a similar conceptual context to Tokenspace, Packy McCormack and Tina He produced a really great chart in a recent post explaining the ins and outs of how to design token economies and program different types of value based on different types of incentives for different users.
Atomizing the functions identified above by McCormack and He into disparate parts in a Google Sheets notebook, I represented each criteria with an identification number for a simplified calculus for designing, deploying, and understanding the behavior of token economies.
By reorganizing the chart in order to produce identification numbers and sub-identification numbers, it is then possible to begin understanding token economies based on their behaviors and classifications. The following analysis walks through three hypothetical examples – token 1.03/2.02/3.04/4.03; token 1.04/3.01/4.06; and tokens Token 1.02/2.02/3.01/4.01 + Token 1.04/2.01/3.01/4.06 – to demonstrate how the design choices from McCormick and He result in a limited framework for composability for Web3 organizations and projects.
Example 1: Token 1.03/2.02/3.04/4.03
1.03/2.02/3.04/4.03 would likely be a security token because in most cases it would represent an investment contract under the definition provided by SEC v. W.J. Howey Co. (i.e., an investment of money, In a common enterprise, with the expectation of profit, to be derived from the efforts of others):
- the first numeric pair, 1.03, in 1.03/2.02/3.04/4.03 indicates the Underlying Value is Shares-like / ownership;
- the second numeric pair, 2.02, in 1.03/2.02/3.044.03 indicates the Supply Strategy is a Private Sale;
- the third numeric pair, 3.04, in 1.03/2.02/3.04/4.03 indicates the Utility is as a Store of value; and
- the fourth numeric pair, 4.03 in 1.03/2.02/3.04/4.03 indicates the Driver is to Get rewards (financial revenue / cashflow share).
Because we know token 1.03/2.02/3.04/4.03 would likely be a security token and because we know security tokens require transfer restrictions, then we know that there will need to be some limitations about who is able to access a particular token. The Upside Security Token can be configured after deployment to enforce transfer restrictions such as the ones shown in the diagram below. Each holder's blockchain wallet address corresponds to a specific category. Only transfers between blockchain wallet address groups in the direction of the arrows are allowed:
This type of token is recommended if you want to use your token to raise capital or if you want something that will be treated like a security. This is the approach taken when Upside helped build the Republic Note, a security token that has an underlying value of shares-like / ownership, a supply strategy of a private sale, a utility as a store of value, and that will provide rewards (financial revenue / cashflow share) in companies launched for Republic's investment platform.
Example 2: Token 1.02/2.04/3.01/4.01
Using the same type of reasoning as above, it is also possible to deduce that a hypothetical token 1.02/2.04/3.01/4.01 would likely be a utility token.
- the first numeric pair, 1.02, in 1.02/2.04/3.01/4.01 indicates the Underlying Value is Network Value;
- the second numeric pair, 2.02, in 1.02/2.04/3.01/4.01 indicates the Supply Strategy is a Demand-driven;
- the third numeric pair, 3.01, in 1.02/2.02/3.01/4.01 indicates the Utility is to Access rights (to work, to use, to vote); and
- the fourth numeric pair, 4.01, in 1.02/2.02/3.01/4.01 indicates the Driver is to Get access (to product, services, content, etc.)
Here, hypothetical token 1.02/2.04/3.01/4.01 only serves a purpose from being used as a mechanism for accessing rights or services from a limited network of participants (i.e., a utility) that is able to be used by the holder. As such, it is not an investment contract because any value comes from use by the holder.
This type of token is usually suited to launching a membership network for some network of users. This is the approach taken by TurnKey Jet, as described in the SEC's No Action Letter which designates the token as a utility token. Something else of note is that this token is only available to be transferred to other members within the private permissioned network.* The toy framework from above and offered by Packy McCormack and Tina He does not explicitly describe the differences between public and private blockchains, nor does it list who a token's investors are (which also has a bearing on the security status of a token).
Example 3: Token 1.02/2.02/3.01/4.01 + Token 1.04/2.01/3.01/4.06
Tokens can be as simple or as complex as needed. In the context of a DAO, there may be a security token to fund the creation of a DAO and one utility token for internal members of the DAO, as well as a second utility token for external members of the DAO. The first token in example three functions more like a security token. The second token in example three functions more like a governance token.
This type of approach is recommended if you want to launch a complex token economy that involves the funding of a company + a system to incentive the participation of users in a network. This is the approach taken when Upside helped launch $GARI, a social token on Solana that involves both fundraising and governance components for Chingari, a social media company with millions of active monthly users.
Bonus: Composability and Token Power-ups
This helps us demonstrate an additional insight into the Upside tokenization process: the basis of the type of token involved also tells us about the types of Power-ups available to a given token. For example, you would not use a Restricted Token Swap integration for a utility token because utility tokens by their nature are unrestricted.
This is the approach taken when Upside helped to power-up FreshCut Diamonds ($FCD) with a vesting contract for their existing ERC-20 token on Polygon.
Creating Institutional Knowledge at the Speed of Web3
Taken together, these examples represent just a snapshot of the types of projects we have been working on at Upside. Each example demonstrates some of the basic features and functionality between security tokens and utility tokens are also helpful to understand the calculus of building a Web3-native organization. Several realities will impact the relative growth of composable organizations within the Web3 space. In particular:
- The pace of development in the Web3 ecosystem leads to market asymmetries and has tended to favor experimentation over standardization;
- As other industries have demonstrated, composability is the result of coalitions, consortiums, and other collaborations where members work toward the same goals – (see e.g., XBRL, NIST);
- Processes such as the creation of EIPs and ERCs are a great start to these challenges but will require systems-level thinking like that demonstrated by Packy McCormack and Tina He; and
- The most successful tokenization packages in the short term will be the ones that coordinate the backend complexity to deliver products that are easy to understand, simple to use, and deliver trustworthy results.
This all sounds complex, but there is hope for navigating this rapidly expanding space
At Upside, instead of attempting to navigate all of the complexity of such a broad landscape, we asked ourselves "what if it was possible to reimagine composability as a means to organize the paths forward for tokenization, based on empirical results, that are provably secure, repeatable, and easy?"
This is where we see our competitive advantage. The approach to tokenization at Upside is one that bakes in knowledge for projects that are seeking to launch new tokens and people who are looking to tweak the incentives of tokens that are already out there. We work with a veritable smorgasbord of experts to identify the easiest pathways for navigating the creation of innovative organizations in Web3. This approach also has enabled us to establish a history of launching cutting edge crypto products with regularity (e.g., the first Reg CF+ compliant token launch in 2017 with Props, launched Vevue, a Security Token for a Wyoming Blockchain DAO Corp in 2019 with complex transfer restrictions for private round investors, pull based airdrops for DappRadar saving over $1M in Ethereum gas fees, etc.).
Our solution to accomplish this involves a collaborative approach to development and standardized deal packages based on a knowledge of having been through the fires since the beginning of Web3. To ensure we are optimizing the tokenization process for adoption in the real world, we work closely with a number of partners, including Republic Crypto (check out their cool new site) and a number of others who know what they are doing at each phase in the tokenization process.
Passing the Benefits Along to Clients
To make this process seamless for customers, we have tailored our product offerings to ensure that we can provide you with what you need at any phase of the tokenization process using components that have been trusted to create repeatable deal patterns and less general regulatory uncertainty as popular paths for development are worn.
Until that point, throughout the process of token engineering for different systems and building Web3 organizations, it is important to understand the impact of different sequences and the unique set of options available at different points in a token's lifecycle.
If you want to learn more about our packages, visit upside.gg/packages
-------------
Editor's Note: Upside did not work with TurnKey jet, they were selected to write about in this article because they are definitively a security token (as described by the SEC's aforementioned No Action Letter).
