Tokens are a very interesting, useful, and powerful new tool that changes how protocols are designed and what can be achieved, but tokens are not central to the design. Today’s protocol design is more like “alchemy” than a discipline because the understanding of designers is far from comprehensive or scientific, and most projects still require a lot of experimentation.

This session is divided into three parts, starting with common mindsets in token design, followed by a taxonomy of tokens, talking more specifically about what tokens really are and how we can think about developing and enhancing their capabilities. The last is the technology tree theory, how to use technology to make our design easier to succeed.

Thinking mode

First, tokens are for the protocol, they are a tool, part of the design process, and they should not be the goal. If you want to do something decentralized, tokens are probably a part of that because it’s great for people to have ownership of the protocol and also for keeping people in line.

Three Stages of Design

Phase 1: Define your goals

A goal is a concise description of the outcome of a valid protocol, and it should be unambiguous whether it has been achieved by a specific design. So we should have a very clear distinction between success and failure. If it is not clear what our goal is, we need to start over and forget about tokens. Ideally, goals are measurable, even if we’re not sure how to measure success yet.

Phase 2: Introduce restrictions

In general, there are two types of constraints, one is intrinsic, and the other is exogenous: intrinsic constraints are the ones we choose to simplify the design process because there are some trade-offs to be made, or they are trade-offs in themselves.

Intrinsic constraints can come from many sources but are usually determined by the designer himself. Exogenous constraints are imposed on you by nature, the state of technology, regulations and all kinds of things. I will talk about it later.

Phase 3: Design mechanism

Once we have a constraint and a goal, we can explicitly think about the mechanics that will meet that goal. Now whenever we think about a mechanic, it should be really clear if it violates those constraints and gets us closer to that goal. A protocol will be a set of mechanisms, all driven towards a specific goal according to some constraints.

Take MakerDAO as an example. Their goal is to develop a stable Ethereum native asset. Of course, there are many interpretations of stability and nativeness. Their limitations are prices pegged to USD, fully backed by native on-chain assets, etc.

Common pitfalls

Too much emphasis on tokens. Tokens are not protocols, and tokens should not be your goal. It should just be a tool.

How to get out of this trap? Ask yourself: How would this system work without tokens? If the system completely fails when you remove tokens entirely, then you may be overemphasizing the role of tokens. It’s better than if a few key parts of the system fail, your token does matter and is necessary for the overall balance, but the system remains coherent without it. Therefore, you should still think about the goals of the system.

Design space is unlimited. In design, you have so many ideas, and so many possibilities you don’t even know where to start because there are so many things that can be done. This is usually because the goal is not clear, so it is necessary to refine the goal. It may also be due to your lack of understanding of the limitations that the outside world has placed on you or that you have not accepted them.

If you bring these constraints into the mix, you’ll find that the design space shrinks and becomes much clearer. Two questions that help limit the design space are to ask yourself: What is the strong concept you want to build? It may be some in-depth ideas, some advantages, some changes in the trend of the times, etc. Ask yourself what this powerful concept is? How can you get the most out of it and focus on it instead of thinking about the whole system first? Another question is: what is the biggest weakness of this design? What’s keeping you up at night, it’s the points you think might not work, the points you’re worried about, the key weaknesses, and what constraints can you accept to improve it? This can greatly limit the design space.

Always let the community know. There are challenges in designing certain parts of the system, pushing them all to the community to solve, or expecting unseen forces to fill in the gaps; always you expect people to find the problem and solve it, which is very risky. Despite the popularity of permissionless systems and the amazing innovations that have occurred, you can’t predict the actions of the community, nor should you expect them to solve the most obvious problems in your system.

There are a few key questions you should ask yourself, what do we really expect from our community and what are we giving them? Isn’t it enough to ask us to give them enough tokens? Rather, what powers have we given them? What abilities are given to them? What ownership do they have? Are they empowered enough to balance this responsibility?

If you really expect them to fix a thing, if you expect other ambitious people to add some interesting extensions, or fix some components of the system, then you have to ask yourself first, would you build here? If you won’t because it doesn’t have enough upside, enough power, or enough flexibility, then look no further.

Token taxonomy

