Making Bitcoin Great Again RGB Initiates a New Journey of Web3 from Payments to Smart Contracts

Co-creation: Infinitas; Waterdrip Capital; viaBTC Capital

Technical Support: Li Ning; Hong Shuning

After more than a decade of vigorous development, Web3 technology has brought about various levels of innovation. Bitcoin, without compromising its decentralization and security, has continuously improved its privacy protection capabilities and achieved a series of advanced features such as Schnorr signatures and Taproot, laying the foundation for subsequent technological innovations. At the same time, the evolution of on-chain smart contracts represented by Ethereum has given birth to the golden age of blockchain applications (such as DeFi) and brought about two bull markets. However, since 2022, the innovation in the Web3 industry has suddenly lost its direction, and blockchain technology has always been unable to break free from the “impossible triangle,” resulting in the failure of large-scale applications of blockchain. So, have we reached the limits of technology? Are there deeper unknown territories waiting for us to explore? Perhaps, it is in the process of these explorations that the Bitcoin Layer 2 protocol, RGB, is quietly waiting for the opportunity, gradually maturing, to challenge the existing technological limitations and show its dazzling brilliance.

Bitcoin: Establishing its position as the currency layer

The biggest difference between Web3 and Web2 lies in its built-in economic system, and any economic system is based on currency as its foundational layer, with protocol layers and application layers above the currency layer. The currency of Web3 is called cryptocurrency, which is issued through blockchain.

Due to several key factors, Bitcoin is recognized as the most secure and stable cryptocurrency, and its value has gained global consensus:

Firstly, the Bitcoin network covers the whole world and has more than 10,000 full nodes. These nodes work together to verify and record transactions. This decentralization makes it difficult for attackers to tamper with transaction history. Secondly, Bitcoin uses powerful hash computing power as its proof-of-work mechanism, which is the cornerstone of network security. In block validation and mining, the consumption of a large amount of computing power makes it difficult for attackers to control the network. In addition, the consensus rules of Bitcoin have not undergone significant changes in history. This stability helps maintain the consistency and security of the network. Compared to other blockchain projects, the consensus rules of Bitcoin are less susceptible to radical changes. The Bitcoin community is highly concerned about the security and stability of the network, focusing on the security of the core protocol. Modifications to the core protocol are carefully discussed and tested to ensure network stability. In summary, Bitcoin is recognized as the safest and most stable among many blockchains, and with its outstanding decentralization, consensus mechanism, stability, and community attention, it has become the preferred currency layer of Web3.

Bitcoin Script: Ensuring security and simplicity in parallel

As an important role in the foundational currency layer of the Web3 world, Bitcoin, in its gradual evolution through careful discussion and testing of the core protocol, particularly worth mentioning is the development of its script system. The original intention of the Bitcoin script language is to ensure security and mitigate potential risks, so it deliberately limits functionality in its design while maintaining simplicity and security similar to chip instruction sets. The Bitcoin script is an execution language based on the Reverse Polish Notation (RPN) and stack-based. This script is designed to be executed on limited hardware.

In the mainstream Bitcoin node code, developers have imposed some restrictions on executable script types, only allowing the execution of several types of transactions known as “standard scripts”. Among them, the most important is the P2SH (Pay to Script Hash) transaction, which actually allows any Bitcoin script to be executed, making it possible to execute scripts with certain complex functionalities on Bitcoin. For example, the Lightning Network has become the de facto standard for small, high-frequency Bitcoin payments.

With the introduction of the Schnorr signature proposal and the Taproot soft fork upgrade, Bitcoin has taken an important step, marking a significant milestone. This allows Bitcoin to better support the development of layer 2 protocols, further enhancing its role in the future Web3 world.

Focusing on Schnorr Signature and Taproot

Behind Schnorr Signature and Taproot, there are a series of technological innovations that have created new opportunities for Bitcoin. Firstly, Taproot introduces more flexible payment channels, allowing multiple types of transactions to be executed on-chain in a more privacy-preserving manner. By hiding complex multi-signature scripts within a single script, Taproot makes various complex transactions look like regular single-party payments, thereby enhancing privacy and security. The introduction of Schnorr signatures makes transactions on the Bitcoin network more compact, reducing transaction fees and improving scalability, aligning closely with the efficient transaction needs of the Web3 world.

