Tokens can be a powerful, interesting, and useful tool that can change the way protocols are designed. However, tokens are not the core of the design. Protocol design today is more like “alchemy”, than a discipline. This is because designers have limited knowledge and many projects require lots of experimentation. The taxonomy of tokens will then be discussed. The technology tree theory is the last part. It explains how technology can be used to improve our design.Thinking modeFirst tokens are not the goal. They are just a tool. Tokens can be used to decentralize a protocol. It is important that your goals are clear and concise. We should be able to clearly distinguish between success and failure. If we are unsure of our goal, we should start over and forget tokens. Goals should be measurable even if they aren’t clear. Phase 2: Introduce restrictions. In general, there are two types: exogenous constraints and intrinsic constraints. These are the ones that we choose to simplify the design process, either because of trade-offs or because they are trade-offs. Although they can be imposed by many sources, intrinsic constraints are usually created by the designer. Exogenous constraints are those that you are subject to by nature, technology, regulations, and other factors. I will discuss it later. Phase 3: Design mechanism. Once we have identified a constraint as well as a goal, we can begin to think about the mechanics that will achieve that goal. When we think of a mechanic, it should be clear if it violates these constraints and gets us closer towards that goal. A protocol is a collection of mechanisms that are all directed towards a particular goal, according to some constraints. Take MakerDAO as an illustration. Their goal is to create a stable native asset for Ethereum. There are many ways to define stability and nativeness. Common pitfallsToo much focus on tokens. Tokens are not protocols. Tokens should not be your goal. This should be a tool. How can you get out of this trap. Ask yourself, “How would this system work without tokens?” If the system fails completely when tokens are removed, you might be overemphasizing their role. It’s better to have a few parts of the system fail than none at all. Your token is important and necessary for the system’s overall balance, but it doesn’t make the system any less coherent. Design space is infinite. There are so many options and ideas in design that you can’t know where to begin. This is often due to the fact that the goal is unclear. It is important to clarify the goal. This could also be due to a lack of understanding or acceptance of the limitations placed upon you by the outside world. The first question that will limit your design space is: What is the strong idea you want to build? It could be some deep ideas, some benefits, or some changes in the current trend. What is this powerful concept? How can you make the most of it? Instead of focusing on the whole system, how can you focus on it? Another question is: What is the greatest weakness in this design? It’s not the design that you don’t like, but the things you worry about, the key weaknesses, or the points that might not work. What constraints can you accept to make it better? This can severely limit the design possibilities. It is possible to have difficulties in designing parts of the system. You can push them all to the community or expect unseen forces that will fill in the gaps. This is dangerous. Despite permissionless systems being very popular and the many innovations that have been made, it is impossible to predict what the community will do. Is it not enough to ask them to give them enough tokens to get by? What powers have they been given? What are their abilities? What level of ownership do they have? Is their responsibility balanced? If it doesn’t have enough upside or power or flexibility, you should not expect them to fix it. How can we see how this data structure is used across different protocols? They can be divided into five categories: Payments and Voting, Stakeholders and Metadata. Claiming is the third. The payment function can also be broken down into three categories. The first is the internal currency of the project or community. Although we haven’t seen many examples of this, there are some. SourceCred is one example. FWB may also be moving in this direction. It is different from traditional payment methods like USD payments because it is within a specific community that controls the currency. They can use monetary policies on the currency. This includes the ability to create monetary policy on the currency. The second type of payment, which is also used for online resources, such as Ethereum and Bitcoin. You can pay for computing power, storage, and other cryptocurrency network resources. EIP1559, staking and liquidity are all available. To determine how tokens can also be used to calculate different resources within a system, particularly computing resources, the third payment token is available as a game currency. Token prices must be set for resources, games, and other protocol resources. This is because the token price must be stable if you use the system. It doesn’t matter whether it’s in stable supply, as you only use it to implement a part of your application. A stable currency can be used in any of the three above ways. But what makes a stablecoin a stablecoin is the mechanism behind it that stabilizes it, so stablecoins generally fall under the ownership category.OwnershipThere are generally two types of ownership, on-chain (deposits) and off-chain (ownership). Deposit tokens are ownership over other tokens. An example of this is the Uniswap LP to token, which is an ERC-20 token in V2 and an NT in V3. DAI, the stablecoin that is derived from the Maker protocol, can also be used by vault holders to claim their underlying collateral. A deposit token can be used to claim tokens in an offline environment. This could be a real-world asset token or real estate token. This is a rare example. Modern examples include the redeemable, which allows tokens to be exchanged for physical items. NFT can be used to exchange artwork for artwork. This NFT represents the yard’s ownership. There are also some fun deals. You can use physical objects to control NFT, and you can also control the ownership of any subsequent NFT through digital functions like chips. VoteVoting can be used for funding projects, allocating resources, making payments or transfers as part of a group, as well as software upgrades. It can also be used to measure social consensuses such as the selection and payment of a leader to determine future plans for a project. Although there is no legal agreement, the mechanism means that tokens will be entitled to some on-chain activity. Maker is an example of this. Maker token holders who do their jobs well and the system works properly will get a return. This is because smart contracts, which are designed to reward good governance, allow tokens to be made. Legal agreements also allow you to receive returns. A token can be used to represent an equity fraction, or share of equity, but there are restrictions and legal requirements. Although it was possible to create security tokens in theory, there was a time when this was not the case. Tokens can also be used to underwrite risk in return for returns. This principle is used by Maker. Maker token holders will lose more Maker tokens if there is a loss in Maker protocol. This can dilute Maker token holders’ value. Maker token holders take some risk by holding Maker tokens. This is why Maker holders are motivated to encourage community building. If they want to see their investment increase in value, they need to support the development of this system.MetadataFirst, tokens represent the membership, determining whether you have access to a particular space, whether you are in a particular community, or whether you are in some groups. This membership attribute can be used in any protocol or tool written by third parties. Some NFT communities may decide that token holders are the only ones who can join. The ones that offer specific functionality. Tokens can also represent reputation. Many people are debating whether reputation should transferable. It may be non-homogeneous or homogeneous in certain cases. It may not be homogeneous if it is about your achievements. However, if it is about information sources, credit or other types of credit scoring systems it may be homogeneous. This is continuous data and is considered a type of metadata. Tokens can also be used to identify or reference individuals. Ens is one example. ENS names can point at addresses and can be updated, unlike DNS. Off-chain data can also be a type of metadata. An example of this would be an offchain KYC, or some type of verifiable certification. A diploma or academic qualification is another good example. This certificate is given to you by someone and it’s publically visible, traceable and authentic. We haven’t seen many cases where permissions or capabilities are expressed on-chain. As if an entity grants you permissions to call a function or modify code, or transfer anything on-chain, You can use tokens to create interfaces. We’ve seen examples where you can not only put SVG data into a token URI but you can also put an entire HTML page in it. And you can even add a little JavaScript. You can embed an interface in the NFT, control it, or embed it in an object that other people own and transfer. These texts are displayed on the small BEEP3R image. These texts are displayed on the small image of BEEP3R. This token is a membership token. You can receive messages with this token. Any wallet interface that correctly displays animated URLs can display any message you get as long as it supports the standard. This token is also an identity token since you can send and receive information as a BP holder. This is only possible in the set. It also serves as an identity token by contacting you with your BP token ID. It also functions as an interface. Information related to NFT can be viewed. Tech Tree TheoryWe can see some fields have made significant progress, such tokens as a way of payment and network resource resources, while others have not yet developed interfaces and metadata. Why is this? Consider the lending protocol as an example. It is difficult to imagine the lending protocols functioning without stablecoins. Because you are able to borrow assets such as stablecoins, and lend debt in a loan agreement, it is important to have AMM. An AMM is required if you want to quickly exchange the stablecoin for the asset and to have greater exposure. The development of lending protocols was possible only after we had AMMs and stablecoins. This is impossible without an interoperable token standard. Stablecoins, AMMs and all systems around them must understand how other projects interact with them. To have ERC-20 tokens you will need fully-programmable smart contracts. Although you don’t really need them, they are necessary because Ethereum was launched before the ERC-20 token standard. To be able leave enough design space, we need complete programmability. This can be discussed further. In conclusion, I believe there are technology trees in which certain technologies are prerequisites for other technologies. The second question is: What technologies are needed to create trustless and decentralized interfaces or reputation systems? The second question is somewhat similar to the first question in reverse: Which applications and protocols will be unlock by the upcoming technology’s? These questions are fascinating because we can see the arrival of technologies that will ease or introduce design constraints. How does that affect our designs? If there are technologies that can ease the constraints, should they be developed? This might help us to think about what’s coming and what we need to do to reach the desired constraints. I believe that new technology can alleviate the limitations we have faced in the past. It is possible to design a general-purpose AMM without using a specific token standard. However, this would be extremely difficult. This seemed like an insurmountable limitation. However, having an interoperability standards means that we can directly support ERC-20 tokens, which limits the design space. How does this impact the constraints on our protocol design. What technology is needed to achieve specific goals and constraints? Technology will be able to alleviate these limitations and make these goals possible again through new mechanisms.DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.Join us to keep track of news: https://linktr.ee/coincuWebsite: coincu.comHaroldCoincu NewsTags: BEEP3REIP1559ENSERC-20EthereumLP tokenMakerDAOSourceCredtokenToken Design