Tokens are a tool in a protocol, they are a tool and a protocol, and more abstractly, they are a data structure. So how do we see this data structure is used in different protocols? They can be grouped into five very general categories: Payments, Voting, Stakeholders, Metadata, and Claiming.

To pay

The payment function is further divided into three categories, the first is as the internal currency of the community or project. We haven’t seen much like this, but there are a few examples. For example, SourceCred is an interesting example, and FWB may be moving in this direction.

It differs from traditional payment methods such as USD payments because it exists within a specific community that has control over the currency, and they can use monetary policy and other means on this internal currency, such as this currency should be stable, Should be pegged to the value of some other specific asset, maybe they mint or burn it based on specific, community-wide goals.

The second, and probably the most commonly used and most well-understood form of payment for using cryptocurrencies, is as an online resource, and Ethereum and Bitcoin also fall into this category. You pay for computing power, storage, or some other cryptocurrency network resource. We have EIP1559, staking, liquidity, etc. to determine how tokens can be used to calculate different resources within the system, especially computing resources.

The third payment token exists as a similar game currency. For example, games, resources or some protocol resources need to be stable and need to be priced, because if you use the system and these resources are stable, the token price also needs to be relatively stable. It doesn’t matter if it’s in stable supply or not, because you’re only using it to implement a specific part of your application.

So where should stablecoins be placed? Of course, a stable currency can be used as payment in the above three ways. But what makes a stablecoin a stablecoin is the mechanism behind it that stabilizes it, so stablecoins generally fall under the ownership category.

Ownership

There are generally two types of ownership, on-chain (deposits) and off-chain (ownership). Deposit tokens represent ownership over other tokens, an example is the Uniswap LP token, which is an ERC-20 in V2 and an NFT in V3. DAI, the stablecoin that comes out of the Maker protocol, is also an on-chain deposit because you or vault holders use it to claim their underlying collateral. So a deposit token means that it can be used to claim other tokens in an off-chain environment.

The second token represents ownership of some off-chain asset, so this could be something like a real-world asset token, a real estate token, or something like that. We haven’t seen a lot of examples of this. A more modern example is what is now called a redeemable, where tokens can be exchanged for physical objects. For example, NFT is used to exchange artwork with artwork, and this NFT represents the ownership of the yard. There are even some fun deals if you want. You can use physical objects to control NFT and control the ownership of subsequent NFT through some digital functions such as chips.

Vote

Voting can be used to fund projects, allocate resources, i.e., make payments or transfers as a group, and make software upgrades. It can also be used as a measure of social consensuses, such as the selection of a leader to determine the future plans of a project.

Pledge

Tokens can be designed to be entitled to rewards through smart contracts, there is no legal agreement here, but the mechanism works to mean that the token will benefit from some kind of on-chain activity. One example is Maker; if the Maker token holders are doing their job well, and the system is functioning properly, then they will benefit from some return; this is the way of smart contracts, the way the protocol is designed, reward good governance of the community.

You can also make tokens as a result of legal agreements that entitle you to returns. You can create a token that represents an equity fraction or share of equity in a company, of course, with various legal requirements and restrictions. There was a time when there were people who could theoretically create security tokens, although we haven’t seen much of that.

Tokens are also used to underwrite risk in exchange for returns. Maker uses this principle. If there is a loss in the Maker protocol, more Maker tokens will be generated, which dilutes the value held by Maker holders. By holding Maker tokens, holders own some risk, which is part of what drives Maker holders to promote community building. If they want to see their investment increase in value, they need to support the development of this system.

Metadata

First, 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. Protocols or tools written by some third parties can use this membership attribute in any way which is permissionless. For example, some NFT communities can decide that only those who hold tokens can join, such as holding this token. The ones that provide specific functionality and so on. Membership is an interesting metadata type provided by tokens.

Tokens also represent reputation. Some people are debating whether reputation should be transferable. But it may be homogeneous in some cases and non-homogeneous in others. If it refers to your achievements, it may be non-homogeneous; if it refers to information sources, credit, or different types of credit scoring systems, it may be homogeneous. This is continuous data, so it is a kind of metadata.

Tokens also represent identities or references. Ens is an example of this, ENS names can point to addresses and can be updated, unlike the DNS system.