These two innovations not only improve the performance and privacy of Bitcoin, but also bring more possibilities for innovation to the ecosystem. More efficient script and signature technologies support cross-chain operations, Lightning Network scaling, and complex smart contracts. This will refocus Bitcoin on the core of Web3, paving the way for the construction of a more secure and efficient decentralized financial and application ecosystem.

The Impact of Schnorr Signatures

In the early design stage of the Bitcoin protocol, Satoshi Nakamoto needed to consider various factors of the signature algorithm, including signature length, openness, patent issues, security verification time, and performance, among others. In the end, he chose the Elliptic Curve Digital Signature Algorithm (ECDSA) and selected the specific elliptic curve secp256k1 based on the performance and security of this algorithm. However, besides ECDSA, there are other digital signature algorithms that meet the requirements, especially Schnorr Signature. The reason why Satoshi did not adopt this algorithm may be that the patent for Schnorr Signature had not expired in the year Bitcoin was created. German mathematician and cryptographer Claus-Peter Schnorr applied for and obtained the related patent in 1990, so the open-source community could not adopt this technology during the patent’s valid period. Otherwise, Satoshi might have been able to use this signature mechanism in the initial version of the Bitcoin protocol.

Compared to ECDSA, Schnorr Signature is more aligned with the essence of Bitcoin signatures. It not only performs better and has shorter signature length, but also has linear properties, making key aggregation simple without the need for special techniques required for multi-signatures. This linear property is easy to understand, and the keys of each participant are aggregated to form a new key through a simple mechanism. There are multiple ways to achieve aggregation, such as Blockstream’s proposed MuSig and the updated version, MuSig2. In the MuSig2 scheme, multiple signatures can generate an aggregated public key from their respective private keys, and then jointly generate a valid signature for that public key, reducing the number of rounds of interaction from the original three rounds (MuSig) to just two rounds.

So, looking at a 2-3 multisig transaction, the traditional way requires three public keys and two signatures to initiate a transaction.

However, in the Schnorr Signature scenario, on-chain transactions only require an aggregated public key and a signature, reducing a lot of transaction bytes and therefore reducing transfer costs.

Innovation of Taproot Script

Taproot is an innovative Bitcoin script structure that specifies how to use and parse transaction addresses of the Taproot type. Taproot was originally inspired by Bitcoin developers’ research on Merkle Abstract Syntax Trees (MAST), so Taproot can be seen as a special implementation of MAST. With Taproot, Bitcoin UTXOs with multiple different branch scripts can spend by only revealing one branch, while the remaining branches will never appear on the blockchain, greatly improving transaction privacy and efficiency. This technology makes the use of complex scripts more convenient and efficient under the premise of greater security.

In the Bitcoin protocol, the “locking script” (output script) specifies the conditions for receiving Bitcoin (UTXO), while the “unlocking script” (input script) specifies how to use Bitcoin (UTXO), the former can be seen as a lock, and the latter is the corresponding key. In the Segregated Witness (SegWit) upgrade, Bitcoin’s script rules were comprehensively upgraded. Two new script rules were introduced, namely P2WPKH (Pay-to-Witness-Public-Key-Hash) and P2WSH (Pay-to-Witness-Script-Hash), which allowed addresses starting with bc1 to be used. P2WPKH is mainly used for regular addresses, while P2WSH is commonly used for multi-signature addresses.

In the Segregated Witness upgrade, the scripts also introduced the concept of version numbers. The previous Segregated Witness rules were marked as version V0. Taproot further upgraded the version number on the Segregated Witness framework to V1, which is also the origin of the “SegWit V1” title in BIP 341. Therefore, this new set of script rules is called P2TR (Pay-to-Taproot) to correspond with P2WPKH and P2WSH.

In addition, combining Schnorr Signature and Taproot allows for a wide variety of ways to construct multisig. Pioneers in the Bitcoin community, such as Steve Lee, have introduced various methods in their presentations, such as threshold signatures and Musig trees (Musig Keytree), etc.

Original speech video: https://www.youtube.com/watch?v=fDJRy6K_3yo

For example, for a hot wallet of an exchange, a 2-3 multi-signature scheme can be used, involving three private keys: exchange private key, trusted third party private key, and cold wallet backup private key. In threshold signatures, multiple signers pre-construct the receiving address through the MuSig mechanism. During actual transactions, only two signatures need to be aggregated to complete the transaction.

LNP/BP: Maturity of “Bitcoin Protocol/Lightning Network Protocol”

In the previous article, we delved into the foresight demonstrated by the Bitcoin network through the introduction of Schnorr signatures and Taproot soft fork upgrades. At the same time, as the wonders of technology never cease, the LNP/BP Standards Association has been quietly working behind the scenes, bringing more innovative possibilities to the Bitcoin ecosystem like a finely crafted work of art. The LNP/BP codebase covers standards and best practices for Bitcoin’s second layer and above, which do not require Bitcoin blockchain-level soft or hard forks, and are not directly related to the content covered by the Lightning Network RFC (BOLTs). In short, the LNP/BP standards cover all aspects related to Bitcoin transactions, define the basic building blocks of second layer and above solutions, and describe complex use cases built on these blocks. This provides possibilities for financial assets, storage, message transmission, computation, and secondary markets that utilize the Bitcoin security model and Bitcoin as a means of payment/exchange.

This article will not go into detail on each protocol within LNP/BP, and those who wish to have a comprehensive understanding of LNP/BP can visit https://github.com/LNP-BP/LNPBPs .

Here, only a few key points that will have important implications for the future of Web3 will be introduced, such as key phase transactions in state channels, as well as key protocols and technologies: bi-directional channels, PTLCs, eltoo, channel factories, discreet log contracts, high-frequency microLianGuaiyments, and Sphinx, among others.

Overview of Key Phase Transactions in State Channels

Funding Transactions: Funding transactions are the initial transactions used to create payment channels in the Lightning Network. They pool the funds of all parties into a multi-signature address, serving as collateral for the payment channel. Funding transactions ensure that participants have committed a certain amount of funds before they start conducting off-chain transactions on the payment channel. Funding transactions are the first step in creating payment channels, ensuring channel security and availability.

Partially Signed Bitcoin Transactions (PSBT): Partially signed Bitcoin transactions are a special format of Bitcoin transactions that allow multiple participants to collaboratively construct and sign transactions. In the Lightning Network, PSBT can be used to create, update, and close payment channel transactions. When both parties of a payment channel want to conduct a transaction, they can collaboratively construct a PSBT, each perform partial signatures, then merge the partially signed transactions, and finally complete the transaction and submit it to the Bitcoin network. PSBT makes the process of multi-party collaboration in transactions more flexible and efficient.

Base-Signed Bitcoin Transactions (BSBT): BSBT is a type of transaction used in the Lightning Network to construct and update channel states. It contains the current state information of the channel and is signed by the channel’s owner. BSBT is used to record the latest state of the channel to ensure the correctness and security of transactions. When the channel state changes, BSBT is created and updated to reflect the new channel state.

Key Technology Supporting RGB Smart Contracts in the Lightning Network

The Lightning Network is a second-layer solution built on top of Bitcoin, which allows users to conduct fast and low-cost transactions through one or more bi-directional channels while maintaining the decentralization and security features of the blockchain. In the following content, we will delve into the strategies adopted by the Lightning Network when facing complex RGB smart contract requirements. From efficiency to scalability, we will analyze the inherent key technologies one by one, and reveal whether the Lightning Network has the potential to support large-scale RGB smart contracts in its continuous evolution.

Bi-directional Channels: As a special type of payment channel, bi-directional channels enable two participants to engage in bi-directional real-time interactions without executing transactions on the blockchain for each interaction. This channel can be likened to a private ledger between two people, allowing them to freely transfer and trade assets within the channel. The final state of the channel is only submitted to the blockchain when the channel is closed. In the Bitcoin network, the implementation of bi-directional channels mainly relies on Bitcoin scripts. For example, in the Lightning Network, users can make payments and asset transfers within the channel, and the final state of the channel will only be submitted to the Bitcoin blockchain when the channel needs to be closed. It should be noted that the core technologies of bi-directional payment channels in the Lightning Network include RSMC and HTLCs, which will not be elaborated on here.

Point Time Lock Contract (PTLC): When discussing the privacy issues of HTLC (Hash Time Locked Contract), we encounter a key challenge: every hop along the path uses the same pre-image, which means that each HTLC in the entire path can only be unlocked by the same pre-image. Does this mean that we have no other solution? In fact, we need to solve the following problems:

Once the payment is completed, the payer (Alice) must be able to provide valid payment proof to the payee (Bob).

Each hop in the path must be able to provide a secret value s to unlock the conditional payment sent by the previous node.

In order to obtain the secret value s, each hop needs to send the conditional payment that needs to be unlocked using the secret value s’ to the next node in the path. This secret value s’ can be used to find the secret value s.

Although we can adopt a “simple” method, which is to use the same secret value s throughout the entire path, just like what we do with HTLC, this is not the only solution. In fact, the secret values s and s’ do not have to be the same. The key is that as long as a node knows s’, it can know s, so we can construct the secret value to satisfy this condition. This is the core concept of PTLC (Pointlocked Timelocked Contract).

The following is an illustrative example:

Eltoo: Bitcoin and other blockchain-based systems have limitations in scalability. On-chain payments require all network nodes to validate and store, limiting overall throughput. To address this issue, second-layer protocols (off-chain protocols) are considered as feasible solutions. They renegotiate and share states among a small number of participants, avoiding frequent broadcasting of state updates to the blockchain and reducing network burden. However, all second-layer protocols face a core problem of how to ensure that only the latest state is submitted to the blockchain.

In this context, Eltoo has become a prominent alternative protocol. It introduces state numbering, a variant of enforceable on-chain sequence numbers. This solves the problem of old state submission, ensuring that only the latest state is recognized and recorded on the blockchain, improving system efficiency and security. This simple and powerful mechanism enhances the feasibility of second-layer protocols and provides a powerful solution for the scalability of Bitcoin and other blockchains.

Discreet Log Contracts (DLC): While smart contracts are highly regarded in cryptocurrency systems such as Bitcoin, they have not yet been widely used in the financial industry. Scalability and the challenge of incorporating external data into smart contracts are two major obstacles to implementation and application. At the same time, the privacy of contracts has always been a concern. Discreet Log Contracts (DLC) is a system that addresses scalability and privacy issues while attempting to minimize the trust required for external data-providing oracles. These contracts maintain secrecy on a discrete level, making it difficult for external observers to detect the presence of contracts in transaction records. Additionally, these contracts rely on discrete logarithmic knowledge, which is an advantage.

SPHINX: In the Lightning Network, “routes” refer to the paths used by the payer to send payments to the payee through a series of payment channels. To enable users to relay payments through routes, the Lightning Network employs a mechanism called “Source-based Onion Routing,” commonly known as “SPHINX.” SPHINX is a tool for ensuring secure communication, requiring the payer to create multiple layers of encryption. During the message delivery process, these layers of encryption are gradually peeled off by intermediate nodes until the intended payee receives the innermost message. During transmission, each intermediate node only knows its preceding and succeeding nodes. Through source routing, the payer is responsible for creating the payment path from their node to the payee’s node.

In summary, the Lightning Network can facilitate payments and asset transfers for complex RGB smart contract requirements through bi-directional channels without the need for frequent broadcasting to the blockchain. Point Time Lock Contracts (PTLC) address the issue of using the same secret value in payment paths, improving privacy. Eltoo, as a new choice for second-layer protocols, solves the problem of old state submission by introducing state numbering. Additionally, Discreet Log Contracts (DLC) address the scalability and privacy issues of smart contracts while reducing the trust required for oracles. Finally, SPHINX, as a source-based onion routing mechanism, ensures secure communication for large-scale applications. These innovative technologies and strategies not only enhance the performance and functionality of the Bitcoin network but also lay the foundation for its important role in the future digital financial world.

Leading the Change: Exploring the Mission of the RGB Protocol

RGB, as a powerful protocol, aims to combine the characteristics of Bitcoin as the underlying currency layer with the flexibility of smart contracts. Through RGB, we can create and manage various assets on the Bitcoin network, enabling broader financial and application innovation. From efficient and secure asset issuance to more complex contract logic, RGB injects new vitality into the Bitcoin network, making it play a more important role in the future digital ecosystem. Let’s explore the attractiveness of RGB and its role in driving the Bitcoin network forward.

Brief Overview

A detailed introduction to the history of RGB has been given in several recent articles, so here we will only provide a basic review.