Off-chain data can be a kind of metadata. An example would be an off-chain KYC or some kind of verifiable certificate. Another good example is a diploma or academic qualification. Someone hands you this certificate, and it’s publicly visible, traceable, and authentic. We haven’t seen many cases of expressing permissions and capabilities on-chain.

Like some entity explicitly grants you permissions, like the ability to call a function, change a piece of code, or transfer something on-chain. It’s even possible to use tokens as interfaces, we’ve seen examples of this, where not only can you put SVG data in a token URI, you can put an entire HTML web page in it, and you can even put a little JavaScript. You can put an interface in the nft, control the interface, or embed the interface in an object that people own and transfer.

An interesting example is BEEP3R, where you mint a text into an NFT first, and then you can broadcast the text to other BEEP3R holders by owning it. These texts are displayed on the small image of BEEP3R. When you have a BEEP3R machine, you can also send messages directly to other BEEP3R machine holders, just like using XMTB alone.

So what is the function of this token? This is a membership token, and with this token, you can receive messages. Any wallet interface that correctly represents animated URLs can display any message you receive as long as it supports this standard.

This is also an identity token because as a BP holder, you can receive and send information. So this thing only happens in that set. It’s also an identity token, because they message you with your BP’s token ID. At the same time, it also exists as an interface, and information related to the NFT can be viewed.

Tech Tree Theory

We can see that some fields have made great progress, such as tokens as a means of payment and network resources, while some fields have not yet developed, such as interfaces and metadata. So why is this the case?

Why do some products appear at certain times, and why do some products take longer to appear than others? Take the lending protocol as an example, and it is hard to imagine the lending protocol working without a stablecoin. This is because when you lend debt in a lending agreement, you want to represent it with a stable asset because you can predict the price of this asset, so we need stablecoins before we can actually have a lending agreement.

Similarly, we also have a lending agreement that requires AMM because if you want to use the lending agreement for leverage, especially the early simple lending agreement, you need to be able to borrow assets, such as stablecoins. If you want to exchange that stablecoin for that asset very quickly and you want to have more exposure, then you need an AMM. It wasn’t until we had functioning AMMs and stablecoins that lending protocols evolved.

But how to get a working AMM and stablecoin? This is difficult to do without an interoperable token standard because stablecoins, AMMs, and all the systems around them need to understand how other projects interface with them. And to have ERC-20 tokens, you need fully programmable smart contracts. You probably don’t actually need them, but that’s how they first appeared on Ethereum, since Ethereum was launched without the ERC-20 token standard. We need full programmability to be able to leave enough open design space; of course, this can be discussed further. But in conclusion, I think there are technology trees where certain technologies are prerequisites for others.

There are two questions here: what are the key technologies that will unlock future applications and protocols? That is, what technologies do we need to develop useful reputation systems or decentralized and trustless interfaces? And the second question is a bit like the first question in reverse, which applications and protocols will be unlocked by the upcoming technology?

For example, account abstraction, EIP4844, vertical tree, zero-knowledge machine learning, etc. These questions are interesting because if we can foresee the arrival of certain technologies that alleviate or introduce design constraints, how does that change our designs? If there are specific technologies that can alleviate the constraints, should we spend energy developing them?

If you think of things as a tech tree, it might help us reason about what’s coming or what you need to get to the set of constraints you want. So, linking it back to my original point of limitation, I think new technology alleviates the limitations we faced before. For example, if there is no ERC-20 standard, then the constraints on any AMM or stablecoin design will be that it either needs to introduce a standard or be able to cope with a variety of different designs.

Imagine designing a general-purpose AMM but not using a specific token standard, it would be very, very difficult. I thought this would be an almost insurmountable limitation, but having an interoperability standard means we can support ERC-20 tokens directly, which limits the design space and makes it possible.

If we can predict which technologies will emerge in the future, how does this affect the constraints on our protocol design? If we have specific goals or specific constraints, what technology do we need? 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/coincu

Website: coincu.com

Harold

Coincu News

BEEP3R

EIP1559

ENS

ERC-20

LP token

MakerDAO

SourceCred

token

Token Design

Author

Harold

With a passion for untangling the complexities of the financial world, I've spent over four years in financial journalism, covering everything from traditional equities to the cutting edge of venture capital. "The financial markets are a fascinating puzzle," I often say, "and I love helping people make sense of them." That's what drives me to bring clear and insightful financial journalism to the readers of Coincu.