In 2016, Peter Todd proposed the concepts of Single-use seal and Client-Side Validation. Inspired by these important ideas, RGB was proposed in 2018. In 2019, core developer Orlovsky started promoting RGB and dedicated himself to developing many parts that ultimately constitute the RGB protocol. Subsequently, the LNP/BP Association was established in Switzerland to develop guidelines related to these standards. After a lot of development work, in April 2023, RGB released version v0.10, which is the first preliminary usable version and promises to maintain backward compatibility.

Decoding RGB Smart Contracts

RGB smart contracts can be briefly summarized as two core elements: ownership and state validation. Therefore, RGB smart contracts can be seen as a distributed network. In this network, no one has a complete current state view, but it still maintains consensus globally (with consensus) due to the one-time sealing technology based on Bitcoin’s proof-of-work (PoW) (which is possible through the Lightning Network as an intermediary) and the same client verification rules (architecture). In this system, only owners can access the states they own and a branch of the state history directed acyclic graph (DAG) directly related to these owned states.

In RGB smart contracts, rights management involves defining specific types of operations that can only be performed by parties who own specific parts of the smart contract state. These operations include but are not limited to asset ownership, identity ownership, asset supply increase rights, sub-identity creation rights, asset clipping/destruction rights, etc.

In RGB smart contracts, users’ rights are implemented. The allowed types of rights are explicitly defined in the pattern, which are called state types because each right must have some current state/value, even if it is “null”. Initial rights are allocated by the contract issuer at genesis, and as states transition, rights can be transferred along with new owners (carrying new state values). The ownership of rights (states) is controlled by Bitcoin scripts and one-time sealing mechanisms. The next owner of a specific right is always defined by the current owner of that right (i.e., the state owner). Client-side validation requires that rights transfers must always be reversely validated by the new owner according to the verification rules.

The RGB smart contract implements the validation rules for rights transfer/state transition, which are defined by the schema using two main tools: schema structure (to determine the allocation of rights among descendants) and simple scripts (to specify the evolution of certain rights states). For example, in terms of assets, the script requires that the sum of outputs must be equal to the sum of inputs. These rules can be further restricted (rather than expanded) at genesis and each state transition. In a specific subgraph of the state DAG, the new owner can trace back and verify these rules until genesis. It is worth noting that violating the rights rules in one ownership branch of a smart contract does not affect the integrity of the smart contract in other branches.

In terms of the core security measures of the RGB smart contract, each right (i.e. state) cannot directly access the state information under other rights. If necessary, in some cases, rights can use metadata to achieve “shared state”. Both the schema and the genesis file specify whether such sharing is allowed.

RGB Smart Contract Example:

When Web3 meets RGB

The emerging smart contract paradigm brought about by the technical innovation of the RGB smart contract gives users the ability to manage rights, providing greater flexibility from asset ownership, identity ownership to the power of asset supply expansion. In the RGB smart contract, the transfer of rights is controlled by Bitcoin scripts and one-time sealing mechanisms, ensuring the secure transfer of rights.

At the same time, the RGB smart contract attempts to solve the problem of old states by introducing the concept of state numbering. This enables the owner of a right to verify the rules retroactively, with the hope of improving system efficiency and security, providing stronger guarantees for contract transfer and state transition, and ensuring that each transfer complies with the validation rules. Overall, the RGB smart contract brings some exciting ideas, especially in terms of the scalability, privacy, and rights management of smart contracts. This innovation is bound to have a positive impact on the entire Bitcoin network and bring more possibilities to the future of the Web3 field.

Unleashing Infinity: A Brand New World Analogous to TCP/IP

In the Bitcoin network, the gradual implementation of proposals such as Schnorr signatures and Taproot, as well as the maturation of layer 2 protocols centered around LNP/BP and RGB, have painted an exciting future for us. In this context, the development path of standard Web3 becomes increasingly clear, constructing a new landscape based on more complex decentralized technologies and cryptographic foundations. The Infinitas technology team believes that this landscape, with the LNP/BP protocol as its cornerstone, will present a layered structure similar to the architecture of TCP/IP, integrating the three key layers of the currency layer, protocol layer, and application layer organically.

Scalability and Efficiency Improvement: The LNP/BP protocol can introduce more second-layer solutions, such as the Lightning Network, to the Bitcoin network, thereby improving transaction speed and throughput, reducing transaction costs, and promoting more efficient fund flow.

Enhanced Privacy and Security: The development of RGB smart contracts will achieve a higher level of privacy and security in the second layer protocol, allowing users to conduct transactions and contract executions in a more private environment, protecting personal information and asset security.

Scalability and Efficiency Improvement: The LNP/BP protocol can introduce more second layer solutions, such as the Lightning Network, to the Bitcoin network, improving transaction speed and throughput, reducing transaction fees, and promoting more efficient fund flow.

Enhanced Privacy and Security: The development of RGB smart contracts will achieve a higher level of privacy and security in the second layer protocol, allowing users to conduct transactions and contract executions in a more private environment, protecting personal information and asset security.

Richer Functions: RGB smart contracts introduce more smart contract functionalities to the Bitcoin ecosystem, supporting operations such as asset ownership, identity management, and asset issuance, promoting the development of more types of financial and non-financial applications.

Reduction of Blockchain Burden: The development of second layer protocols can transfer most transactions from the main chain to the second layer, reducing the burden on the main chain and allowing it to focus more on security and core functions.

Developer Innovation: The development of the LNP/BP protocol and RGB creates a broader space for developer innovation, enabling the construction of more diverse applications and services, and promoting the diversification and prosperity of the Web3 ecosystem.

Development Process of TCP/IP

To better understand this new pattern, let’s quickly review the development process of the traditional computer network. In this field, the development process of the TCP/IP protocol stack plays a crucial role. It has evolved from initial fragmentation to complexity, and finally to standardization and usability. In the early stage from the late 1960s to the early 1970s, different research institutions attempted and developed various protocols and communication methods. In 1969, the Advanced Research Projects Agency Network (ARPA) of the Department of Defense in the United States was established, using the NCP protocol for communication. Subsequently, in 1972, Vint Cerf and Bob Kahn proposed the TCP protocol, and ARPA began to adopt the TCP protocol in 1973, marking the embryonic form of the TCP/IP protocol stack. By 1977, the standardization phase began to emerge, and Vint Cerf and Jon Postel released RFC 791, which defined the IPv4 protocol. Subsequently, core protocols such as TCP and IP were gradually standardized, forming the basic framework we have today. In 1989, Tim Berners-Lee invented the World Wide Web, introducing HTTP and HTML, making the Internet more user-friendly and visual.

Fascinating Narrative

The correct development path of Web3 is built on more complex decentralized technologies and cryptographic foundations, which is the development and evolution of protocols such as LNP/BP and RGB. Similar to the development of the TCP/IP protocol stack (the core of Web2), Web3 must also go through several key stages and require more great contributions, although this journey is long, it is essential. Infinitas, as an innovative solution based on Bitcoin smart contracts, deeply extends on the basis of protocols such as LNP/BP and RGB, and will achieve core technologies such as payment universal addresses, Contractum language smart contract development environment, immutability of schemas, and multi-level secure storage based on RGB client-validated data (Proofs, etc.). Pursuing perfection in every detail to make smart contract writing more efficient and reliable. The integration of these technologies constitutes the distributed Infinitas platform, providing a solid foundation for the development of large-scale Web3 applications.

The Bright Future of Web3 Development

Through the in-depth exploration in this article, we can see a development path similar to the TCP/IP protocol, and there is reason to believe that with the continuous maturation of the LNP/BP protocol and RGB protocol, people’s infinite imagination of the metaverse is becoming a reality. The Web3 world will become more abundant and diverse, and we will soon see:

  • Mass adoption of decentralized finance;
  • The emergence of blockchain games: high-performance competitive, strategy, casual, and other types of games;
  • Diversified social applications on the blockchain: media, dating, video, and other types;
  • Deep integration with AI to prevent AI malicious behavior;
  • Integration with wearable devices and sensors.

The RGB protocol has put us on a brand new starting point, witnessing a future with infinite possibilities similar to Bitcoin. As participants and witnesses in this process, we look forward to a more open, inclusive, and innovative Web3 future that it brings.

Like what you're reading? Subscribe to our top stories.

We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!

Follow us on Twitter, Facebook, YouTube, and TikTok.

Share:

Was this article helpful?

93 out of 132 found this helpful

Gambling Chain Logo
Industry
Digital Asset Investment
Location
Real world, Metaverse and Network.
Goals
Build Daos that bring Decentralized finance to more and more persons Who love Web3.
Type
Website and other Media Daos

Products used

GC Wallet

Send targeted currencies to the right people at the right time.