Knowledge

Token Design: Great Potential, Pitfalls, Solutions And Future Prospects

Tokens are a very interesting, useful, and powerful new tool that changes how protocols are designed and what can be achieved, but tokens are not central to the design. Today’s protocol design is more like “alchemy” than a discipline because the understanding of designers is far from comprehensive or scientific, and most projects still require a lot of experimentation.

This session is divided into three parts, starting with common mindsets in token design, followed by a taxonomy of tokens, talking more specifically about what tokens really are and how we can think about developing and enhancing their capabilities. The last is the technology tree theory, how to use technology to make our design easier to succeed.

Thinking mode

First, tokens are for the protocol, they are a tool, part of the design process, and they should not be the goal. If you want to do something decentralized, tokens are probably a part of that because it’s great for people to have ownership of the protocol and also for keeping people in line.

Three Stages of Design

Phase 1: Define your goals

A goal is a concise description of the outcome of a valid protocol, and it should be unambiguous whether it has been achieved by a specific design. So we should have a very clear distinction between success and failure. If it is not clear what our goal is, we need to start over and forget about tokens. Ideally, goals are measurable, even if we’re not sure how to measure success yet.

Phase 2: Introduce restrictions

In general, there are two types of constraints, one is intrinsic, and the other is exogenous: intrinsic constraints are the ones we choose to simplify the design process because there are some trade-offs to be made, or they are trade-offs in themselves.

Intrinsic constraints can come from many sources but are usually determined by the designer himself. Exogenous constraints are imposed on you by nature, the state of technology, regulations and all kinds of things. I will talk about it later.

Phase 3: Design mechanism

Once we have a constraint and a goal, we can explicitly think about the mechanics that will meet that goal. Now whenever we think about a mechanic, it should be really clear if it violates those constraints and gets us closer to that goal. A protocol will be a set of mechanisms, all driven towards a specific goal according to some constraints.

Take MakerDAO as an example. Their goal is to develop a stable Ethereum native asset. Of course, there are many interpretations of stability and nativeness. Their limitations are prices pegged to USD, fully backed by native on-chain assets, etc.

Common pitfalls

Too much emphasis on tokens. Tokens are not protocols, and tokens should not be your goal. It should just be a tool.

How to get out of this trap? Ask yourself: How would this system work without tokens? If the system completely fails when you remove tokens entirely, then you may be overemphasizing the role of tokens. It’s better than if a few key parts of the system fail, your token does matter and is necessary for the overall balance, but the system remains coherent without it. Therefore, you should still think about the goals of the system.

Design space is unlimited. In design, you have so many ideas, and so many possibilities you don’t even know where to start because there are so many things that can be done. This is usually because the goal is not clear, so it is necessary to refine the goal. It may also be due to your lack of understanding of the limitations that the outside world has placed on you or that you have not accepted them.

If you bring these constraints into the mix, you’ll find that the design space shrinks and becomes much clearer. Two questions that help limit the design space are to ask yourself: What is the strong concept you want to build? It may be some in-depth ideas, some advantages, some changes in the trend of the times, etc. Ask yourself what this powerful concept is? How can you get the most out of it and focus on it instead of thinking about the whole system first? Another question is: what is the biggest weakness of this design? What’s keeping you up at night, it’s the points you think might not work, the points you’re worried about, the key weaknesses, and what constraints can you accept to improve it? This can greatly limit the design space.

Always let the community know. There are challenges in designing certain parts of the system, pushing them all to the community to solve, or expecting unseen forces to fill in the gaps; always you expect people to find the problem and solve it, which is very risky. Despite the popularity of permissionless systems and the amazing innovations that have occurred, you can’t predict the actions of the community, nor should you expect them to solve the most obvious problems in your system.

There are a few key questions you should ask yourself, what do we really expect from our community and what are we giving them? Isn’t it enough to ask us to give them enough tokens? Rather, what powers have we given them? What abilities are given to them? What ownership do they have? Are they empowered enough to balance this responsibility?

If you really expect them to fix a thing, if you expect other ambitious people to add some interesting extensions, or fix some components of the system, then you have to ask yourself first, would you build here? If you won’t because it doesn’t have enough upside, enough power, or enough flexibility, then look no further.

Token taxonomy

Tokens are a tool in a protocol, they are a tool and a protocol, and more abstractly, they are a data structure. So how do we see this data structure is used in different protocols? They can be grouped into five very general categories: Payments, Voting, Stakeholders, Metadata, and Claiming.

To pay

The payment function is further divided into three categories, the first is as the internal currency of the community or project. We haven’t seen much like this, but there are a few examples. For example, SourceCred is an interesting example, and FWB may be moving in this direction.

It differs from traditional payment methods such as USD payments because it exists within a specific community that has control over the currency, and they can use monetary policy and other means on this internal currency, such as this currency should be stable, Should be pegged to the value of some other specific asset, maybe they mint or burn it based on specific, community-wide goals.

The second, and probably the most commonly used and most well-understood form of payment for using cryptocurrencies, is as an online resource, and Ethereum and Bitcoin also fall into this category. You pay for computing power, storage, or some other cryptocurrency network resource. We have EIP1559, staking, liquidity, etc. to determine how tokens can be used to calculate different resources within the system, especially computing resources.

The third payment token exists as a similar game currency. For example, games, resources or some protocol resources need to be stable and need to be priced, because if you use the system and these resources are stable, the token price also needs to be relatively stable. It doesn’t matter if it’s in stable supply or not, because you’re only using it to implement a specific part of your application.

So where should stablecoins be placed? Of course, a stable currency can be used as payment in the above three ways. But what makes a stablecoin a stablecoin is the mechanism behind it that stabilizes it, so stablecoins generally fall under the ownership category.

Ownership

There are generally two types of ownership, on-chain (deposits) and off-chain (ownership). Deposit tokens represent ownership over other tokens, an example is the Uniswap LP token, which is an ERC-20 in V2 and an NFT in V3. DAI, the stablecoin that comes out of the Maker protocol, is also an on-chain deposit because you or vault holders use it to claim their underlying collateral. So a deposit token means that it can be used to claim other tokens in an off-chain environment.

The second token represents ownership of some off-chain asset, so this could be something like a real-world asset token, a real estate token, or something like that. We haven’t seen a lot of examples of this. A more modern example is what is now called a redeemable, where tokens can be exchanged for physical objects. For example, NFT is used to exchange artwork with artwork, and this NFT represents the ownership of the yard. There are even some fun deals if you want. You can use physical objects to control NFT and control the ownership of subsequent NFT through some digital functions such as chips.

Vote

Voting can be used to fund projects, allocate resources, i.e., make payments or transfers as a group, and make software upgrades. It can also be used as a measure of social consensuses, such as the selection of a leader to determine the future plans of a project.

Pledge

Tokens can be designed to be entitled to rewards through smart contracts, there is no legal agreement here, but the mechanism works to mean that the token will benefit from some kind of on-chain activity. One example is Maker; if the Maker token holders are doing their job well, and the system is functioning properly, then they will benefit from some return; this is the way of smart contracts, the way the protocol is designed, reward good governance of the community.

You can also make tokens as a result of legal agreements that entitle you to returns. You can create a token that represents an equity fraction or share of equity in a company, of course, with various legal requirements and restrictions. There was a time when there were people who could theoretically create security tokens, although we haven’t seen much of that.

Tokens are also used to underwrite risk in exchange for returns. Maker uses this principle. If there is a loss in the Maker protocol, more Maker tokens will be generated, which dilutes the value held by Maker holders. By holding Maker tokens, holders own some risk, which is part of what drives Maker holders to promote community building. If they want to see their investment increase in value, they need to support the development of this system.

Metadata

First, 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. Protocols or tools written by some third parties can use this membership attribute in any way which is permissionless. For example, some NFT communities can decide that only those who hold tokens can join, such as holding this token. The ones that provide specific functionality and so on. Membership is an interesting metadata type provided by tokens.

Tokens also represent reputation. Some people are debating whether reputation should be transferable. But it may be homogeneous in some cases and non-homogeneous in others. If it refers to your achievements, it may be non-homogeneous; if it refers to information sources, credit, or different types of credit scoring systems, it may be homogeneous. This is continuous data, so it is a kind of metadata.

Tokens also represent identities or references. Ens is an example of this, ENS names can point to addresses and can be updated, unlike the DNS system.

Off-chain data can be a kind of metadata. An example would be an off-chain KYC or some kind of verifiable certificate. Another good example is a diploma or academic qualification. Someone hands you this certificate, and it’s publicly visible, traceable, and authentic. We haven’t seen many cases of expressing permissions and capabilities on-chain.

Like some entity explicitly grants you permissions, like the ability to call a function, change a piece of code, or transfer something on-chain. It’s even possible to use tokens as interfaces, we’ve seen examples of this, where not only can you put SVG data in a token URI, you can put an entire HTML web page in it, and you can even put a little JavaScript. You can put an interface in the nft, control the interface, or embed the interface in an object that people own and transfer.

An interesting example is BEEP3R, where you mint a text into an NFT first, and then you can broadcast the text to other BEEP3R holders by owning it. These texts are displayed on the small image of BEEP3R. When you have a BEEP3R machine, you can also send messages directly to other BEEP3R machine holders, just like using XMTB alone.

So what is the function of this token? This is a membership token, and with this token, you can receive messages. Any wallet interface that correctly represents animated URLs can display any message you receive as long as it supports this standard.

This is also an identity token because as a BP holder, you can receive and send information. So this thing only happens in that set. It’s also an identity token, because they message you with your BP’s token ID. At the same time, it also exists as an interface, and information related to the NFT can be viewed.

Tech Tree Theory

We can see that some fields have made great progress, such as tokens as a means of payment and network resources, while some fields have not yet developed, such as interfaces and metadata. So why is this the case?

Why do some products appear at certain times, and why do some products take longer to appear than others? Take the lending protocol as an example, and it is hard to imagine the lending protocol working without a stablecoin. This is because when you lend debt in a lending agreement, you want to represent it with a stable asset because you can predict the price of this asset, so we need stablecoins before we can actually have a lending agreement.

Similarly, we also have a lending agreement that requires AMM because if you want to use the lending agreement for leverage, especially the early simple lending agreement, you need to be able to borrow assets, such as stablecoins. If you want to exchange that stablecoin for that asset very quickly and you want to have more exposure, then you need an AMM. It wasn’t until we had functioning AMMs and stablecoins that lending protocols evolved.

But how to get a working AMM and stablecoin? This is difficult to do without an interoperable token standard because stablecoins, AMMs, and all the systems around them need to understand how other projects interface with them. And to have ERC-20 tokens, you need fully programmable smart contracts. You probably don’t actually need them, but that’s how they first appeared on Ethereum, since Ethereum was launched without the ERC-20 token standard. We need full programmability to be able to leave enough open design space; of course, this can be discussed further. But in conclusion, I think there are technology trees where certain technologies are prerequisites for others.

There are two questions here: what are the key technologies that will unlock future applications and protocols? That is, what technologies do we need to develop useful reputation systems or decentralized and trustless interfaces? And the second question is a bit like the first question in reverse, which applications and protocols will be unlocked by the upcoming technology?

For example, account abstraction, EIP4844, vertical tree, zero-knowledge machine learning, etc. These questions are interesting because if we can foresee the arrival of certain technologies that alleviate or introduce design constraints, how does that change our designs? If there are specific technologies that can alleviate the constraints, should we spend energy developing them?

If you think of things as a tech tree, it might help us reason about what’s coming or what you need to get to the set of constraints you want. So, linking it back to my original point of limitation, I think new technology alleviates the limitations we faced before. For example, if there is no ERC-20 standard, then the constraints on any AMM or stablecoin design will be that it either needs to introduce a standard or be able to cope with a variety of different designs.

Imagine designing a general-purpose AMM but not using a specific token standard, it would be very, very difficult. I thought this would be an almost insurmountable limitation, but having an interoperability standard means we can support ERC-20 tokens directly, which limits the design space and makes it possible.

If we can predict which technologies will emerge in the future, how does this affect the constraints on our protocol design? If we have specific goals or specific constraints, what technology do we need? 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/coincu

Website: coincu.com

Harold

Coincu News

Other Posts

Related Posts

[tptn_list limit="8" title_length="0" heading="0" show_date="0" daily="1"]