KR20240099107A - Advanced transaction protocol and ecosystem for creating and deploying smart contracts - Google Patents

Abstract

A method of distributing a cryptographic token, wherein a plurality of fungible tokens are created by one or more smart contracts during a token creation event, wherein a portion of the fungible tokens are available for public sale and distribution by an issuer of the fungible tokens, A portion of the fungible tokens remain locked according to a defined vesting schedule; A number of tokens equivalent to the number of fungible tokens are created simultaneously during a token creation event, where transaction tokens are distributed to investors in exchange for payments received in the form of stablecoins or cryptocurrencies; Trading tokens are exchanged for an equivalent amount of fungible tokens that are vested and unlocked for trading.

Description

Transaction protocol and ecosystem for creating and deploying smart contracts

Cross-reference to related applications

This application is filed under U.S. Provisional Application No. 63/168,597, filed March 31, 2021, entitled “Advanced Trading Protocol and Ecosystem for Creating and Deploying Smart Contracts,” and “Autonomous Protocol for DeFi Token Launching and Collateralized Token Trading.” and Platform", filed on November 19, 2021, and priority is claimed for U.S. Provisional Application No. 63/281,317. Each of the foregoing applications is hereby incorporated by reference in its entirety.

Technology field

The present invention relates to blockchain decentralized applications, smart contract execution, and blockchain processing.

In the processing of data and programs stored, distributed, and executed on public blockchains, blockchains and their networks replace the role of commercial banks as transaction oracles. Blockchain features include:

- Unlicensed transaction medium

- Trusted asset (or contract) verification mechanism

- Distributed ledger (DLT or blockchain) for record keeping

- Virtual machine for smart contract execution

As a transaction medium, blockchain allows two parties to engage in commerce without knowing or meeting each other, protecting the privacy and true identity of both parties. The second key function of blockchain networks is the ability to verify digital assets, virtual currencies, or smart contracts to prevent counterfeiting, double spending, and contract fraud.

The third function of a blockchain network is its ability to store data, functioning as a database that is immune to single-point failures or attacks. Distributed ledger technology (DLT), short for distributed ledger technology, refers to a whole class of linear database configurations. The terms DLT and blockchain are often used synonymously. While it is true that blockchain is DLT, the converse is not necessarily true. A more accurate explanation is that DLT is a special type of database, and blockchain is one specific implementation of DLT.

Specifically, distributed ledger technology (DLT) involves a distributed database managed by multiple participants distributed across multiple nodes. On the surface, storing data on different nodes increases the level of data security, because an attack on one node (or its local data storage devices) cannot access the entire dataset contained in the distributed database. However, storing data on multiple devices distributed across multiple locations does not guarantee that DLT is decentralized.

A truly decentralized database requires that both data content and database access be distributed. A DLT database with centralized control access to a distributed database (e.g., the CFO's desktop computer) is not decentralized. This is because a focused attack against the control interface can access the entire content of the DLT, regardless of where the content is stored.

Blockchain, a fully decentralized version of DLT, overcomes these vulnerabilities by completely eliminating the central control node. Every block contains content (the block's payload) and a block header. The contents of the block header change across the blockchain, but are typically block-number; A time-stamp to ensure that blocks are entered sequentially; and the unique digital identifier of the block required for cryptographic verification or mining.

The payload of a block may be passive information, such as a financial transaction; An identifying “address” of a digital asset or virtual currency; linear database or file; creative work; or other database records. Payloads may also include software in the form of computer programs or decentralized applications such as smart contracts (described in the next section). The payload can contain both encrypted (ciphertext) and unencrypted (plaintext) data.

In addition to the payload, each block is timestamped to provide an immutable, sequential record of events. Another key element of every item on a blockchain is a digital identifier, or signature, which allows third parties to verify that the block is valid and has not been forged or corrupted.

Cryptography in DeFi : One way for users to control access to blockchain content and verify its authenticity is through the use of cryptography ^[35][36][37] . In a broad sense, cryptography uses one of two strategies:

- Encryption and decryption through cryptographic key exchange

- Hashing (encryption only), no key exchange required

In a reversible process of encryption and decryption, the content of the payload (e.g. transaction, data, file, image) is encrypted using a cryptographic key and a defined algorithm to create an encrypted file called ciphertext. The other party can then use the decryption key (which uniquely corresponds to the encryption key) to recover the original unencrypted (plaintext) content from the ciphertext.

However, to decrypt a file, the reader must first obtain a copy of the decryption key through a process called key exchange. Key exchange performed securely over an insecure channel is called public key exchange. There are a variety of public key infrastructure (PKI) mechanisms for cryptographic key exchange, but one common algorithm is split key exchange.

During a split-key exchange, the intended recipient of the encrypted content (not the sender) generates two keys: a public encryption key and a private decryption key. This encryption process is asymmetric in that the decryption key can decrypt content encrypted with the encryption key, but the encryption key cannot be used for decryption.

The receiver then sends the encryption key to the sender node to encrypt their content accordingly and the resulting ciphertext is sent to the receiver. Because the encryption key is not useful for decrypting ciphertext, both the public key and the encrypted file can be passed publicly over a public channel (hence the name "public key").

However, in most cases, sharing cryptographic keys with users requires prior permission to access the block's contents. These applications are called permission systems because access must be granted by an administrator. Paradoxically, PKI is not only used in blockchain for trusted verification, but blockchain is now being used symbiotically to improve the integrity of PKI.

PKI methods can be used to protect the contents of a blockchain, but they are unnecessarily complicated for a verifier to simply verify that the integrity of the chain has not been compromised or that the origin of the block in question has been altered. Instead, an alternative approach, called a permissionless system, is preferred, where miners do not need to request access to the blockchain and sufficient information is publicly available to independently verify the authenticity of the chain.

This is where the role of the cryptographic hash begins. Hashing is an encryption process in which a file of arbitrary size is encoded with a fixed-length ciphertext based on the contents of the file being hashed rather than a separate encryption key. The properties of a cryptographic hash are:

- One-way: Content can be converted to a hash, but analyzing the hash cannot reveal the content that created that hash (even if you know the hashing algorithm).

- High non-linearity: small input fluctuations can cause dramatic changes in the hash output, affecting more than half of the bits (sometimes called the avalanche effect)

- Randomness: The output of the hash cannot be predicted from the input file.

- Fixed length: Hash output has a fixed length regardless of the input size.

- Deterministic: inputting the same file to the hash will always produce the same output.

- Collision avoidance: Statistically, it is extremely unlikely that two different source files will produce the same hash output. For all practical purposes, every hash output is unique.

Compared to encryption, an important difference in hashing is that the process is one-way. This means that once a file has been hashed, its original content cannot be recovered or extracted from the hash output. At first glance, the process of creating a file that no one can read may seem useless, but it turns out that hashing has become a critical component in verifying all blockchain transactions today.

The unique property of the hashing process is that it is a deterministic but highly non-linear operation. Even the slightest variation in the source file produces very different and unrecognizable hash code output. Statistically, this property means that the only way for the hash of one file to match the hash of another file is if the two files are identical. Metaphorically, a hash is a digital fingerprint useful for rejecting fraudsters, excluding fraudulent blocks, and preventing content tampering. The fingerprint function of a hash can be used to verify that a series of blocks in a chain belong together and are self-consistent. A hash of a hash of a hash is called a hash chain, for example:

H[H[H[H[x]]]] ≡ H ⁴ [x]

Hash chains make sequential verification of the chain simple - inserting a fake block will generate a series of mismatch errors that will easily be detected as fraudulent by a third-party verifier. To apply hashing to the process of validating a blockchain for third-party inspection, blockchains use nested hash chains.

In a nested hash chain, each block contains both the hash H[x] of the previous block and new content, including transactions, data, images, etc. For example, if x = n, n-1, n-2, n-3, ..., the nesting of hash chains can be expressed as the data structure below:

Block(n) = Content(n) + H[Block(n-1)]

Block(n-1) = Content(n-1) + H[Block(n-2)]

Block(n-2) = Content(n-2) + H[Block(n-3)]...

As shown in Figure 1, successive blocks of data (2a, 2b, 2c, 2d...) are arranged linearly over time to form a digital ledger or chain, where new entries are only added to the end of the chain. You can. A chain of blocks, or blockchain (1), consists of transactions, financial information, and artistic content (items A, B, and C) represented by a payload (8) and metadata used to validate existing and new blocks. (6) and content related to the block header (3) including subheaders (5, 7). Every time a new transaction is initiated, a network of computer nodes called miners or validators must first check whether the blockchain they are looking at is valid or corrupted. Because the same blockchain persists permanently across hundreds of thousands of devices, it is impossible for a hacker to find and compromise enough blockchains to change the outcome of ongoing transactions. Without a central authority auditing the ledger (the way commercial banks verify financial records), blockchain integrity is verified using cryptography, including encryption, and through the cryptographic hashing process described earlier. By sequentially concatenating a series of hashes corresponding to the arrangement and contents of blockchain blocks, any change, insertion, or deletion in a block can be easily detected without knowing what the block contains. A series of hashes that include the previous hash is called a nested hash chain.

In a nested hash chain, each block is hashed and embedded in the block header of subsequent blocks on the chain. As shown, the contents of the entire block 2b (denoted as block n-2) are hashed by the hash function 4b and the output is the sub-header contained in the block header 3 in block 2c. It is implied in (5). Likewise, the content of the previous block 2a is hashed with the hash function 4a and is contained within the block header of block 2b. In this way, every block contains the hashes of all blocks before it in time. The metadata sub-block 6 may also contain time and date stamps, making the blockchain linearly temporally constrained. During block verification, if the hash recorded in any particular block matches the hashing result of the previous block, that block does not belong there and the blockchain being evaluated is corrupted or corrupted.

Apart from using hashing to verify the legitimate order of blocks, hashing can also be used to verify the content within a block. Unlike sequential blocks on a nested hash chain, the hashed data of transactions contained within a block is hierarchical rather than sequential, with each hash connected to its parent along a relationship similar to a parent-child tree, with the most Hashed transactions constitute the parent branch of the "leaf" items. Additionally, as shown in Figure 1, this hierarchical arrangement, called a Merkle tree 13, consists of binary pairwise hashes 9a, 9b, 9c, 9d, 10a, 10c and a root 11. and the root 11 can be extended to 2, 4, 8, 16, 2 ^m-1 elements (excluding the root) for any tree with m≥2 layers. The advantages of Merkle trees are:

- Ability to determine the integrity and validity of data within a hierarchical database

- Ability to verify the integrity of specific tree branches even if parts of the tree are damaged or not yet available

- Lightweight, adds minimal data overhead

- You can check branches without examining the entire tree

- Only a small amount of memory is required to perform validation

- Minimal network traffic occurs during validation

A Merkle tree is created by hashing hash pairs repeatedly until only one hash remains. In the block encoding process, transactions are hashed (actually at the top of the hash tree) starting with blocks containing individual instances, e.g., content A, content B, and content C. Since there is no content (D) to hash (i.e., D is a null entry) and binary hashing requires hash pairs, H _D is made a replica of the H _C hash to maintain binary leaf symmetry.

H _A = H[Content A]

H _B = H[Content B]

H _C = H[Content C]

H _D = H[Content C]

The hashes are then paired, concatenated (or merged), and hashed again in an iterative manner, until a single hash remains. Using ∥ to denote the chain, the hash pair H _AB and H _CD is given by:

H _AB = H[H _A ∥H _B ]

H _CD = H[H _C ∥H _D ]

This behavior describes the hashing process running one layer down in the leaf hierarchy. If there are more than two hashes remaining forming the middle layer, the process is repeated until only two hash files remain. By hashing these two remaining hashes, the final hash, called the Merkle root (H _MR ), is obtained:

H _MR = H[H _AB ∥H _CD ]

Therefore, the Merkle root (11) represents the single unique hash of all constituent hashes of the tree. By including this Merkle root in the sub-header (7) of the header (3) within block (2c) and likewise in every block in the blockchain, a quick check can be used to verify block integrity throughout the tree. If the hash of the block does not match the Merkle root of the header, the content of the block has been tampered with. This means that blocks may contain fraudulent transactions or corrupted smart contracts.

Importantly, hashing provides a means for verification nodes or miners to verify the authenticity of a block in progress before installing it on the chain. But how can we trust jury nodes? Ensuring truthful verification is another role of cryptography in blockchain processing. To avoid the risk of authentication compromises, verifying and recording transactions is done through a consensus mechanism, a voting process by an anonymous jury-of-peers. Because jury nodes in a blockchain network do not know the identities of the parties involved in the transactions they verify, there is no logical incentive for jurors to cheat or vote with bias when evaluating the integrity of a new entry.

Nodes can vote without doing the exhaustive work of checking hashes, but jurors who have a chronic history of disagreeing with other nodes are suspects and are ultimately excluded from jury consideration. Another way to curb inappropriate behavior among miners verifying transactions is to use a proof mechanism. In one of these concepts (Proof of Work), each block header contains a hash of a random number called a nonce, a cryptography term meaning number used once . Borrowed from the field of trusted communications, it introduces randomness into transactions to prevent replay attacks by using a nonce as an authentication method, thereby preventing outsiders from executing hacks by guessing the next action from the last action. To have a chance to verify (mine) a block, the verifier must first solve a hash-nonce puzzle to extract the nonce value (a random number with a varying number of leading zeros).

These indiscriminate efforts require energy use and money expenditure, thereby discouraging insincere efforts or fraudulent results. In a PoW implementation, this same hash-nonce puzzle is used to mine new cryptocurrencies. In addition to verifying blocks, cryptography can also be used as a credential to verify the authenticity of the content itself (e.g. art, music, tickets, etc.). This feature is especially important for trading non-fungible tokens (NFTs). By using cryptography to verify blocks and digitally sign them, blockchain can provide users with “trust in a trustless environment.”

Blockchain Properties : Blockchain properties include the following major functions and characteristics.

- Trusted : Every node in a blockchain network contains a copy of the same digital ledger, so there is no way for a fraudulent block to be inserted without it being detected and expelled from the network. In this way, fraudulent transactions and corrupted blocks are not recorded on the blockchain.

- Immutable : Once an item is time-stamped and recorded on the blockchain, it cannot be removed or reordered ^[60] . Once indelibly recorded on the blockchain, there is no way to rewrite the block's history and chronology and corrupt it after the fact.

- Decentralized : By using a network of anonymous nodes to realize an autonomous virtual machine of the blockchain, no central computer or network operator can control the activities of the blockchain. Therefore, there is no single device or node vulnerable to cyberattacks; There are no operators who can bribe or coerce; And there is no personal information to leak. Decentralized peer-to-peer (P2P) networks can avoid manipulation and repel distributed denial-of-service (DDoS) attacks. This is because a would-be hacker cannot identify which servers within the cloud are hosting the various nodes of the blockchain virtual network.

- Redundant : The digital ledger that forms the blockchain is shared across multiple nodes in the network, eliminating any single point of failure or concentrated vulnerability. This parallel node structure provides data, network, and compute redundancy.

The benefits of redundant distributed virtual machines include timely and reliable resolution of transactions and operations even when a node or its communication network goes offline. An early example of redundant computing with jury-based decision making was the computer used to control NASA's space shuttle.

However, decentralized redundant networks should not be confused with distributed computing. In distributed computing, work is divided into separable pieces and assigned to each node to distribute the work fairly. By parallelizing efforts, the time it takes to complete a task is reduced proportional to the number of nodes contributing to the task. Likewise, the total energy consumed to perform a computing task (E _job ) is distributed across virtual machines with “n” nodes. Here, each node consumes an average energy of E _job /n per task.

In contrast, in decentralized computing, a single task or task is performed identically in parallel by “n” network nodes acting in unison as a redundant array of computing nodes. Therefore, the time required to perform a task is not reduced at all by the redundancy of the virtual machine. In fact, in decentralized computing, the slowest node in the network determines the transaction speed of the blockchain virtual machine. Moreover, the energy required for decentralized computing increases from E _jobs consumed by the central computer to n·E _jobs in the decentralized version. This means that decentralized computing is less energy efficient than centralized computers.

- Consensus Validated : A key element of a redundant system is a means of mediating disagreements between nodes. In other words, it determines what to do if nodes cannot unanimously approve whether a new transaction is valid. Decision-making during conflicts is facilitated through peer jury voting using a consensus mechanism ^[64] that aggregates the results of multiple nodes performing the same task. The required consensus criteria for passing or rejecting an ongoing transaction vary depending on the blockchain implementation.

Consensus attacks used by hackers to corrupt votes (e.g. Sybil attacks, etc.) can be defeated using various camouflage techniques to obscure random anonymous nodes and jury nodes.

Proof : A key concept in implementing reliable consensus decisions is a means of ensuring that all participating nodes are truthful, i.e., a means of verifying that a node's vote is meaningful. Ensuring that a node is a truthful juror is called “proof,” and a more insightful explanation of what keeps a node honest should be called proof-of-sincerity. But how can a blockchain virtual machine ensure that its nodes are acting truthfully and in the best interest of the blockchain's integrity and user community?

The first step in ensuring transaction integrity is to protect the identities of parties participating in a transaction, preventing validators from engaging in conspiracy or bias voting, or "gaming" the system, i.e. intentionally committing illegal acts. It is to prevent.

A common way proof is achieved to prevent fraudulent voting is to ensure that jury nodes have something to lose if they vote insincerely or dishonestly. For example, (i) you have to spend money and effort to participate in the verification process (“proof of work”) ^[67] , (ii) the value of the assets you hold may be negatively affected by your actions (“Proof of Stake”), or alternatively (iii) jury nodes hold certain credentials that authenticate them as participants so that they can only receive rewards if they consistently vote with a majority (without knowing in advance what a majority vote is) there is.

Proof-of-Work (PoW), first deployed as part of the Bitcoin blockchain and later adopted by Ethereum, intentionally wastes electricity as the cost of mining new blocks. Illegal or bad behavior can be deterred by forcing hackers to submit costs, and they can recover those costs only to the extent that they are not disqualified for bad behavior. Recently, PoW, with its enormous carbon footprint, has come under intense scrutiny worldwide for being energy-wasting, environmentally irresponsible and ecologically unsustainable. Alternative and environmentally friendly methods such as Proof-of-Stake are currently being adopted.

However, the move to Proof of Stake (PoS) has been much slower than expected. This is partly because users are not confident that they can avoid the nothing-at-stake problem. This is a malicious deception that deceives other nodes into thinking that the node has a significant economic interest in the blockchain's cryptocurrency when in fact this is not the case. In PoS consensus voting, if ineligible nodes are not detected, they can commit fraudulent transactions (such as double spending) or intentionally destroy valid transactions. Other options include credential-based consensus verification, time-stamped “Proof of History” (PoH), or dynamic node governance and inimitable cryptographic hop codes (a type of nested hash called an ephemeral blockchain). Includes HyperSphere's "Proof of Performance" (PoP), a decentralized consensus algorithm that employs chains.

In addition to improving transaction speeds, these new consensus algorithms offer a substantially smaller carbon footprint and improved resilience to hacking compared to previous algorithms. In effect, the HyperSphere hop code creates a cryptographic proof of a node's contribution as part of the network that moves data and performs the actual work, which is energy that would have been used even if consensus verification was not included. That is, PoP verification can be run as part of packet communication without consuming additional energy.

However, due to inherent differences, these new consensus mechanisms cannot be applied to existing blockchains and must instead be initially built into the blockchain architecture.

Security : As previously explained, cryptography provides security to blockchains and their transactions in a variety of ways, providing a means of authenticating the integrity and origin of blocks in the chain and allowing new blocks to be added to the chain once they are verified. includes promoting. Additionally, cryptography can verify the Merkle tree of a block to ensure that the content has not been altered, preventing double spending, fraud, or smart contract tampering.

Cryptography using hash-nonce puzzles or security credentials released through the blockchain virtual machine verifies the veracity of the jury nodes involved in approving transactions.

Cryptography using private keys protects assets stored in decentralized wallets and traded through smart contracts. Using digital signatures, the authenticity of an asset can also be verified, which is an especially important feature when trading collectibles using non-fungible tokens (NFTs).

Although blockchain transactions are protected by cryptography, network communications over the Internet are still exposed to surveillance, metadata analysis, phishing attacks, and malware. Transactions conducted through Internet browsers, insecure wallets, and poorly designed protocols are particularly vulnerable to attacks designed to steal users' private encryption keys. To prevent such hacks, the level of blockchain protection can be strengthened by modifying network communications, especially by obfuscating or encrypting packet data at OSI layers 3, 6, and/or 7 (network, presentation, and application layers, respectively). . This is a feature unique to HyperSphere.

Unlike mining and verification of passive cryptocurrencies, which are vulnerable to DDoS and consensus attacks, the hard-coded instructions in smart contracts (once uploaded to the blockchain) cannot be changed. Therefore, to a limited extent, a cyber hacker can only prevent smart contract execution by the operation of the blockchain's virtual machine (BCVM) hosting the smart contract or by disrupting the system's state machine, for example using time jacking, re-entrancy, etc. It can be a hindrance. The risk of DeFi cyberattacks is amplified by poorly written code, significantly increasing the attack surface of smart contracts vulnerable to hacking. Preventing such risk exposure requires thorough review by experienced dApp and cybersecurity experts.

Transparency : Single, decentralized blockchains such as Bitcoin and Ethereum are public, providing public inspection of block entries and transactions. A single public blockchain facilitates tracing the lineage history of addresses associated with transactions, including wallets, digital assets, and smart contracts. Permissionless smart contract downloading allows for inspection of smart contract code by creators, users, and authorized third-party verification services. The downside to the transparency of a public single blockchain is its vulnerability to a variety of attacks, including backtracking of high-value wallets. Fortunately, the wallet address is public, but the actual identity of the wallet owner is not.

Transaction Speed : The speed of blockchain varies depending on the verification mechanism and temporal and hierarchical structure ^[79][80] . For example, Proof of Work (PoW) is significantly slower than Proof of Stake (PoS), and PoS is slower than Proof of History and Proof of Performance. A single, public, unified blockchain is inherently slow, and transaction throughput decreases as the chain grows (i.e. longer). Parallel chains, such as DyDAG, can provide higher transaction speeds because shorter chains with fewer blocks can be confirmed faster and with a higher degree of parallelism.

When executing smart contracts that involve logical and arithmetic calculations, OPS (Operations Per Second) speed becomes an important factor in smart contract execution time. In most implementations, blocks are mined, or traded, at fixed intervals called block times, which are specific to the blockchain network. For example, Ethereum previously ran with a block time of 15 seconds and reduced the block time to 12 seconds in 2012. The new competing chain is faster and has a shorter block time of around 2 seconds. In contrast, Bitcoin, the first generation blockchain, takes 9 minutes to solve one block. Performing the same amount of work in less time requires faster computing speeds. However, because blockchain does not control the hardware used by miners or validators, it cannot prescribe hardware or minimum performance levels for nodes in the network.

Because every transaction is time-stamped when a block is written to the chain, a means to measure and monitor the evolving performance of the network already exists. A simple statistical analysis of recent chain transactions allows you to immediately determine the current processing time of the blockchain node community. Details of the computer architecture and GPU semiconductor technology used in the nodes are not reported, but improvements in computing performance, i.e. if miners purchase faster processors, are statistically seen in transaction speeds. Therefore, network performance improvements can be adjusted to reflect continued performance improvements in specific BCVMs.

However, raising the performance standards of decentralized networks carries risks ^[82] . As blockchain specifications are upgraded, the network will inevitably be controlled by fewer and more capable computing nodes that only wealthy miners can afford, thereby threatening node diversity and decentralization. Another key factor that determines arithmetic OPS speed is block size. Instead of measuring blocks in bytes, block size is measured in terms of the maximum amount of gas allocated to the block. Since gas is a unit of measurement for the computational effort required to execute a specific operation, the gas limit measures the maximum computational effort of a block, where the gas required per operation is specified by the gas consumption rate (G).

For example, before the gas limit and OPS rate increase in April 2021, EVM had a gas limit of 12.5M, a block time of 12, and a fixed consumption rate of G = 3 per integer operation ^[85] , thus

=

350k ops/초

=

350k ops/sec

This instruction processing speed is considerably slow compared to computing standards, and is comparable to the speed of a 1965 IBM System/360 computer. On the other hand, graphics processors readily available for gaming today perform floating point (not fixed integer) calculations at 30 TFLOPs, eight orders of magnitude faster than EVM-based dApps. It may seem obvious to improve throughput, but gas limits may be increased to accommodate larger blocks, and the risk that a significant number of nodes will not be able to complete their work within the allotted block time increases exponentially with a linear increase in block size. grows exponentially. Incomplete block verifications must be discarded and repeated, increasing gas fees and delaying the completion of smart contract transactions.

Smart contracts ( dApps ) : Instead of simply storing passive data, second-generation blockchains (and beyond) support decentralized applications (dApps) called smart contracts. Smart contracts contain software-based if-then-else conditional logic that can react to changes in state variables specified in the contract, including time and date, transaction, price, token supply, and previous transactions. Smart contracts can also perform fixed integer arithmetic operations, but not floating point calculations.

Blockchain enables smart contracts in several ways, including: (i) providing a decentralized platform for storing and distributing dApps to users, and (ii) transacting with updates to the latest and most current contract instances. (iii) provides a consensus mechanism to verify new contract instantiations, and (iv) acts as a blockchain virtual machine (BCVM) required to execute smart contract commands.

Inspired by the concept of decentralization first presented by the file sharing program BitTorrent, and starting from a profound awareness of the economical application of distributed processing using nodes of limited computing power (i.e., performance comparable to ES-EVM), The concept of a 'non-stop computer' without any dedicated hardware platform was born. This pioneering proof of concept in decentralized applications, the Ethereum virtual machine (EVM), has proven to have an impact that no one could have predicted.

In fact, the basic design of almost all blockchain virtual machines is essentially unchanged from the Ethereum blockchain pioneer. As depicted in Figure 2, structurally, the Ethereum Virtual Machine (EVM) operates as a state machine consisting of lightweight decentralized applications stored on the Ethereum blockchain that can perform various levels of computing applications without a dedicated host processor.

As shown, the realization of the Ethereum virtual machine involves three elements. That is, (i) an immutable dApp (20a) containing EVM code (21) stored on the blockchain; (ii) a world state (σ) (20c) that is updated but remains persistent as an “account store”; and (iii) machine state (μ), which includes volatile instances of the Ethereum virtual machine that exist temporarily during transaction processing (20b).

The EVM's computing kernel is the EVM's operating system and includes software stored on the Ethereum blockchain. Using the blockchain as a virtual read-only memory (virtual ROM), this EVM OS code 21 cannot be modified or edited other than executing updates as a completely new instance on the blockchain. After that, the previous version will remain available forever. In this way, the Ethereum blockchain functions as a trusted platform for distributing software (in this case, the Ethereum Virtual Machine). To call the EVM, a smart contract written in Java-Script like language called Solidity makes a function call to the EVM OS.

When the EVM OS is started on an Ethereum network node, it collects variable data from a designated decentralized account repository that represents the world state (σ). Loading this data into the EVM allows the system to catch up on events that occurred during sleep mode. In other words, you can make it up to date. For example, if a number of tokens were sold via a smart contract as the last recorded transaction before going dormant, this available supply data is passed from the account store to the EVM OS as a starting point for processing.

The data in the account store 26 is stored sequentially as key-value pairs containing a 32-byte wide cryptographic key identifying each state variable 27a and the corresponding current value of data 27b, which is also 32B wide. World state (μ) data is described as "persistent" because this data is always loaded from the account store 26 when the EVM OS boots and is saved again when the operation begins.

The core of the EVM OS executable code is the machine state (μ )(20b). During EVM execution, operation instructions are loaded from virtual ROM while current state information is loaded from account storage. Transfers to the state machine occur in bursts of 32B data, stored either in 1B wide memory or in a 32B wide program stack. The machine state (μ) is volatile and is not maintained after execution of a smart contract except for data written to storage as the world state (σ) 20c.

As with RPN-based programs and counters, the program stack of the machine state (μ) contains a mixture of prescribed operation instructions and data that are executed sequentially with each advance within the program counter. Completed operations are "popped" to the top of the program stack, with execution continuing until the task is complete or the gas runs out. To prevent transactions exceeding the maximum allowed block size, careful programming of smart contracts on the EVM state machine is ensured. Block overflows can cause failures, permanently damaging mining efforts for that block, causing program execution failures, incomplete transactions, and/or uncertain states. Because there is no way to determine in advance whether a program step will exceed a gas limit or block time, looping, hold states, and floating-point arithmetic are also prohibited.

Lastly, special care must be taken to ensure that smart contracts running on the EVM are bug-free. Writing data to an inappropriate address or a smart contract in a suspended state can result in irrecoverable asset loss.

The operation of the EVM is just an example. Implementations of random blockchain virtual machines are chain-specific and use different implementations, languages, protocols, and consensus mechanisms ^[90] . Live chains include BSC Binance Smart Chain, Huobi ECO Chain, Solana, Polkadot, Cardano Ouroboros, HyperLedger, Tezos, Stellar, EOS, IOTA Tangle, etc. Some of the aforementioned blockchains actually include blockchain platforms for hosting client-specific virtual machines and networks.

One such platform is HyperLedger, the Linux Foundation's custodian project for open source blockchains, with major support from IBM and SAP-Ariba. Frameworks developed based on HyperLedger include Hyperledger Fabric, Hyperledger Iroha, Hyperledger Sawtooth, and Hyperledger Besu, as well as various developer tools.

Another platform for blockchain development is Polkadot. Created by Gavin Wood, co-founder of Ethereum and developer of Solidity, Polkadot aims to be a development ecosystem for blockchains. The essential components of this system are Relay-Chain, an integrated tool that supports network interoperability of parachains, parathreads and sharding, and its own blockchain that supports fast processing and high transaction throughput while supporting custom governance and tokens. This is a method that allows developers to create.

One such smart contract platform developed on Polkadot is Moonbeam, an Ethereum-compatible network that allows developers to use existing Solidity-based smart contracts and related dApps on Moonbeam without major changes. By porting Solidity dApps to Polkadot's Moonbeam, beneficial performance improvements over Ethereum hosting include reduced costs and increased transaction throughput.

Smart contracts also play a special role in creating, distributing and trading digital assets called tokens, which include both fungible and non-fungible tokens (NFTs), described below.

Crypto & DeFi Transactions : Blockchain supports a variety of digital assets and their transactions. For example, chain-native cryptocurrencies such as BTC and ETH, fungible utility and security tokens for various financing, investment and commercial purposes, e.g. ), there are non-fungible tokens (NFTs) used to acquire and trade collectibles of limited edition content. Smart contracts allow unrelated parties to engage in shared activities such as trading (swapping), lending (staking), borrowing, and market making (providing liquidity). Smart contracts can also be used to automatically create new token offerings.

Similar to a group of people pooling money together to buy a lottery ticket, smart contracts can anonymously pool money from a group of unrelated investors or venture capitalists to jointly fund a project; invest in index or synthetic funds; It can be used to provide capital to DAOs (decentralized autonomous organizations) or corporations. Smart contracts that enable shared investments by unrelated parties are called decentralized finance pools, DeFi pools, or liquidity pools ^[100] . DeFi pools are virtual and decentralized, meaning they do not physically exist on a single server, device, website, storage device, or are located in a specific country or residence. Therefore, DeFi pools are simply smart contracts shared by investors.

Platforms or websites that host and award access to a DeFi pool are not participants in the pool. A host platform that exists far from pool operations is simply a link or user interface (UI/UX) created to access the pool's smart contracts. All terms and conditions of the pool are defined by the smart contract, not the platform. Therefore, no platform or device can control the transaction terms between the pool and participants. Therefore, DeFi pools are P2P (Peer-to-Peer) commerce.

Tokens created by smart contracts are automatically and algorithmically created by, for, and on behalf of pool participants. Except in the case of corporate token issuance, tokens released by a DeFi pool in a token generation event (TGE) do not have an issuer. Because there is no issuer, TGE does not meet the legal definition of a security issue. This subtle but important distinction that issuing tokens without an issuer does not constitute an “offering” will remain a hotly debated legal issue for the foreseeable future.

Since there is no central authority that can regulate autonomously executing smart contracts, investors and token traders must consider DeFi transactions in the context of buyer beware, ensuring that smart contracts are bug-free and that DeFi pools are legal. It is a good idea to take extra precautions to ensure that your project or development is indicative. In the case of corporate issuances, as in the case of private and equity purchases, an appropriate level of due diligence is recommended.

Cryptocosm Summarized : Considering the foregoing in-depth discussion, several key high-level implications can be inferred.

1. Blockchain provides a decentralized ecosystem that allows people to participate in peer-to-peer financial transactions and record keeping without the control of central authorities or financial institutions. Blockchain is therefore inevitably disruptive (perhaps beneficial or detrimental) for the banking and financial services sector.

2. Transactions on a blockchain, arranged in a linear order of finite-sized digital blocks, are indelibly recorded and use cryptography to create new entries and involve a jury of peers to verify the veracity of existing block entries. Uses a consensus mechanism.

3. Items on a blockchain may include smart contracts, including decentralized application dApp software, as well as passive components such as data, ledgers, records, and chain-native cryptocurrencies (BTC, ETH, etc.).

4. Decentralized applications and smart contracts can be accessed, downloaded, and executed (called) directly on public blockchains without risk of tampering with the source code. Verification and certification of the quality and integrity of smart contracts by third-party experts is commercially available and recommended.

5. The dApp runs not on a private website (which risks hacking), but on a cloud-based blockchain virtual machine (e.g. Ethereum's EVM) that allows transactions to be completed over a decentralized network without dedicated hardware or devices. takes place in

6. Due to the risks of typos, bugs, and poorly written logic, arithmetic, and function calls that are unavoidable in passive smart contract code writing, an autonomous dApp software called a protocol is used to comprehensively generate smart contracts according to a defined algorithm. . Protocols must also be carefully checked and thoroughly investigated.

7. One of the main classes of dApps is the use of smart contracts to create, launch, trade and pledge DeFi tokens. Tokens offer numerous beneficial features not available in passive chain-based cryptocurrencies, such as those created through crypto mining efforts.

8. DeFi tokens that share a common smart contract are called DeFi pools. If backed by a token issuer, such as a corporation, DeFi pools can be used to bring new tokens to market. Alternatively, DeFi pools funded by liquidity providers operate as autonomous marketplaces for trading or lending traditional virtual currencies and non-fungible tokens. DeFi pools exemplify peer-to-peer (P2P) commerce.

What are DeFi tokens? : Broadly speaking, a digital token is a cryptographic token created by executing a smart contract on a public or private blockchain. These tokens are:

- Issued as a centralized virtual currency (digital currency) by the government using a highly regulated permissioned blockchain, or

- Issued by corporations or non-governmental organizations (NGOs) as non-financial tokens for identity, access rights, or gaming using private permissioned blockchains;

- Non-fungible tokens (NFTs) released by artists and gamers as collectibles and virtual assets in the metaverse, or

- Launches as a fungible DeFi token containing decentralized tradable assets using a public permissionless blockchain.

The first two examples, government-issued digital currencies and personal access tokens, are not decentralized and are therefore outside the scope of this specification. The third item, non-fungible tokens, includes its own DeFi token class. Unlike fungible tokens, which are comprised of multiple indistinguishable digital tokens of identical value that are useful for commerce, non-fungible tokens exhibit properties of uniqueness, identity, and ownership (royalty rights).

Trading NFTs across various blockchain-specific marketplaces and communities requires extensive cross-chain transactions where gas fees, not utilities, are a significant factor.

The fourth category, decentralized fungible digital assets known as DeFi tokens, represents an incredibly broad and expanding asset class. DeFi tokens deployed on public permissionless blockchains are not created by solving puzzles, but by executing smart contracts, i.e. dApps hosted on one or more blockchain virtual machines (BCVMs).

One distinguishing difference between DeFi tokens and cryptocurrencies is “total supply.” Unlike cryptocurrencies, where new coins can be mined at any time (even if losses occur), the total supply of tokens at launch is fixed in quantity and cannot be adjusted later. DeFi tokens come in various forms, including:

- Cryptographic wraps of fungible and tradable cryptocurrencies (e.g. WETH)

- Stablecoins, which include fungible and tradable tokens with a value pegged to real assets such as fiat money, gold, etc.

- Fungible and tradable tokens issued by companies or organizations

- Fungible and tradable tokens autonomously launched by and for DeFi pools

Crypto Cash Equivalents : The first two items, cryptocurrency wraps and stablecoins (simply referred to herein as “crypto”), operate as crypto cash equivalents in the cryptocosm. These assets have a defined value at the time of transaction, so they can be used to exchange publicly tradable assets of defined value for private or publicly traded tokens with speculative future value. The value of crypto cash equivalents when trading DeFi tokens is well defined in large global markets. Some tokens are additionally collateralized by non-crypto assets such as gold or fiat currency to combat volatility. These tokens, called stablecoins, have a value pegged to their fungible counterparts.

For example, Tether is a stablecoin pegged to the US dollar, with a value of {1 } ≪The value is {1 $USD}. Stablecoins mediate the world of tokens and cryptocurrencies, as they can be traded on digital currency exchanges and can also be used for autonomous execution of smart contracts. In the commercial press, stablecoins are often incorrectly referred to as cryptocurrencies (similar to BTC and ETH) because they perform store of value and commerce functions. However, stablecoins are tokens, not chain-native cryptocurrencies, which is why they can be used in smart contracts without being wrapped first (where BTC and ETH cannot).

For example, US dollar-backed stablecoins ( , USDC, DAI and BUSD) are pegged to the US dollar at a fixed 1:1 exchange ratio (with some small slippage). Currently, other stablecoins are being issued pegged to the Euro, British Pound, Japanese Yen, and Singapore Dollar. For a volatile currency with high trading volume like ETH, its cash equivalent value is constantly changing. Therefore, during any DeFi transaction, Ether must be valued at the “spot” transaction price, i.e. the market value frozen at a specific moment or period of time. To avoid misunderstanding, certain public digital currency exchanges (e.g. Binance) are designated as the exchanges on which reference trading prices are based.

Chain-native cryptocurrencies such as ETH suffer from several disadvantages compared to tokens. First, it is locked in its own blockchain and there is no interoperability between chains. Second, it is not compatible with ERC-20. This means that it cannot be used to process transactions through smart contracts. Third, as a liquid, tradable and fungible cryptocurrency, it cannot be locked or held as collateral except when transferred to a custodial wallet (a wallet with private keys controlled by another party).

The solution to this challenge is tokenization, i.e. converting chain-native cryptocurrencies into tokens. The token conversion process, which converts fungible assets into smart contract-compatible tokens, is performed prior to engaging in dApp-based commerce and therefore does not impact real-time transaction throughput. The process of tokenizing a cryptocurrency is called “wrapping.” Token wrapping involves locking an asset into a smart contract and creating a specified number of corresponding tokens. Initially, the total value of these tokens will be equal to the value of the underlying asset securing them. Therefore, a token wrap is a mirror of the underlying asset used to create it, and its value depends on the quality of the asset backing the token and the smart contract used to create it. Therefore, Token Wrap is also called tokenized cryptocurrency.

Any crypto asset can be wrapped. Cryptocurrency token wraps are often identified by adding the prefix “W” to the cryptocurrency’s symbol name. For example, WETH is a wrap for Ether, WBTC is a wrap for Bitcoin, etc. For convenience, token wraps are generally issued at a 1:1 ratio with the underlying asset, and maintain a constant price ratio despite market fluctuations in the value of the underlying asset. In other words, when the price of ETH rises, the price of WETH also rises.

가격 {1 BTC}와 같다. 마찬가지로 이더리움 네트워크에서, 가격 {1 WETH} 가격 {1 ETH}이다. 토큰화된 암호화폐의 가격 비율은 그 기본 자산에 대해 고정되어 있고 스마트 계약은 토큰만 거래할 수 있다는 것이 일반적으로 이해되기 때문에, 래핑된 암호화폐를 언급할 때 W 접두어를 제외하고, 암호화폐와 해당 토큰 대응물을 동등하게 언급하는 것이 일반적이다.For example, the value of Bitcoin Lab is equal to the real-time value of Bitcoin. i.e. price {1 WBTC}

Price is equal to {1 BTC}. Likewise on the Ethereum network, the price {1 WETH} The price is {1 ETH}. Since it is generally understood that the price ratio of a tokenized cryptocurrency is fixed to its underlying asset and that smart contracts can only trade tokens, the W prefix is excluded when referring to the wrapped cryptocurrency. It is common to refer to the corresponding token counterpart as equivalent.

The process of tokenizing assets through wrapping involves executing a smart contract. In the wrapping process shown in Figure 3, the value of the investor's 30 assets 34a in the wallet 31a collateralizing the tokens is first locked by the smart contract 32a 34b and transferred to the blockchain 33 as the new owner address. It is recorded in The smart contract 32b then releases those tokens, called token wraps 35, at a fixed rate, and the releases to the wallet 31b are recorded on the blockchain network hosting the smart contract. Unwrapping a token is simply the reverse of the process, giving up the token and releasing the asset. Since many smart contracts are written in Solidity to be compatible with the Ethereum blockchain and EVM, various versions of ETH and generalized WETH form a natural token-wrap pair. Compared to trading on-chain native cryptocurrencies (ETH, BTC, etc.), there are many advantages to using token wrap on a smart contract-enabled blockchain, including:

- Conditional transactions: Using smart contracts and blockchain oracles, token wrap-based transactions can be executed conditionally based on changing market and economic conditions.

- Increased transaction speed: Smart contract verification of Token Wrap transfers is simpler and faster than manually executing transactions via chain-native cryptocurrency or transactions that require laborious block-by-block verification and jury consensus by all nodes.

- Increased transparency: With Token Wrap, smart contracts provide unprecedented transparency, made possible through unrestricted public access to the blockchain specifying token governance and transaction statistics (e.g. number of tokens outstanding, created, transferred, burned).

- Interoperability: Token Labs is interoperable across a wide range of wallets, exchanges and dApps and is uniquely tuned to trade with assets on any fork (network) of the Ethereum blockchain. WBTC allows you to execute Bitcoin payments or swaps using Ethereum-based smart contracts that are not compatible with Bitcoin transactions.

- Portability: Token Wrap can be used to facilitate cross-chain transactions by launching linked smart contracts on two or more blockchains.

- Extended applications: Smart contracts facilitate the connection between the token economy and real-world applications (robotics, security, IoT, etc.).

- Enhanced security: Tokenization gives users exclusive access to the private keys of their assets.

- Policy enforcement: Tokenization provides a mechanism to enforce policy on the chain, providing transparent regulation while preventing abuse of control, manipulation, illegal activity or misuse of assets by a single party.

Technical standards for token wrap vary, but generally dictate how tokens are transmitted and how users can access data about a specific token. The standard facilitates transaction analysis and specifies the minimum required token data required to exchange tokens or transfer tokens to or from a cryptocurrency-wallet. For example, the Ethereum blockchain supports a variety of technical standards for tokens, the most common being ERC-, which consists of standardized APIs ^[104] used for fungible tokens, including transfer, payment, and balance-tracking functions. It's 20. Ethereum Request for Comments (ERC) refers to a request for information, or data exchange, required to successfully process a pending token transaction.

Fungible DeFi Tokens : The creation of fungible tokens by smart contracts hosted on a permissionless blockchain provides a means for new tokens to be created without the need to mine and wrap existing cryptocurrencies. In this respect, running smart contracts to generate tokens is more ecologically sustainable (greener) than PoW cryptocurrency mining.

During the token creation process, a smart contract is created that specifies the type and quantity of tokens to be issued, and is then executed by uploading the smart contract to the intended host blockchain.

Once a DeFi token is created, it is sold (exchanged) to investors. Tokens purchased simultaneously or in stages are distributed to investors through a process called ‘token release’. DeFi token launches may be executed on behalf of a variety of token sponsors, including:

- Corporation, registered business or DAO

- Project or dApp development

- Trading pool (consortium of traders)

- Artist or content creator

Proceeds from token sales are passed on to sponsors, who have an implicit (or explicit) obligation to provide products or services in return for the investment received. For example, a business has an obligation to provide a product or service; Projects strive to provide working software or dApps, trading pools are obliged to provide a means for people to trade, stake or borrow a specific list of tradable assets, and artists are obliged to provide a means for people to trade, stake or borrow a specific list of tradable assets, and artists rights) must be conveyed to the collector. Issuance of tokens lacking defined deliverables is considered fraud or fraud.

Since tokens are issued through a permissionless blockchain, the cryptocurrency-economy considers token launches as decentralized finance. Token distribution during launch can be carried out by a variety of mechanisms. in other words:

- Through a private sale (and/or SAFT agreement) to a venture capital (VC) fund.

- Via airdrop (a giveaway used for marketing purposes)

- Through exclusive IDO (Initial DEX Offering) of carefully selected decentralized exchanges

- Via private pre-sale to accredited investors (subject to KYC and regulations)

- Via a token generation event (TGE) on one or more DEXs or centralized digital currency exchanges (DCXs)

- Via government approved whitelist via DEX or centralized DCX

In all cases above (except airdrops), token distribution will be limited to professional investors who have passed the rigorous KYC/AML verification typically implemented on decentralized exchanges (DEXs) or centralized digital currency exchanges (DCXs). General partners and investors in venture capital (VC) funds are also considered qualified professional investors. Suspiciously absent from the preceding list is an initial coin offering (ICO), a process similar to an initial public offering (IPO) of stock, in which a company sells tokens directly to the unqualified public.

After a brief but intense ICO period between 2017 and 2019, the court ruled that many ICO token launches represented unauthorized issuances of public securities. Additionally, many issuers were found to have failed to conduct sufficient background checks to positively establish candidates as accredited investors. As expected, token sales to the general public are now considered prohibited in many countries and jurisdictions.

Nonetheless, out of an abundance of caution, many companies issuing tokens are exempt from countries that ban or restrict the sale of digital assets and cryptocurrencies, such as the United States and its territories, Canada, the United Kingdom, and China (including Hong Kong). Limit distribution. Investors should pay attention to the relevant laws of the country of their citizenship and residence.

Finally, it would be remiss not to mention that the act of creating a new token itself does not represent a token creation event. There is no need to release the token at the event where it is first created. In fact, there is no need to deploy them at any time. For example, an engineering project seeking to raise funds through issuing DeFi tokens may change its plans and cancel the issuance for any reason, creating tokens but not distributing them. If so, the smart contract is abandoned and remains on the blockchain permanently, without having to execute a token sale or single transfer.

DeFi Token Standards : To ensure universal interchangeability, fungible DeFi tokens must adhere to consensus standards specific to the blockchain. Two of the most common standards are Ethereum’s ERC-20 standard and Binance’s BEP-20 standard. These standards specify key factors that determine the tokenomics of an issuance. Ethereum's ERC-20 standard specifies six required function calls and three optional function calls for parameters (*). in other words,

- totalSupply(*) Describes the total supply of tokens, i.e. the total circulation volume.

- balanceOf(*) Displays the number of tokens in the owner's wallet.

- transfer(*) Specifies the amount of tokens to be transferred and to which address to send them.

- transferFrom(*) allows a smart contract to automatically transfer a specified amount of tokens from the owner to the recipient.

- Approves withdrawal of a certain amount of tokens from the owner’s wallet through the approve(*) receiving address.

- Allowance(*) Checks whether the owner's wallet contains at least as many verified tokens as specified in the approve(*) command.

- name(*) Optionally, specifies the ID of the token.

- symbol(*) Optionally specifies a 3- or 4-letter abbreviation for the token.

- decimals(*) Optionally specifies the number of digits to the right of the decimal point when expressing an integer as a fixed-digit number, a feature required for fractional units of the token (when the token is valued too high to be unusable) important).

ERC functions provide the information smart contracts need to reliably perform specified tasks (such as transferring assets to a wallet or another smart contract). Although tokens can be transferred directly using the transfer(*) function, sending digital assets manually carries risks. For example, if you send a token to a smart contract that cannot receive tokens, the sent token will be credited to the recipient's address and the transaction will be recorded as "complete", but the recipient's contract will not be able to recognize it, resulting in an irreversible loss. there is.

For illustrative purposes, numerous ERC-20 compatible tokens include Chainlink (LINK), Shiba Inu (SHIB), OmiseGO (OMG), EOS, Tron (TRX), ICON (ICX), Maker (MKR), and Native Attention Token (BAT). ), Ox (ZRX), Quant (QNT), IOT Chain (ITC), Jasmy, etc. Tether, a stablecoin , USDC, Dai, and BUSD are also ERC-20 compatible tokens. Paradoxically, ETH, the cryptocurrency belonging to the Ethereum blockchain, is not like that.

Smart contracts using ERC-20 compatible tokens can reduce the risk of error by invoking specific attestation and compatibility checks before executing a transaction. For example, transfer a token using the approve(*) and transferFrom(*) function calls if defined criteria are met. Nonetheless, ERC-20 compatible tokens are not perfect and are subject to numerous failure modes.

To circumvent these issues, replacement token standards for ERC-20 have been developed, including the backwards-compatible ERC-223, which is designed to prevent funds from being lost during transfer. Other notable options include ERC-721 for non-fungible tokens (NTFs), ERC-809 for competitive NFT rentals, and ERC-1238 for non-transferable tokens or badges. Despite offering enhanced features and benefits, widespread adoption of these alternative token standards remains difficult, and ERC-20 maintains unrivaled hegemony on the Ethereum blockchain.

Similar standards, sometimes with expanded features, exist in other blockchains, such as BEP-20 on Binance Smart Chain, and there are evolving standards in modern blockchain networks. Regardless of the specific blockchain network and the assets traded in smart contract transactions on BCVM, it is important to note that the gas required to fund the validator community executing the smart contract is specific to each blockchain. Therefore, running an EVM smart contract trading ERC-20 tokens requires ETH for gas fees, but running a BSC smart contract trading BEP-20 tokens requires Binance BNB tokens, not ETH for gas.

Features of Tokens : The value and utility of tokens are not simply intended to mimic fungible substitutes for fiat currency. Cryptocurrency can do that. As defined by the token's role, purpose, and characteristics, a token can do things that fiat or cryptocurrency cannot. For example, tokens can hold state information and convey credentials such as genes that grant privileges, rights, benefits, priorities, confidentiality, privacy, or access, despite the absence of direct intervention between the transacting parties. .

Similar to an exclusive golf club membership, tokens can provide unique privileges to their holders by granting access to products, content or services that would not be available without the token. For example, tokens released to members of a celebrity's fan club could provide unique preferred seating to their most loyal followers. Tokens also provide economic incentives to users, who can be used to get discounts on purchases, receive gifts, or upgrade to better hotel rooms.

For example, purchasing online music using tokens may result in receiving bonus songs that are not included in the album. By accumulating tokens, you can get free online streaming services for movies and music. Similar to airline miles, tokens can be used to access unused inventory (e.g. empty business class seats) at a discounted price or for free. However, unlike airline miles, which are managed by the airline or airline group issuing the miles, tokens involve no staff or costs to manage or distribute. In DeFi, there is no central authority issuing tokens or controlling their distribution.

Another unique feature of fungible tokens is that they are indistinguishable. Certain types of tokens, e.g. , USDC, alOT, UNI, YFI, etc.) have the same characteristics as all other tokens with the same symbol, so they are indistinguishable from each other. Crypto wallets containing corporate tokens can track which tokens are from previous purchases, which tokens were later acquired at a higher price, and which tokens were given away for free through promotional distributions (e.g. crypto airdrops). I can't tell if I received it or not. ERC-20 tokens do not have an identification code that defines identity or registers the owner like a stock certificate.

Due to their indistinguishability, tokens do not confer personal ownership or involve identity registration. The tokens used to board trains or buses do not have the names of the passengers written on them. Anyone can use it. As such, tokens offer the convenience of transferability and can be easily exchanged between friends, bartered for favors, or donated for charitable purposes. Indistinguishability has one drawback. It is impossible to determine if a token has been stolen and from whom. For this reason, providing security and privacy of the crypto wallet that stores tokens is paramount to protecting token assets from cyber theft.

Tokens can also have economic value. As with chain-native cryptocurrencies, ERC-20 compatible tokens created by wrapping a cryptocurrency (commonly referred to as WETH) can be used in crypto commerce transactions instead of ETH or BTC. Unlike non-token cryptocurrencies, smart contracts allow tokens to facilitate conditional properties such as lock-in, fixed price, bonus rewards, conditional issuance, etc., which are not possible with pure cryptocurrencies. For example, a BTC airdrop allows its recipients to trade the cryptocurrency immediately, while token airdrops can remain locked for a defined time or until certain conditions are met. Tokens can therefore be used to incentivize action or encourage long-term participation in a pool or business.

Tokens can also grant their holders privileges that facilitate access to products, services or preferences. Acting like a membership pass to participating businesses, token holders can gain access to venues, receive favorable prices or request special privileges reserved for elite token types. Examples include access to a hotel's Presidential Suite, reserving a private box at a sporting event, scheduling a meet-and-greet with an artist after a performance, or requesting an exclusive VIP table reserved at a five-star restaurant. As mentioned earlier, tokens that provide benefits with undefined economic value are referred to as NFT (Non-Fungible Token). The benefits of NFTs (e.g. ownership) are not limited to non-cash transactions. Hybrid tokens can combine NFT features and inherent value.

Another unique feature of tokens compared to cryptocurrencies is recognition. Stupid cryptocurrency trading is unconditional. If a crypto coin is valid, it can be transferred or sold immediately, regardless of economic situation or transaction outcome. In contrast, tokens can request and take into account off-chain conditions when managing transactions. By using blockchain oracles to retrieve on-chain and off-chain event information, smart contracts can dynamically react to changing economic and environmental conditions, such as prices, dates, and quantities, or adapt using artificial intelligence.

For example, a smart contract could limit the use of tokens for services only to defined GPS regions or specific cellular networks, ensuring compliance with local legal ordinances. Smart contracts can automatically prevent or limit swapping (buying or selling) during volatile transactions or price crashes. Contingent value is particularly useful in commerce, especially when implementing stablecoins, which are tokens that maintain a fixed price ratio for a commodity (e.g. gold) or are pegged to a predefined ratio to the value of a specific fiat currency. for example is a token whose commercial price is pegged to the United States Dollar (USD) (within some nominal range).

Transacting DeFi Tokens : Transacting DeFi tokens occurs in three main stages of the token lifecycle. in other words,

- Token generation

- Token Distribution

- Token trading

Creating a new token, or token creation, involves executing a smart contract that defines the type and properties of the released token. The creation of smart contracts is an important element in properly executing arbitrary DeFi issuance because the real-time launch of a smart contract is an irrevocable event and cannot be undone once done. In particular, the terms of a smart contract cannot be changed after the fact, and mistakes cannot be eliminated. The consequences of a poorly written smart contract can range from unnecessarily incurring excessive gas fees for users to causing a complete loss of invested capital. Root causes of failure include arithmetic errors, logic errors, improper function calls, hung program counters (freezes), and incomplete or misdirected transfers.

Essentially, the token issuance and tokenomics of its execution are strictly defined by the smart contract. The number of tokens created, i.e. the total token supply, cannot be increased later. Locked tokens cannot be unlocked unless conditions specified in the smart contract occur, for example according to a defined vesting schedule. Unlocked tokens cannot be locked later, and once defined, the vesting schedule cannot be changed. Therefore, the creation of reliable and error-free smart contracts is fundamental to a successful token launch. Smart contracts represent a specific type of software called a decentralized application, or “dApp.”

Developing dApps : Writing new smart contracts is the role of dApp developers , a team of software programmers familiar with blockchain-based decentralized applications. Programming decentralized applications is significantly different from programming for smartphones, personal computers, cloud servers, web servers, IOT devices, or connected vehicles.

In traditional computing, application programs run on top of an operating system that locally delivers dedicated resources, including hardware that includes one or more computing engines, cache memory, and non-volatile storage. Hardware host resources are owned or leased by the software owner. If a user enters into a service agreement with Amazon or Google Web Services, the right to use the leased hardware for a specific period of time as if the customer had purchased the server, regardless of which servers in the cloud are actually performing the work at any particular time or day. The contract is similar to renting a car in that you own the car.

When a programmer has unrestricted access to dedicated hardware, the problem of the software programs it hosts executing instructions for no purpose and storing data they don't need is simply too small a problem to bother with. , can be very inefficient. Web programmers are notorious for writing inefficient code, especially based on pre-built HTML templates, and compiled programs can become bloated with useless coding contributions from all their predecessors.

One area of engineering where sloppy programming doesn't work is software for real-time communications devices and services. In real-time systems, inefficient code affects system performance. Unnecessary computations reduce the system's ability to transmit data, negatively impacting the network's latency and throughput (e.g., data bandwidth). For example, in professional wireless communication systems, propagation delay not only affects network performance metrics, but can also lead to complete and irreversible loss of packets, payload, and content. Of course, only the best programmers can do real-time programming.

Smart contracts can be written in any number of different computer languages, depending on their intended use and the target blockchain virtual machine host for contract execution. The programming languages used by various blockchain virtual machines and their blockchain users are:

- C++: EOS, HyperLedger Sawtooth, lota, Wanchain, Solana, Stellar

- C#: Neblio, NEO, Straitis

- F#: NEO

- Go: HyperLedger Fabric, lota, Neblio, Stellar

- Java: Ardor, Corda, HyperLedger Fabric & Sawtooth, lota, Neblio, NEO, Smilo, Stellar

- JavaScript: HyperLedger Sawtooth, lota, Lisk, Neblio, Smilo, Stellar

- Python: HyperLedger Sawtooth, Icon, Neblio, NEO, Smilo

- Objective-C: Neblio

Many of the items in the above list include general-purpose, high-level programming languages derived from C or Java. Other commonly used smart contract developments include:

- DAML: HyperLedger Sawtooth

- Kotlin: Corda, NEO

- Lidity: Smilo

- LLL: Ethereum

- Michelson: Tezos

- PhP: Neblio

- Plutus: Cardano

- Ride: Waves

- Ruby: Neblio

- Rust: HyperLedger Sawtooth, lota, Solana

- Scala: Stella

- Scilla: Zilliqa

- Serpent: Ethereum

- Solidity: Aion, Binance, HECO, Enigma, Ethereum, Qtum

- WebAssembly: EOS

- Vyper: Ethereum

- Yul: Ethereum

Among the foregoing, Solidity, a Java-derived language, is the default language used in Ethereum EVM and Binance BSC, and thus holds the largest share of the smart contract programming market. Rust appears to be a fast-growing alternative used by both HyperLedger and Solana. Other blockchains claim to be agnostic to the language used to execute smart contracts. These include Kimodo, Multichain, NEM, OpenChain, and Polkadot networks.

Efficient bug-free dApp development requires extensive experience to circumvent programming pitfalls. Accidental arithmetic errors, fixed integer decimal point placement, hidden loops, undetected wait states, and incomplete transmissions can cause catastrophic losses to investors, affecting the success of the project or the survival of the company. Because there are so many programming languages, cross-chain launches are particularly complex and prone to execution risks. Poorly designed code, even if it is bug-free, can result in excessive gas fees or slow execution during high-traffic events, resulting in lost opportunities for investors.

One way to avoid poorly implemented or buggy smart contracts is to use an autonomous smart contract writing system. However, writing dApps that write bug-free smart contracts requires much greater skills than writing smart contracts manually. There are only a limited number of skilled developers worldwide who can solve these challenges.

Executing dApps : Smart contracts released on the host blockchain are immediately ready for deployment and use. As shown in Figure 4, a function call 39a from Ul 36 or API to protocol 37a descends from the original parent block 37a via instance 37b and Merkel chain 39b, 39c. Retrieves the latest code (37c) instance. When accessed via the user interface (Ul) of a smartphone app or web browser (36), this latest template (including the current world state of the BCVM) is downloaded (39d), and pending transactions (random tokens from the wallet (31)) are downloaded (39d). It is modified to include exchanges 35 and 50a) to create a new instance 37d. The updated contract (39e) is then verified (38) and uploaded back to chain (1) as the smart contract (37e) in block (2) (39f). This recently uploaded instance is then used as a template for the next transaction, and so on.

More specifically, smart contract lineage is traced from its parent to the last entry in the blockchain, i.e. the most recent instance, using a peer-verified Merkel tree (aka Merkel chain). Each instance of a smart contract is sequentially recorded on the blockchain using timestamped and peer-verified blocks. As with chain-native cryptocurrencies, blockchain processing of smart contracts is executed by a jury to verify each new entry.

However, unlike cryptocurrency mining, miners who verify smart contracts verify the authenticity of the block, but not its contents. During the verification process, the jury does not (and often cannot) interpret the meaning or functionality contained in the smart contract. For example, for security and privacy reasons, parts of a smart contract may be hashed or encrypted and cannot be decrypted by any trader except members within a defined pool. To ensure that your contract is properly prepared, it is important to only use the latest version of a smart contract as a starting point for creating a new contract.

The latest instance of a smart contract contains the latest contract information, or parameters, needed to synthesize the correct executable code. Parameters define conditional information that changes depending on the time required to execute the smart contract, including date, time, interest rate, number and type of tokens in the pool, locking mechanism, etc. For example, before a new contract is created and recorded to exchange two tokens, the final smart contract must check whether enough tokens exist to execute the transaction. If a buyer attempts to purchase more tokens than exist in the pool, the contract cannot be executed. the trader If you want to run a smart contract on the Ethereum blockchain using , the trader's wallet must contain enough ETH for the gas fee or the transaction cannot be processed.

Program execution appears in a simple chronological order, but to maximize the network's throughput, smart contracts are organized in hierarchical layers (subroutine calls) to avoid unnecessary consensus verification. Figure 5 shows a hierarchical representation of the blockchain virtual machine stack. As shown, the blockchain sits on top of the Internet's TCP/IP protocol stack (40) as OSI application layer-7, with its own four-layer blockchain stack (41) and separate BCVM sublayers (42a, 42b, and 42c). Includes.

Unlike the Internet's OSI layer, there is currently no standardized nomenclature for blockchain. Regardless of the terminology, the lowest layer of the blockchain stack is the infrastructure or network layer (0), which is used to deliver network (44) and communication services to the blockchain (33). Blockchain layer 0 (network layer 42a) serves blockchain layer 1, the protocol or implementation layer (42b), which provides data (26), block content, and chain-specific cryptocurrency (34a). It manages the mining and storage of and system operations, including the blockchain virtual machine (BCVM) (20) and consensus mechanism (38). The Ethereum Virtual Machine (EVM) and Binance Smart Chain (BSC) are examples of blockchain layer 1 implementations.

Blockchain Layer 1, in turn, provides services to Blockchain Layer 2, which is the transaction or application layer (42c) used by BCVM to execute dApps, smart contracts (37) and token creation (50b), providing scalability; Otherwise, it removes operations that would otherwise consume system bandwidth from blockchain layer 1 bandwidth. Layer 2 implementations may include lightweight computing functions called “state channels” that do not require the same verification frequency as blockchain layer 1 processes. In this respect, blockchain layer 2 is faster but less secure than layer 1. It is important to note that the term "application layer" for Layer 2 in the blockchain stack is not the same as Layer 7 of the Internet's TCP/IP communications protocol (the Internet supports all blockchain processing). Blockchain layer 2, which relies on layer 1, likewise provides services to blockchain layer 3, the so-called aggregate layer. The purpose of the aggregation layer is to bundle Layer 2 applications and services for the convenience of users. For example, for customer convenience, staking (lending) and borrowing could be bundled into an integrated service that shares a single DeFi pool, even though they represent different applications.

In particular, processing tasks in a single blockchain layer or distributing them across multiple layers impacts performance, efficiency, and security. This compromise was proposed by Vitalik Buterin, the founder of Ethereum, in recognition of developers' concerns that implementing blockchain processing with fewer verification checks would improve speed, but inevitably compromise decentralization and security, and called it "blockchain." This led to the coining of the phrase "trilemma", and considers whether the network hosting smart contracts has the following characteristics:

- Decentralization: Creates a blockchain system that uses a central control point

- Scalability: the ability of a blockchain system to support large volumes of transactions

- Security: The ability of a blockchain system to maintain stable operation by defending itself from attacks, bugs, and other unexpected problems.

In this regard, blockchain architecture, virtual machine implementation, and smart contract programming across multiple blockchain layers determine the performance, security, and reliability of any blockchain-implemented smart contract. Therefore, consistent, high-quality smart contract programming is necessary to prevent hacking and failures in decentralized financial transactions.

DeFi Pools : As illustrated in Figure 6, hierarchical resources form an essential component of decentralized financial transactions in the cryptocurrency economy. Based on the application layer of TCI P/IP, the Internet provides a network (44) for hosting permissionless blockchains (33) that run permanently, even without dedicated memory available for non-volatile storage. The blockchain then acts as a host platform for the Blockchain Virtual Machine (BCVM) (45), which has high uptime despite the lack of dedicated computing resources. The blockchain virtual machine forms a host platform for the execution of decentralized applications, including dApps and smart contracts (36), which enable financial transactions and transactions despite the absence of any central authority, bank, treasury, or centralized financial clearinghouse. It is a transaction process that can confidently support commercial work.

In one class of smart contracts used to release tokens (called a token release), DeFi tokens (50) are created and released into the wild according to some defined schedule or set of conditions. Investors can obtain tokens by purchasing them directly from the issuer or by executing a token swap in a DeFi pool. In conjunction with today's token launch, the "DeFi Pool" (46) is a smart contract that facilitates the exchange of two digital assets: newly created DeFi tokens and crypto cash equivalents (USDC, BUSD, WETH, etc.).

Unlike DeFi trading pools (where you can buy or sell one of the assets in the pool at will), newly released tokens can only be purchased and not sold during a token launch. These DeFi pools may be called Launch Pads or Issuing Pools. There are two ways for investors to acquire newly released tokens in private token presales: through direct purchase or through DeFi pools. If purchasing directly after completing KYC/AML and complying with applicable regulatory laws, the buyer purchases directly from the issuer. In DeFi, potential investors open an autonomous trading interface called a protocol and exchange a specified amount of cryptocurrency for issued tokens. In high-quality token issuance, demand usually exceeds supply.

Therefore, the maximum purchase quantity is inevitably limited. In other words, it is allocated per person. Transactional DeFi pools are bankless with “products” that provide liquidity that provides opportunities for venture capitalists to launch new launches, lend to borrowers, borrow against borrowers, exchange currencies (token exchanges) for traders, and create opportunities for market makers. It functions like a bank. DeFi pools provide services very similar to businesses, but the pools themselves are heavenly entities. There is no owner, operator, guarantor or legal entity that controls its actions or defines its nature. In this regard, the operation of DeFi pools is autonomous, and their existence is virtual. DeFi is decentralized in nature, with no physical presence within a single device, server, location, country, or legal address. If something happens, there is no one to sue and no one to blame but yourself.

In our experience, users interact with DeFi pools using what appears to be a web interface. In fact, the DeFi User Interface (Ul) calls an application program that directly connects a crypto wallet to Ethereum, Binance, or other host blockchains. For security and privacy reasons, the web interface should not serve as a data conduit for any crypto transaction. Web intermediaries cannot be trusted as they can easily capture, steal, and profit from access to customers' security credentials and private keys exchanged during transactions, including the risk of wallet theft. Decentralized trading therefore relies on trustless, autonomous operations without relying on anything or anyone to execute transactions. In theory, traders can write their own smart contracts to engage in trading within a DeFi pool, but in reality, smart contracts are not written from scratch, but are instead based on contract templates called protocols that define the details of the pool.

DeFi Protocols : Smart contracts play two key roles in supporting investors and entrepreneurs in today’s rapidly developing cryptocurrency economy.

- Facilitating DeFi token trading for investors

- Facilitating the launch of DeFi tokens for issuers

Both of these functions can be performed using hard-coded smart contracts, but custom dApp development is slow and error-prone. An alternative is to use transaction protocols to create smart contracts. A transaction protocol, or simply a protocol, refers to software that autonomously creates smart contracts based on user instructions. In theory, a smart contract writing program for DeFi transactions should be able to support a variety of common DeFi transactions. In practice, most of the available protocols are designed to operate as single-function automata that can perform only a single dedicated task, such as:

- Exchange tokens in a DeFi pool for a single type of cryptocurrency, or

- Lending tokens from DeFi pools to earn interest, or

- Borrow from DeFi pools against locked collateral, or

- Provides liquidity to DeFi pools as capital invested to earn fees.

Separating investment and trading activities into separate protocols, while easier for developers, creates a more confusing user interface and worsens the user experience. Moreover, numerous inadequacies in the design and programming of current DeFi protocols negatively impact the flexibility of traders participating in DeFi pools. This inadequacy has a particularly significant impact on companies or projects looking to launch their own tokens. Key unresolved issues limiting today's protocols include:

- Cannot accept multi-currency payments (multiple crypto wraps and stablecoins)

- Unable to control early sales and prevent rug pulls through lock and vesting management

- Multiple investor tranches with different attribution schedules cannot be released simultaneously.

- Exchange (capital investment) combined with loan (profit) is not supported

- Inability to flexibly support new token launches

- Cannot support transactions and launches on multiple networks simultaneously

Multi-currency Payments : Ideally, investors using the protocol to acquire tokens or participate in new issuances would want to make payments in whatever form of crypto cash-equivalent token is convenient for them. However, in reality, as shown in Figure 7, each exchange pool 46a-46d contains a single token-pair containing a unique combination of one specific DeFi token and a specific cryptocurrency or crypto cash equivalent. For example, if a business wants to support the sale of virtual PRYS tokens (50c) by settling major cryptocurrencies such as WETH, USDT, BUSD, and USDC, it will create four separate tokens, each requiring its own smart counterpart contract (37f, 37g, 37h, 37i). Requires pools 46a, 46b, 46c and 46d. The ability of a programmer 52 to create four separate instances of a smart contract without error is difficult and risky.

In a situation where all launch pools are separate, the token purchase process is inconvenient for investors (30), and even if the investor purchases only one token (50c), payment through WETH involves transaction (53a), and payment through USDT involves transaction (53a). It involves a separate transaction 53b, and payment via USDC involves a transaction 53c, and every transaction has its own gas fee. A real-world use case would require changing the DeFi pool to purchase a token like Jasmy with USDC instead of WETH. Likewise SHIB- Token pairs cannot be mixed with the SHIB-BUSD pair, and SUSHI-WBTC pairs cannot be mixed with the SUSHI-DAI pair. Besides being extremely inconvenient for investors trying to acquire tokens from a mix of cryptocurrencies and stablecoins, strict single-token-pair DeFi pools force issuers to allocate tokens to inactive or unpopular pools and tokens.

Multi-chain Token Trading : Most protocols are designed to operate on a single blockchain and cannot support multiple networks, let alone cross-chain transactions. For example, token issuance on Ethereum uses EVM-specific smart contracts that are not available on Binance's network or the BSC virtual machine. This forces investors to trade exclusively on a single network, even if that means worsening trading times or prohibitively high gas fees.

Beneficially, multi-chain support, shown in Figure 8, allows investors to optimize their trading and minimize gas fees and transaction costs. Unfortunately, most protocols cannot fully support cross-chain transactions or multi-chain token launches. Few developers today have the skills or insight to write dApp protocols for multi-chain transactions or launch. Instead, the programmer (52a) launches a smart contract (37j) on the Ethereum main chain (33a) (54a). Consecutive transactions (multi-swap) involving smart contracts (37k, 371, 37m and 37n) are expensive on Ethereum due to high gas costs. Programmers (52b) who launch (54b) smart contracts (37o) on the Binance Smart Chain (33b) can support low-cost multi-swap transactions (37p, 37q), but lose all interoperability with Ethereum. The Polkadot blockchain (33c) offers low-cost exchanges through smart contracts (37r and 37s), while its programmers (52c) launch smart contracts (37r) that are completely independent of Binance (54c), and Ethereum (54c) Creates compatibility risks.

Another missing feature is the ability to intelligently minimize gas and transaction fees by using a minimum trade algorithm in multi-swap transactions.

Unlocked Tokens : The main problem plaguing DeFi investments today is the problem of early selling and insider rug-pulls. The early selling problem is inherent in poorly executed or corrupt token launches by companies (51) and early investors (e.g. VCs, exchanges, seed investors and developers) (55) who receive preferential pricing, as shown in Figure 9. Unlocked tokens (50z) can be purchased at a significant discount compared to the expected future market price of the above-mentioned issuance. With purchase or pre-sale tokens (50d) at a discount compared to IDOs, TGE and exchange sales (50e and 50f), only a few buyers are willing to sell their tokens (50z) at a lower price, hitting the market before others join. can ruin it. Likewise, all DEXs hosting scheduled listings use bulk pricing contracts to acquire inventory of tokens at preferential prices. Later, when a decentralized exchange releases tokens for sale to customers and makes them tradable, for example during an initial DEX issuance (IDO), pre-sale token holders secretly execute a series of unauthorized sales that the DEX cannot detect, Prices may collapse.

The problem with unauthorized selling is that there is no way to distinguish between tokens approved for sale and tokens traded legally. Indistinguishability is a fundamental characteristic of fungible currencies. This means that once a token is unlocked, there is no way to restrict its transactions. Therefore, lug-pull is an inevitable result of issuing unlocked tokens at the time the unlocked tokens were first created. One alternative means by which issuers can prevent early sales by pre-sale token holders is to withhold the release of tokens to buyers until a later date, through a distribution delay. Although this option is effective, it is problematic in that few investors will agree to purchase the token without any collateral protecting the invested capital until the transaction is completed.

One particularly problematic exploit is the pump and dump (P&D) exploit shown in Figure 10. Here, investors accumulate large quantities of tradable tokens (60c) through pre-sales and small purchases at low prices (65a), and then make deceptive purchases in small quantities (65b) to artificially inflate the market capitalization of the issue (64). 60l). After driving up the price (65c) to attract momentum traders to become buyers, investors sold heavily in several transactions (61a, 61b and 61c), resulting in a selling storm (65d) that pushed the remaining token price (62) to an all-time low. makes it reach

NFT Specific Issues : Fungible tokens based on the ERC-20 and BEP-20 standards share many features, benefits, and flaws with NFTs based on the ubiquitous ERC-721 standard, but have one key difference . The point is that most decentralized finance involves transactions on multiple chains but does not include cross-chain transactions. Once USDT tokens are created for the BSC network, they are not transferred for use on the EVM network, but are instead first converted on the exchange. In contrast, the NFT market is driven by interest groups (e.g. antique cars, comic books, sports, art, music, etc.). For whatever reason, these groups are often transacted by communities living on different blockchains.

For example, most NFTs are first released on Ethereum and then transferred to one or more other networks for marketing and community sales. In this sense, NFTs are not simply multi-chain assets, but operate as a way of trading across multiple networks. In other words, NFTs involve cross-chain transactions. To achieve this feat, NFTs use wrapping (the same technology used to tokenize chain-native cryptocurrencies such as ETH) to make them compatible with the target blockchain. An example of this process is shown in Figure 10a, where NFTs are traded on three blockchains: EVM (33a), BSC (33b), and Polygon blockchain (33c).

As shown, the original instance of NFT 88f created in EVM 33a was transferred to the BSC 33b network and became 88g. This is because the potential buyer was already trading on the Binance network. To transfer an NFT from the Ethereum network to BSC, you must first wrap the NFT (88f) to follow the protocol and code structure specific to the BSC smart chain. In other words, Ethereum-based NFTs are disguised as Binance tokens by wrapping so that they can operate on the BSC (33b). After sale, the ownership of the NFT changes, creating a new BSC token (88h). The process of wrapping and transferring NFTs from one blockchain to another is called bridging.

However, later, when the owner wants to sell the same token to another buyer on the EVM (33a), rather than reverting it to the original format of the token, it is wrapped in an Ethereum wrapper to create a BSC-compatible NFT (88i) containing the wrap. By wrapping token 88h with , the token is brokered to be compatible with EVM 33a. After selling the token to another Ethereum buyer, the new EVM token (88j) is rewrapped and brokered to the Polygon network (33c) as an NFT (88k), then sold to the new owner as 88l, and rewrapped as a token (88m). and is brokered to other EVM buyers. Thus, the tokens (88m) include wraps of wraps of wraps of wraps of EVM-based NFT tokens, wraps of wraps of polygon wraps of polygon wraps of BSC wraps of EVM-based NFT tokens. This is not a problem for traders who are not interested in accessing the actual content of the NFT, but for collectors this situation becomes very problematic when unwrapping is required.

Specifically, unwrapping the overlapping NFT as shown in Figure 10b involves the NFT 88e being unwrapped by the bridge 37v to reveal a Polygon (XYZ) token 88d by paying ETH as gas. can do. The NFT 88d is then unwrapped by the smart contract 37u by paying MATIC with gas to reveal an EVM token 88c, which in turn unwraps the smart contract 37t to reveal a BSC-based NFT token 88b. Gas is required for this, which can ultimately be unwrapped for BSC gas via contract 37s to extract the original EVM belonging NFT token 88a and access the metadata core 87. This means that the buyer bears the full cost of unwrapping, and in many cases they do not know how much the process will cost or how many layers of packaging will be embedded.

background summary

Given the limited choice and inherent flaws of today’s DeFi protocols, we must acknowledge the following:

- Today's DeFi protocols are not built for token launches, but for dedicated token trading in DeFi pools and DEXs.

- Even the best DeFi protocols lack the functionality and features needed to support and manage a properly executed token launch.

- Current DeFi protocols prevent unauthorized selling or blocking IDO and TGE stage investors from rug pulls, pump-and-dumps and trun-running by unscrupulous individuals and pre-sale holders. -running)[143][144] There is no mechanism to protect against liquidation of one's position through abuse.

- Standard protocols that allow only designated token-pairs to be exchanged limit potential investors to specific DeFi pools, cryptocurrencies, and blockchains, reducing the attractiveness and availability of new issuance.

- Most protocols operate on a single blockchain. Unproven protocols attempting cross-chain functionality suffer from bugs, waiting states, completion risks, and security vulnerabilities.

- DeFi protocols rely on insecure crypto wallets with unreliable identity verification mechanisms (two-party authentication is inadequate).

- No DeFi launch platform anticipates the lifecycle management needs of token issuance.

- NFT bridging is a costly and deceptive practice of selling assets that involve hidden costs.

What is needed are new DeFi platforms and protocols developed specifically to meet the needs and alleviate the concerns of projects, DAOs, and companies launching their own tokens, and better ways to issue and trade tokens, especially NFTs.

(Summary of invention)

A fully autonomous smart contract creation system is disclosed that can simultaneously create multiple smart contracts from a single source file for multiple blockchain networks, eliminating the risk of random programming errors and transaction losses. In one embodiment, an autonomous generator of decentralized applications uses network protocols and token standard libraries validated by third-party experts to eliminate system errors during smart contract creation. The self-creating program includes smart contracts to launch new tokens and create various DeFi pools, each with its own price and vesting conditions, along with a companion dApp for trading, a UIUX interface, and an automatic market maker to maximize pool liquidity. Includes a decentralized oracle for real-time data needed to support rational trading practices.

In other embodiments, the autonomous smart contract writing program can support transactions and rewards using multiple cryptocurrency wraps, such as WETH, and multiple stablecoins, such as USDT and BUSD. creates . Additionally, the disclosed AMM can support balancing of all assets included in any multi-crypto trading pool.

In another embodiment, the autonomous software creates a pool containing the tokens to be released and collateralized exchange (kTx) tokens that serve as their proxies, whereby the kTx tokens distributed to investors are generated from the token generation event (TGE). It is collateralized with the same amount or value as the corporate token. kTx tokens can be used for redemption and as proof of purchase to claim the released corporate tokens according to a defined smart contract according to an automatically executed vesting schedule. In another embodiment, the vesting schedule, price per token, and total supply of the released tokens are arranged in separate tranches as defined by the token issuer.

In other embodiments, kTx tokens may be collateralized before the underlying collateral assets are vested and unlocked through merged swapping and staking, swapping and staking, or the Collateralized Token Exchange (KDEX) as a derivatives market.

In another embodiment, an autonomous smart contract creation program can generate fungible and non-fungible tokens, i.e. FTs and NFTs, based on its input files and metadata.

In another embodiment, dApps can move NFTs cross-chain without the need for nested wrapping or hidden costs, enabling a fast and cost-effective means for cross-chain transactions.

Figure 1 illustrates a blockchain hash chain and Merkel tree used to verify new blocks.
Figure 2 illustrates a blockchain virtual machine implementation in Ethereum.
Figure 3 illustrates the process of wrapping the ETH cryptocurrency to create WETH tokens.
Figure 4 illustrates the process of calling a smart contract, modifying it, and registering the changes as a verified block.
Figure 5 illustrates the relationship between blockchain layers and sublayers for the OSI network (TCP/IP) communication network stack.
Figure 6 hierarchically illustrates the resources required to execute smart contracts, create crypto tokens, and host a DeFi pool.
Figure 7 illustrates that separate smart contracts must be used to release tokens on different blockchain networks.
Figure 8 illustrates multi-chain token trading.
Figure 9a illustrates the process by which a company issues tokens to investors and the risk of unauthorized sales.
Figure 9b illustrates token trading using pump-and-dump.
Figure 10a illustrates the NFT bridging process.
Figure 10b illustrates the problem of overlapped NFTs arising from repeated bridging.
Figure 11 compares autonomous smart contract writing with hand-coded programming.
Figure 12 illustrates LaunchBot's role in token creation and distribution.
13 illustrates various decentralized applications including the launched Launchpad ecosystem for DeFi.
Figure 14 illustrates how to autonomously create and execute multiple smart contracts simultaneously on separate blockchain networks.
Figure 15 illustrates simultaneous token release on multiple blockchains with different token vesting and prices.
Figure 16 illustrates the role of a decentralized oracle in asset spot price evaluation during trading.
Figure 17 illustrates autonomous smart contract creation executed by the LaunchBot dApp against a multi-crypto DeFi pool.
Figure 18 illustrates an autonomous smart contract executed by the SwapBot dApp for transactions in a multi-crypto DeFi pool.
19 illustrates an example user interface (U1) for SwapBot autonomous token trading.
Figure 20A illustrates the initial steps required to procure tokens through the SwapBot interface.
Figure 20b illustrates the final steps required to procure tokens through the SwapBot interface.
Figure 21 provides an example comparing the operation of the token release pool and the operation of the token transaction pool.
Figure 22 illustrates the role of a decentralized oracle in maintaining DeFi pool liquidity through the Automatic Market Maker (AMM) dApp.
Figure 23 illustrates AMM operation instructions in a multi-crypto DeFi pool.
Figure 24 illustrates the process of issuing unlocked tokens in TGE.
Figure 25 illustrates an example mix of tokens released in a Token Generation Event (TGE).
Figure 26 illustrates locked, vested and unlocked token distribution for various sales channels.
Figure 27 illustrates example tokenomics of token issuance.
Figure 28 shows LaunchBot token distribution using push attribution airdrop.
Figure 29 illustrates the creation of a collateralized transaction token (kTx) DeFi pool.
Figure 30 illustrates the implementation of a kTx swap pool and token distribution therefrom.
Figure 31 illustrates that a token release pool can be mimicked with parts including a collateralized kTx pool and a kTx swap pool.
Figure 32 illustrates kTx token distribution through various channels.
Figure 33 illustrates the process of issuing kTx tokens in TGE.
Figure 34 illustrates a comparison between an unlocked token launch and a launch containing collateral locked (kTx) tokens.
Figure 35 illustrates the various stages in the distribution of a kTx pool, including initiation (launch), kTx sale, and kTx redemption.
Figure 36 shows three asset representations at various stages of kTx pool deployment, including origination (launch), kTx sale, and kTx redemption.
Figure 37 illustrates an example step-by-step token vesting followed by kTx redemption.
Figure 38 illustrates a multi-asset representation of a multi-crypto pool with kTx tokens.
Figure 39 illustrates the use of kTx tokens in equity investment after swap.
Figure 40 illustrates the use of kTx tokens in swaps and equity investments.
Figure 41 illustrates kTx derivatives trading including exchange or staking.
Figure 42 illustrates the autonomous creation and distribution of an NFT portfolio.
Figure 43 illustrates the disclosed NFT instantaneous movement method.

This disclosure describes innovative advances in reliable processing of blockchain-hosted data and decentralized applications (dApps) and applications such as:

- Autonomous smart contract writing ecosystem

- Creating and transacting multi-chain smart contracts

- Multi-currency DeFi pool trading

- Decentralized data oracle for rational asset trading

- Collateral transaction (proxy) token launch and vesting

- Cross-chain teleportation of digital assets

Autonomous Smart Contract Authoring Ecosphere : As previously explained, the rapid growth of decentralized finance (DeFi), the creation and distribution of fungible and non-fungible tokens, and the growth of trading, investing, asset exchange, and lending ( The launch of autonomous permissionless DeFi pools for staking, borrowing and liquidity provision (market making), the creation of decentralized applications (dApps) to process digital crypto assets using smart contracts running on blockchain virtual machines. and launches, sparking the emergence of a burgeoning industry.

As shown in Figure 11, many smart contracts 69 are created by manual coding of software by a software programmer 68. This trend has resulted in a variety of problems resulting in the theft or loss of billions of dollars in assets and invested capital. In some cases, these unfortunate outcomes are due to ignorance or carelessness; in other cases, they are due to intentional illegal or criminal activities or susceptibility to vulnerabilities, hacking, or market manipulation. Beyond simple crypto key and wallet theft, causes of smart contract failure include:

- Many programmers are unfamiliar with the software used to implement decentralized applications and smart contracts (e.g. Solidity).

- Many programmers have no experience writing program code to run on BCVM (Blockchain Virtual Machine). Unlike today's high-performance laptops, desktops, and smartphones, the cloud of network nodes is limited by low-performance connected devices to ensure decentralization. Therefore, the performance of BCTM is limited to extremely low throughputs of hundreds of thousands of instructions per second, the computing speed of the 1960s. Complex programs can cause extremely slow responses, infinite waiting states, infinite loops, or crashes in the middle of a transaction, resulting in irreversible loss of the assets involved in the transaction.

- Most programmers are familiar with floating point math and are not familiar with the fixed integer calculations required by dApp software.

- Widely used token protocols such as ERC-20 have commands such as “transfer”, as these commands have the potential to fail to detect incomplete transfers and irreversibly transfer the asset into thin air. "No longer recommended".

- Hand-coded programs are subject to random, undetectable errors that can cause excessive malfunctions or more serious errors. The cost of using a third party to certify the integrity of any hand-coded program is prohibitive.

- Each smart contract has unique vulnerabilities that are unique to the blockchain on which it is launched and the token-pair it transacts with. Launching new tokens that can be traded against multiple currencies requires a new smart contract for each token pair. For example, to launch a virtual company 'PRYS' that can be exchanged for Ether and four common stablecoins, smart contracts for each of five networks are required. That is, one for each token pair (ETH-PRYS, USDT-PRYS, USDC-PRYS, BUSD-PRYS and DAI-USD). When a token is released on three chains, the number of hand-coded smart contracts triples, each subject to its own random errors.

- Criminals and rogue programmers can build back doors for hacking and insert inherent vulnerabilities for various “legitimate” exploits, such as front-running (the trading version of line jumping in an exchange’s real-time order book). .

An obvious solution to the above problem would be to generate software automatically, but no such standardized program generation code exists. Especially since each blockchain has a unique purpose: to attract the majority of clients to its platform and discourage its use on other networks. For example, Binance, the company that hosts the Binance SmartChain virtual machine that uses its proprietary BEP-20 token standard, is not interested in making it easy for customers to use networks provided by Polygon, Solana, or Cardano. .

Accordingly, this patent application describes a pioneering autonomous smart contract writing program for launching new dApps and tokens, referred to herein as the LaunchBot writing program. As illustrated in Figure 12, LaunchBot 71 automatically and autonomously converts the input file 70 into a smart contract 72. Here, the smart contract 72 is a blockchain-specific decentralized application. In other words, the LaunchBot (71) writing program generates the smart contract (72) computer code according to the input file (70) to generate the token (73) and distributes the newly released token (73) to the market (90). Create a method for To this end, the launch of a token that allows a certain amount (76) of fungible tokens to be exchanged for another token (75a) containing a stablecoin (e.g. USDT, USDC, etc.) or a wrap of a cryptocurrency (e.g. WETH). Create a pool (74).

In order to perform error-free blockchain smart contract creation, LaunchBot 71 must know the details of the issuance (the tokenomics of the issuance specified in the input file 70) and the unique requirements of the blockchain network on which the token will be used for transactions. do. Network-specific requirements, including the software languages used (Solidity, Vyper, Simplicity, Varna, Obsidian, etc.) and the various fungible token standards (ERC-20, BEP-20, etc.) or non-fungible token standards (ERC-721) It is precisely specified in the network protocol library (83). With respect to a specific blockchain protocol, each executable smart contract 72 can also be called a protocol because it embeds commands and code that are translated by a specific blockchain virtual machine (BCVM).

The LaunchBot (71) program can create smart contracts from input files (70) created according to the network protocol library (83), but to execute autonomously created smart contracts (72) additional decentralized applications are required to support its operation. Interaction with is required. These utilities cannot perform transactions on their own, but collect important information during smart contract operation and provide it to the smart contract 72. As shown in Figure 13, the utilities include:

- Intuitive user interface: designed to provide traders with immediate feedback (good user experience) in response to data entry (e.g., once a purchase code is entered, the number of tokens to purchase is immediately recalculated). Because blockchain transactions are irreversible, UIUX (82a) is important to prevent accidental or unintended transactions or financial losses due to operator error. UIUX 82a is interoperable with the smart contract 72 as its interface. UIUX 82a can be embedded within smart contract 72, or alternatively can operate independently as a decentralized application and have a secure application processor interface (API) for all instances of smart contract 72 on any blockchain. You can.

- Decentralized Oracle (82b): Collects on-chain and market data and prices from centralized exchanges (CEX) and decentralized exchanges (DEX) and transmits the information to UIUX (82a) for display. Calculate exchange rates when trading one token for another, or evaluate volatile wrapped cryptocurrencies at market spot prices. Since multiple instances of a smart contract 72 may be released on different blockchain networks, the oracle 82b must support multi-chain monitoring along with cross-chain interoperability.

- Automated Market Maker Decentralized Application (AMM(82c)): In particular, in the unique multi-crypto trading pool with multi-chain interoperability disclosed herein, dynamically equalizes the value of assets within the pool to maximize liquidity and external arbitrage. It is used by liquidity providers who invest in DeFi pools to protect against losses.

- Trading bot decentralized application (SwapBot (99)): used to interface UIUX (82a) to any and all instances of smart contracts (72) hosted on various blockchain networks.

As disclosed herein, an interoperable module including LaunchBot (71) authoring dApp, Protocol Library (83), UIUX dApp (82a), Oracle (82b) dApp, AMM (82c) dApp, and SwapBot (99) trading dApp. The combination of an integrated set of decentralized applications enables Launchpad Ecosphere (80), a batch solution for token launch, token trading, blockchain processing, and token life management (including vesting, distribution, staking, etc.).

The multi-chain token launch process using the disclosed Launchpad Ecosphere 80 is illustrated in the flow chart of Figure 14. As shown, using Launchpad Ecosphere 80, Enterprise 50 defines the tokenomics 70 of expected issuance. In response, Launchpad Ecosphere (80) transmits the conditions of tokenomics (70) to the LaunchBot (71) writing program. This program, when combined with the necessary details of the blockchain network contained in the protocol library (83), autonomously and simultaneously generates several blockchain-specific smart contracts (72a, 72b and 72c), each of which has three BCVMs; In other words, it represents executable dApp code for Binance Smart Chain (BSC), Ethereum Virtual Machine (EVM), and Solana's Ouroborus. As part of a suite of interoperable tools, smart contracts (72a, 72b, and 72c) created by Launchpad Ecosphere (80) can be used to create APIs, function calls, or contracts for a variety of applications, including UIUX (82a), Oracle (82b), and AMM (82c). Includes other links to dApp functionality (82).

In relation to clients of autonomously generated smart contracts, the term enterprise 50 is, for example, according to the Cambridge Dictionary, "an organization (in particular a business) (comprising quite a number of people or groups of people pursuing a common goal) It is used as a broad definition to include "any difficult or important plan (especially a money-making plan)." In that respect, the list of companies looking to offer both fungible tokens and NFTs today includes corporations, institutions, sports teams and franchises, VC-funded projects, consortia, blockchain commerce infrastructure, investment and real estate portfolios, and DeFi pools as liquidity providers and market makers. This includes all investor groups willing to support, universities, grants, real estate and home offices, portfolio and fund managers, financial service providers, cryptocurrency-backed credit card companies, and more, and the number continues to grow.

Unlike traditional business commerce, token issuers can include projects and DeFi pools without legal status, registration, or physical address, such as decentralized autonomous organizations (DAOs). music and video artist; painters, sculptors, and graphic artists; curated art galleries and auctions; Other art-business crossover industries such as architecture and interior design, online and play-to-earn (P2E) gaming, and sports and sports betting are uniquely suited because they involve the issuance of a mix of fungible token offerings and NFT collectibles.

Fungible - Another market for NFT-linked issuance is not for interest income, but for granting privileged access to upcoming VIP exclusive events and issuances, such as first-come-first-served auctions, concert seating, fan meets, exhibition access, upgrades, etc. Includes the use of fungible (ERC-20) token staking (locked deposits). Other developing applications for NFT launches include proof of authenticity, which is important in the art and collectibles market for paintings, luxury watches, baseball cards, vintage comic books, rare tickets, and books.

Tokenomics 70 can be applied to both fungible and NFT issuance. The tokenomics term sheet for fungible token issuance includes: total token issuance volume; A blockchain network that hosts the token; Attribution mechanisms such as push attribution or proxy kTx redemption (described later); vesting schedule and price per token by tranche; Payment methods, including options for multi-crypto pools (i.e. which cryptos can be exchanged on a particular network); Tradeable vs locked tokens in TGE; And includes IDO, DEX, CEX and DeFi pools supported by the issuance. In contrast, the issuance of non-fungible tokens (NFTs) created by Launchpad Ecosphere (80) includes owner and royalty considerations (which will be built into the released ERC-721 tokens), attribution, and supported marketplaces. Regardless of whether the issuance is a fungible token, a non-fungible token, or a combination thereof, the tokenomics model defined by Tokenomics 70 along with the blockchain selected for the issuance determines the smart contract that is created.

The interdependence of multi-chain corporate token issuance created by LaunchBot (71) is based on Tokennomics (70) and token protocols from applicable blockchain and protocol libraries (83). As can be seen in the example in Figure 15, the two smart contracts (72a and 72b) created autonomously based on input data to LaunchBot (71) are not symmetric and differ slightly depending on the target blockchain. For example, the smart contract 72a created for the Binance BSC network (and the BSC virtual machine) uses only BEP-20 tokens, which are distributed in limited quantities, with a price of $0.03 per token and a 6-month lump sum vesting. Through initial decentralized exchange (IDO) issuance (94c) with monthly vesting (4.2% unlocked per token) for 24 months after cliff vesting, and with a price of $0.04 per token and no locking (i.e. immediately) This was achieved through the issuance (94d) of a tradable) token generation event (TGE). The execution of the BSC smart contract (72a) can only accept payments (pmnt) (92a) using Binance BNB and BEP-20 USDT cryptocurrencies.

The same issuance created by LaunchBot (71) via a smart contract (72b) created for the Ethereum network (and the EVM virtual machine) can be divided into Seed Tranche (93a) and Strategic Tranche (93b). , uses ERC-20 tokens distributed through multiple channels, including IDO (93c) and TGE (93d), where the price per token (PPT) is $0.01, $0,025, $0,03, and $0.04, respectively. The Seed, Strategic and IDO tranches share a common 6-month vesting, but the Seed Tranche (93a) has a 36-month vesting (2.8% per month), while the Strategic and IDO tranches (93b and 93c) each have a higher sale price. As compensation, a more desirable 24-month vesting schedule (4.2% per month) is provided. Tokens provided by the smart contract (72b) in the EVM for publicly issued TGE (93d) are immediately unlocked without any vesting schedule. Unlike BSC smart contracts (72a), EVM smart contract execution can accept payments (pmnt) (92b) using a wide range of ERC-20 tokens, including (for example) WETH (Ether wrap), USDT, BUSD, and USDC. there is. The token list is illustrative only and is not intended to be limiting.

Another feature of Launchpad Ecosphere (80) is the important role of Oracle (82b). As can be seen in Figure 16, for any transaction involving the exchange of a digital asset with a fluctuating market price, the value of that asset must be ascertained using the “spot” value of the market at the time of the transaction. The role of the Oracle (82b) is to determine the real-time value of assets on centralized exchanges and other marketplaces (84) and verify the most recent transactions, i.e. on-chain transactions (33) registered on the token's host blockchain. . The current price of a volatile asset (e.g., cryptocurrency wrap 34a) is exchanged between the investor wallet 31 and the smart contract 72 according to the instructions of the investor 30 entered through UIUX 82a. Determine the exchange rate for token 73.

Many - Crypto DeFi Pools (Multi-crypto DeFi Pools) : In traditional token issuance, rewards for acquiring token assets during exchange are facilitated through multiple DeFi pools containing separate token-pairs, one for each payment form. The practice of segmenting swap pools for new token launches into separate smart contracts is unwise and restrictive as it reduces trading liquidity and significantly complicates the trading process, adversely affecting the user experience of traders. Even if a trader chooses a DeFi pool with a rich supply of corporate tokens, if they pay with the wrong type of crypto, they will not be able to complete the transaction.

The solution to this challenge is a unique feature described herein as multi-crypto DeFi pools. A pool, as shown in Figure 17, is a heterogeneous complement of exchangeable assets (hereinafter referred to as Includes a pool (74z) containing (referred to as “crypto” in). As more tokens (73) are sold in the launch pool, the total value of the remaining tokens (76) will likely decrease, even if the price per token increases. Conversely, the value of overall crypto assets increases. The creation of a multi-crypto pool is embedded in a smart contract 72 as a dApp created by LaunchBot 71 based on inputs 70 that define the tokenomics of the offering. Once the launch pool is depleted of newly released corporate tokens, liquidity providers typically either sell assets with a larger value (Crypto z), purchase more assets with a lower cumulative value (Token (73)), or Or both, capital can be injected to balance the crypto value and the token value.

The balanced pool 74a in Figure 18 shows that the value of the crypto is equal to the market transaction value 76 of the corporate token 73. here

Regarding the stablecoin consisting of the cryptocurrency WETH with a value of (34a), USDT with a value of (75a), BUSD with a value of (75b), USDC with a value of (75c), and Dai with a value of (75d),

Value(PRYS) = (# of PRYS)·PPT(PRYS)

Value (Cryptocurrency) = (# of WETH)·PPT(ETH) + $1·(# of USDT + # of USDC + # of BUSD + # of Dai)

PPT(USDC)PPT(BUSD)PPT(Dai)를 가정하면, DeFi 풀은 About stablecoins PPT(USDT)

PPT(USDC) PPT(BUSD) Assuming PPT (Dai), the DeFi pool is

Value(PRYS) = Value(Cryptocurrency)

in balance

Total market capitalization is given as the sum of its assets, or

Value (Pool (74a)) = Value (PRYS) + Value (Cryptocurrency) = 2 Value (PRYS) = 2 Value (Cryptocurrency)

In operation, the purchase and sale (exchange) of pooled assets is called SwapBot 99, which manages transfers to and from wallet 31 according to transaction instructions received via UIUX 82a and recorded by smart contract 72. It is managed by a software-based trading bot (dApp). If the asset being traded has a price per token that changes over time (i.e. either a corporate token (73) or a cryptocurrency wrap (e.g. WETH (34e)), the spot value of the asset is collected in real time by Oracle (82b). It is calculated based on market data. Until the corporate token 73 is listed on a private DEX or public exchange, the price per token is assumed to remain at the last traded price.

Despite the complexity of implementing smart contracts 72 that manage multi-crypto pools 74a, investors can use said pools as a convenient means to acquire newly released corporate tokens 73 using a variety of available crypto payment methods. Reporting, thereby improving user experience while ensuring healthy liquidity of the pool. Access to buy and sell enterprise tokens 73 via multi-crypto DeFi pools 74a on multiple networks, via the ingenious SwapBot 99 and UIUX 82a, is provided through interface 95a, graphically shown in FIG. This is easily facilitated through the flow charts in 20a and 20b.

As shown in step 1 of Figure 20A, SwapBot application 95a is opened in UIUX 82a hosted on a smartphone, desktop computer, or laptop. In Step 2, the user connects his personal (usually non-custodial) wallet 31 to the SwapBot application 95a by selecting Connect Wallet 95b. In the example shown, the user selects his or her ultra-secure CyberWallet. To process a transaction, the wallet needs to contain an appropriate amount of cryptocurrency (e.g. ETH on the Ethereum network, BNB on the Binance Smart Chain, etc.) to cover the transaction gas fee for the specific network.

In step 3, the user selects a blockchain network (95c) from the menu of available network options (83z) downloaded from the protocol library following LaunchBot's DeFi pool creation. If a specific currency is available in TGE, crypto cannot be added later. In an alternative embodiment, the smart contract includes provisions to support all major currencies, but UIUX 82a blocks access (allowing for later activation). In the example shown, Ethereum is selected as the network for the transaction.

In step 4, the user selects a crypto payment form (95d) from the options list (92b). In the example shown, the Ethereum blockchain is selected as the transaction network, so the ERC-20 version of USDT is selected for settlement. However, if you choose the Binance network, USDT will be available according to the BEP-20 standard rather than ERC-20. Once a payment currency is selected (95d), in step 5 SwapBot reports the wallet's current currency balance (95e). At step 95q, if you have sufficient crypto balance, you can proceed with the transaction. Otherwise, a new currency must be selected in step 95d or the transaction must be canceled altogether.

Continuing with step 6 of Figure 20B, the user enters the intended purchase amount specified in crypto (95f) and in step 7, the user selects the token they wish to acquire by entering the token symbol name (virtual token PRYS in the example shown) (95g ). The icon for token 73 automatically appears to provide visual confirmation of the selection. At the same time, the calculated number of tokens you will receive at the market price (or TGE price if the tokens are locked) is displayed. In step 8, when the user enters a purchase code that authorizes a special price (e.g. PPT = $0.01, $0025, $0035) (95h), the special price is selected by the conditional branch (95r) and in step 9, the newly calculated token amount to purchase is is displayed (95i). Once the trader confirms that the calculated amount is correct, he or she presses the buy button in step 10 to execute the trade (95j).

UIUX 82a, combined with SwapBot 99 in this way, can support token distribution to both launch pools (i.e. when companies launch new tokens) and transaction pools (supporting DeFi transactions). The main difference between these two cases is one of token locking and the role of AMM DeFi (82c). In Figure 21, the differences are illustrated by contrasting purchases through SwapBot from a token launch compared to a typical DeFi pool transaction. In the token release pool (74f), corporate tokens can be purchased from the pool, but cannot be sold. The pool therefore begins the sale with a fully collateralized issuance of corporate tokens (76) equal to the asset's starting value (215) and essentially having zero crypto (34e) (shown slightly above 0 for illustration purposes). Later pools (74g) show that the total value of corporate tokens (76) has fallen and been replaced by an increase in crypto consisting of WETH (34e) and BUSD (75a). For the sake of simplicity, assuming there is no change in the market price of these crypto assets during the launch, the sum of the total value of the corporate tokens (76) and the total value of the crypto (34e and 75a) will still be the calculated launch value of the said issuance (215) It should be the same as

In fact, the corporate tokens are allocated to different tranches so that the token value increases as issuance progresses. This effect is not included as it does not help explain the operation of SwapBot. Later, the stock of corporate tokens available for sale in the pool (74h) has been reduced in supply and value to 75, while the total cash value the corporation has collected through issuance now includes the sum of the asset value (34e) plus 75a, 75b and 75c; , has a value close to the original expected value (215).

Essentially, in the launch pool, SwapBot sells newly launched corporate tokens for crypto (cash equivalents) and does not replenish the token supply. Moreover, the main change in value assumed by this model is not market price fluctuations, but changes in the number of tokens and cryptos in the pool. After the above issuance is completed, companies are free to receive the collected crypto to finance their operations and development according to the stated use of the proceeds.

In contrast, the use of SwapBot in DeFi pool trading is completely different. As you can see in this example, the pool (74m) is funded by liquidity providers and has a set value of corporate tokens (76) plus WETH (34e), USDT (75a), BUSD (75b), USDT (75c) and Dai (75d). ) contains the same amount of crypto value distributed across various digital assets, including In this case, the token and crypto each start with a total asset value (215), so the total pool value is the enterprise value plus the same value of cryptocurrency, or double the launch pool value (215).

During the transaction depicted by the pool (75n), the sale of corporate tokens to the pool decreases the total amount of crypto and increases the available amount of corporate tokens (76), creating an imbalance between the two columns of volume (75y) . To rebalance the pool, investors acting as liquidity providers can either inject 75y amounts of capital in cryptocurrency into the pool, sell some of their corporate tokens on the market (e.g. outside the pool) and return the net proceeds to the pool, or , or a combination of these must be used to rebalance the pool by ensuring that the pool is balanced. In Pool (74n), crypto assets are lower than tokens by an amount of 75y, but in Pool (74o) the opposite is true: there is a shortage of corporate tokens, which have a total value of 75z, which is less than crypto holdings. In such cases, investors must balance the pool by procuring new corporate tokens from the market and injecting them into the pool using their own cash or using a portion of their excess tokens.

In either case, to maintain liquidity for both buyers and sellers, the pool must be rebalanced until the asset values are equal, regardless of whether the net value of the assets is greater or less than the starting value (215). This is the role of the automatic market maker AMM 82c shown in Figure 22. In this case, the liquidity provider 86 adds or removes value to the multi-crypto pool 74a, or buys or sells assets in the pool to create the cumulative crypto value of 34e, 75a, 75b, 75c, 75d and the corporate token (76). ) can maintain a balance between

Whenever a rebalancing occurs, the DeFi oracle (82b) must check the current market value of the pool's constituent assets based on current market information (84) and on-chain recorded transactions (33). The imbalance in value, as shown in Figure 23, is the sum of the number of each token multiplied by the current price of that token minus the total sum of each cryptocurrency evaluated at its market price. Unlike other DeFi pools, AMM (82c) does not just balance the pool between the value of the token (76) and the total value of WETH, USDT, BUSD, USDC and Dai crypto assets, but also based on market liquidity and recent trading volume. It is designed to maintain a certain ratio between cryptos. In the table shown, each crypto asset's inventory has a target range that includes a minimum, maximum, and target. Whenever the relative amount of these tokens falls outside the specified range, AMM automatically adjusts it, regardless of whether the total crypto value and the value ratio between the tokens are still within the guidelines.

For example, among stablecoins, USDT's trading volume and liquidity are much larger than similar coins. In contrast, Dai is a relatively small player in the stablecoin market. As shown in the table under “Value Allocation Range”, AMM targets USDT balance equal to 68% of pool value at a slippage of approximately ±3.5%. WETH total amount is limited to 15% ± 3% to minimize market volatility risk. The disclosed invention represents the first multi-crypto pool and AMM.

The Need for Locked Tokens : An important consideration in the tokenomics of new token launches is the total token issuance volume (fully diluted) and the circulating supply of tokens. To prevent rampant selling (lug pulls) or panic selling by insiders and to encourage holding of newly released tokens for long-term profits, they can be sold at or shortly after the public issuance of tokens, i.e. at a Token Generation Event (TGE). It is important to limit the supply of unlocked tokens.

The buy-sell problem is illustrated in the flowchart of Figure 24, where investors who purchase corporate tokens at a pre-sale discount can sell their assets at a higher price as soon as public trading begins. The token issuer has no idea who is responsible for the sale or how deep the selling pressure is. This is especially true when panic selling occurs. For example, an investor could convert fiat currency (122a) to crypto (124a) (e.g. USDT) on a centralized exchange (CEX) (123a) and then make a new substitution during the pre-sale via a smart contract (125a). Purchase token (FT) (126a). If a company distributes presale tokens to investors, the investor may store the token 126a assets in a non-custodial wallet 121 and perhaps segment those assets into several smaller wallets (too many to keep track of). .

Once the tokens are available for public trading, investors can transfer unlocked tokens (126b) to a smart contract (125b), exchange them back to crypto (124b), and then convert them to fiat (122b) on the CEX exchange (123b). Sell it to make a quick profit. If a sale occurs when a token's trading volume is low, even a small sale can drive down the sale price, permanently damaging the token's perceived value and discouraging future investment.

Because tokens are fungible, all tokens released are identical, interchangeable and indistinguishable. Therefore, it is impossible for some of the released tokens to be locked while the tokens used for TGE's public listing are unlocked and tradable. All tokens are locked or all tokens are unlocked. One solution to prevent early sales of presale tokens is to simply not distribute the tokens, but store them in a dedicated corporate wallet until a mutually acceptable date. This solution may seem trivial, but it causes several serious problems.

In particular, token investors are generally not people who trust centralized authority. This is one of the reasons why investors have become DeFi traders for decentralization. Naturally, they expect to receive proof of purchase when procuring tokens. Having the issuer store their tokens in a private wallet (to which the investor does not have the keys) means that the issuer will distribute the tokens later (perhaps months or years later) and the issuer will be responsible for executing the distribution process manually. It means you have to trust it. These processes are the exact opposite of DeFi and are neither autonomous nor permissionless. Manual processes are also unreliable and prone to errors or infringements through incompetence or fraud.

Another problem with manual deployment is its complexity and high cost. Every issuance involves a combination of various tranches, each with its own vesting schedule. For example, Figure 25 shows various token recipients in a typical tokenomics model (100), including institutional investors (VCs) (55a), strategic investors (55c), and individual tranche investors, all of whom have the tokens they purchased It is provided in a locked state and is expected to be vested over time. In TGE, additional categories of locked tokens are reserved to cover project costs for engineering and business development (55b) and are therefore free to use, albeit with typically longer vesting schedules. Other tokens are necessarily issued unlocked from the beginning, with a relatively small portion allocated for public listing (90) in IDOs (initial DEX issuance) and token generation events (TGE). After TGE, additional unlocked tokens are distributed to one or more DeFi liquidity pools (74m) to provide a market-making vehicle.

To provide assurance that token (73) distribution will occur as agreed, one method is to use smart contracts (72) using bug-free executable code generated by the aforementioned LaunchBot (71) authoring system, one for each network. ) Distribution is executed through a smart contract (72) certified by a third-party code verifier (e.g. Certik) by complying with the defined attribution and distribution schedule.

The complexity of multi-tranche and multi-network token distribution is illustrated by the flow diagram in Figure 26, where tokens released for private sale (31) are vested (104), and sold to DEX and CEX (108). can be unlocked (103) or attributed (104), and the token 741 for pool liquidity is inevitably unlocked (103). Tokens in storage 101 may be locked 102 (to be unlocked manually at a later date) or unlocked 104 according to a vesting schedule. The problem with this approach is that once distributed tokens cannot be mixed with other tokens, which must remain locked during attribution.

An example vesting schedule, shown graphically in Figure 27, includes lump sum vesting from 0 to 12 months and unlock schedules for seven categories ranging from 12 to 18 months: Liquidity (111), Business (112), and Development. (112), public issuance (114) and allocation to investors (115). One smart contract 72 deployment scheme implemented by LaunchBot 71 involves time vesting and distribution from a token depository 101 using automatic “push vesting.” As shown in Figure 28, using push attribution in a LaunchBot-specified distribution means that the token is "pushed (117)" when it is attributed. In other words, it is unlocked on a specific date and airdropped to the designated address of the recipient's wallet (31). For example, the first airdrop 105a only occurs after 6 months. Thereafter, as shown, airdrops 105b, 105c, 105d, and 105e occur monthly over 7, 8, 9, and 10 months, respectively. Push attribution continues until all tokens are distributed.

Although push attribution overcomes trust issues and vulnerability to hacking, the cost of thousands of airdrops executed over several years is prohibitively expensive. Despite the high level of automation, using push deployment can cause other problems. Blockchain transfers are irreversible, so if the recipient's wallet address changes, the tokens may become invalid or be transferred to a locked wallet and lost forever. There is no means to retrieve tokens once pushed to the investor's wallet. Additionally, for various reasons such as tax issues, investors may not want to receive tokens immediately upon confirmation of attribution.

kTx Collateralized Transactional Tokens : A unique and innovative technology for managing token distribution disclosed herein is Collateralized Transactional Tokens, abbreviated as kTx (where k represents collateral and Tx is the abbreviation for transaction). In this token distribution method, investors do not receive tradable corporate tokens in return for their investment, but instead receive kTx tokens as a proxy for the tokens they purchased. Like redemption coupons, kTx tokens can be exchanged for corporate tokens at any time after a specific class of corporate tokens has been vested. Because fungible tokens are identical, indistinguishable, and interchangeable, there is no need to tie the attribution of any particular corporate token to a specific owner or wallet. Whenever a category of tokens is vested, any investor holding kTx tokens can redeem any amount up to their total vested amount at any time they wish. There is no need to push or transfer any corporate tokens to investors. Instead, investors can use kTx tokens as proof of ownership and redemption coupons to claim their vested tokens whenever they want. Through this, the burden of token airdrops and the resulting risk of wallet address errors are completely eliminated when attribution is confirmed.

In the manner specified, collateralized kTx tokens act as 'proxy tokens' representing real assets held in reserve locked in a released vault. This minting vault is not a separate wallet or physical entity, but a structure containing the unminted portion of a tradable corporate token that is locked within a smart contract from the beginning (e.g. in a TGE).

Any conversion rate is possible, but typically one kTx is released per corporate token created. This means that the kTx and corporate token redemption ratio is 1:1. Since the kTx tokens distributed to investors at the time of investment reflect the number of unclaimed Corporate Tokens, the Corporate Tokens serve as “collateral” for the kTx Tokens. Since the kTx token is not listed on any public exchange, its intrinsic value reflects the value of the corporate token, i.e. the underlying asset. Since kTx tokens have the intrinsic value of collateral, they can be used as proof of ownership and utilized in private transactions. Therefore, even if the underlying collateral has not yet been vested and is locked, kTx tokens can be used for various transactions (e.g. staking and (same) can be used as collateral. Thus, a named collateralized trading token represents a feature or property of a token - the token can be used for trading based on the net present value of its underlying collateral.

Although it is possible to create kTx tokens even after the TGE (either as a secondary trading market or as a derivative), in practice the kTx tokens are created simultaneously with the collateral corporate tokens within the same smart contract. The origination of corporate tokens and their kTx proxies occurs simultaneously within the issuance smart contract at TGE, but it is easier to visualize the process sequentially, as shown in Figure 29. As shown, the smart contract 150 created by LaunchBot first creates a proxy pool 160a as a register to track the total number of kTx tokens (161a) and the total supply of corporate tokens (162a) (151a) ). The total assets included in the pool at the moment of birth are zero. Immediately thereafter, in step 151b, the smart contract creates a fixed supply of kTx tokens 161b. At this moment, the kTx tokens created in proxy pool 160b are worthless because they are not collateralized by assets of real value.

However, at step 151c, the enterprise 214, which is a business or DAO with purpose or value, approves and directs the smart contract 150 to issue a fixed number of enterprise tokens ( 162c) is created. The total value of the proxy pool (160c) is not twice the value of the corporate tokens it contains. This is because only one of the tokens can be issued and circulated at a time. Specifically, whenever a fixed number of kTx tokens are issued, an equal number of corporate tokens must remain in pool 160c as collateral. If kTx tokens are redeemed for corporate tokens, kTx is returned to the pool and removed from circulation. In one embodiment, once redeemed kTx tokens are burned. That is, it is irreversibly destroyed, avoiding the risk of later reuse and preventing fraud. Since the proxy pool only contains kTx and corporate tokens, the proxy pool cannot sell either of them in exchange for any other asset. Instead, it relies on a companion pool, the swap pool, to enable transactions.

The next step in distributing kTx trading tokens is to create a swap pool as shown in Figure 30. At step 151d, the smart contract creates a new register 163d for trading and holding fungible and tradable crypto (e.g. WETH, USDT, USDC, BUSD or Dai). The second half of the swap pool 185d contains a supply of kTx tokens 161d, which is the same supply as the kTx 161c recorded in the swap pool 160c.

In other words, kTx supply is registered in two pools - with corporate tokens in the proxy pool (160c) and with fungible and tradable cryptos in the swap pool (185d). Afterwards, the investor 179 transfers the crypto 191 to the swap pool and receives kTx tokens 190 as collateral at the same price as the corporate token to be issued in TGE. After receiving the crypto transfer to the swap pool (185e), the asset value of the crypto (163e) increases proportionally while the kTx token supply (161e) decreases by the same amount (177). The sum of the total cumulative value of the underlying collateral for the kTx token (161e) and the market value of the cryptocurrency (163e) received at the moment of transaction corresponds to the total sum (215), which is the same value as just before the swap.

As shown in Figure 31, since the kTx token supply (161e) is shared by both the proxy pool (160c) and the swap pool (185e), the combination of the two pools includes crypto (163f) and corporate token (162f) It acts as a virtual token release pool (199f) with a cumulative value (215). Therefore, by selling corporate tokens to investors but delivering kTx tokens instead, the buyer can be assured that once the corporate tokens are listed and unlocked, they can later be redeemed for fungible corporate tokens and that they are holding proxy tokens representing the underlying collateral. there is.

By doing this, early sales of locked corporate tokens are completely eliminated, while still enabling convenient distribution. Instead of unlocking and distributing corporate tokens, as shown in Figure 32, token release pool 160c releases proxy tokens 190 while maintaining locked token supply 162c. As shown, kTx transactions occur through swap pools 185, through IDOs through exchanges 108 to private wallets 31, or into storage 101 for later distribution, such as secondary (subsequent) issuance. ) is stored in Therefore, investors purchase corporate tokens, but receive kTx tokens in return. The kTx tokens themselves are issued unlocked, but are not listed indefinitely and cannot be sold or traded on any public exchange. It only has value when redeemed against corporate token collateral. The vesting (104) and unlocking (103) of the locked token (102) refers to its ability to be redeemed with corporate token collateral rather than with kTx tokens.

Compared to the problematic unauthorized early sale problem previously described in Figure 24, using kTx collateral tokens completely eliminates the early sale problem as shown in Figure 33. As in the previous embodiment, the investor 200 converts the fiat currency 202a into crypto 204a at the exchange 203a and then invests in the token presale executed by the smart contract 205c. However, instead of receiving corporate tokens, proxy pool 209 only releases kTx tokens 207a to investors (210a). Through SwapBot (71), kTx tokens are delivered to the investor's wallet (201) in unlocked form. Although kTx tokens are not unlocked, corporate token collateral remains locked according to vesting confirmation (208c).

Once a portion of the corporate tokens have been vested (208c), the same number of kTx tokens can be redeemed (110c) from the proxy pool (209) via a smart contract (205d) and a fungible transaction that can be held or sold. Deliver available corporate tokens (206c) to investors.

If an investor wishes to sell unlocked corporate tokens 206c, he or she may execute a transaction via smart contract 205e to receive crypto 203c at the market rate and then (if desired) on the exchange 203c. Crypto can be converted to fiat currency (202c). Only corporate tokens that have been vested and unlocked in this way can be redeemed for the same number of kTx tokens upon vesting. Therefore, early sales are prevented autonomously without the intervention of the issuing company.

Figure 34 contrasts the unlocked and collateralized token release processes, where instead of crypto 204a being converted into a fungible and tradable token 206a by a smart contract 205a, the present invention The improved smart contract 205c releases the kTx collateralized transaction token and deposits it into the wallet 201. In the unlocked token distribution 208b, the fungible token 206b can be immediately sold 205b in exchange for crypto 204b, but in the improved process, a smart contract 205d is used to confirm that the attribution 208c has occurred. Only upon confirmation, kTx tokens 207b can be redeemed for fungible corporate tokens 206c. Once claimed, fungible token 206c can be held in wallet 201 (211g) or sold (211f) for crypto 204c by smart contract 205e.

Figure 35 illustrates the change in token supply over time within the swap pool during a transaction, where at the start (213) the enterprise (214) receives a uniform value (215) of enterprise tokens (2919a) and kTx tokens (218a). It starts with While kTx is on sale but before it is unlocked, investor 200 purchases corporate tokens from enterprise 214 with crypto 204a but instead receives kTx tokens 207a, making kTx tokens 218b available in swap pool 209b. Reduces the supply of but maintains token collateral (219b). During redemption indicated by the pool 209c after confirmation of attribution, the level of corporate tokens 219c decreases as tokens 206c are distributed to investors 200 who redeem kTx tokens 207b, resulting in the recovered kTx token supply. (218c) causes it to rise until all corporate tokens are issued. In one embodiment, all kTx recovered by exchange are burned and permanently destroyed to prevent the risk of theft and misuse. The two-column diagram shows the relative levels of kTx and corporate tokens, but does not accurately account for all transactions since cumulative crypto payments are not represented.

In Figure 36, an excellent representation of tokenomics trading in the launch pool is shown in a three-column graphic, with each column illustrating the relative asset value at launch, during kTx sale, and during kTx redemption in pools 229a, 229b, and 229c. . Specifically, at start 213, enterprise 214 fills column 3 - pool 229a with equal amounts of crypto (219a) and kTx tokens (218a), while the token value (220a) is essentially zero. During the kTx sale, the investor 200 provides crypto 204a and receives kTx tokens 207a as compensation and a proxy for the pool's corporate token collateral. During the kTx token sale process, the token value (220b) increases while the number of kTx tokens in the pool decreases to almost zero (218b). During the kTx sale, the total corporate tokens (219b) remain constant.

During the kTx redemption represented by the 3-column pool 209c, the kTx level 218c rises as the available supply of corporate tokens 219c decreases as investors redeem kTx tokens 207b for corporate tokens 206c. do. During the redemption phase, the crypto asset level (220c) remains constant (at least until companies withdraw the funds received from the pool to fund operations and development, depending on the use of the proceeds from the issuance).

Redemption of kTx tokens into corporate tokens does not necessarily have to occur at the moment of vesting. For various reasons, including income reporting and taxation, investors may not claim their vested tokens. Figure 37 shows swap pool asset levels over an exemplary 18-month vesting period starting at value (215). As shown, even though kTx tokens have not been redeemed, the number of vested tokens increases from 0%, 20%, and 40% at 6 months, 9 months, and 12 months, respectively, and the corporate token level (219a) remains at 100%. and the kTx level 218a is maintained at 0. Then, at the end of 18 months, when 80% is confirmed to the investor, the wallet 231 redeems the amount of kTx tokens (207b) corresponding to 80% indicated by 218z, which is the confirmed lock held by the investor. It corresponds to 100% of the released corporate tokens. In response to the redemption of 218z kTx tokens, the pool releases unlocked tradable corporate tokens (206c) in an amount that lowers the level of remaining corporate tokens (219z) to only 20% remaining.

Although the aforementioned description of kTx-based trading involved only a single denomination of cryptocurrency, the principles of multi-crypto pools are equally applicable to multi-currency pools, as shown in Figure 38. As shown, liquidity providers 255 supply crypto assets 254 to a tri-pool 250 including corporate tokens 253, kTx tokens 252, and cryptocurrency wraps 251, where Crypto wrap 251 may include any combination of WETH (244), USDT (245a), BUSD (245b), USDC (245c), and Dai (245d). When interacting with crypto 240, kTx token 243, and corporate token 242, it is convenient to use icon 241 to graphically represent the multi-crypto pool.

Token Swapping and /or Staking : Using the disclosed methods, corporate tokens, once created, can be used to stake DeFi (decentralized finance) pools to earn earned interest. DeFi pool APY (Annual Yield) can be fixed or variable, and the time period can be daily, monthly, quarterly, or annually. In this way, token holders are incentivized not to sell their tokens economically.

In particular, kTx holders can pledge their tokens as collateral to expand their value in the following ways: (i) staking tokens to earn interest, or (ii) a portion for staking and a portion for exchange. (iii) Exchange your kTx tokens by subdividing them into different parts (also known as kTx staking and swapping) or (iii) automatically investing corporate tokens into a staking pool for a set period of time. For example, Figure 39 shows the post-swap staking function, where the investor's kTx tokens are deposited into the vesting contract 310 prior to vesting (313). Upon confirmation of attribution, kTx tokens are automatically redeemed as corporate tokens from the swap pool (311) and staked in a fixed-term staking contract (312), effectively locking the tokens for a longer period of time in return for higher returns. Figure 40 shows an alternative method in which kTx tokens 313 are used simultaneously for staking (312) and exchange (311) according to a defined vesting schedule (312).

Alternatively, Figure 41 shows that kTx tokens can be used for token exchange on KDEX (Collateral Token Decentralized Exchange) prior to collateral unlocking, or alternatively for staking in an interest-bearing account. The value of kTx tokens on KDEX may be lower than the actual market value of the collateral. As the vesting date approaches, the market value of kTx tokens on KDEX will gradually approach the market value of the underlying corporate token.

NFT Transactions : The same autonomous LaunchBot dApp can create NFTs. As shown in Figure 42, the input file 300 for creating an NFT portfolio includes a metadata file 301. LaunchBot 71 combines input from the network protocol library 83 and blockchain-specific data to create a smart contract 302 that launches a new NFT 303 to one or more networks. Unlike fungible tokens released in DeFi pools, the created NFTs can be used for immediate trading with Metaverse collectors 305 on any number of NFT marketplaces, regardless of the blockchain on which the non-fungible tokens were originally created. .

If traders wish to engage with collectors on a separate blockchain, the token ecosystem includes an NFT teleporter feature as shown in Figure 43. In token teleportation, a holder of an NFT 350 token on an EVM can provide a replica of the teleported NFT to a buyer on the BSC where a smart contract 351 identifies the target wallet and network. However, instead of transferring the wrapped tokens used in the bridging procedure, a new wrap is started on the original token 350 and teleported to the buyer as an NFT replica 354. Meanwhile, the previous token instance 351 is removed by incineration (353) to prevent the risk of duplication. This way, all teleported tokens only contain a single wrap and do not contain nested wraps with hidden gas costs.

Claims (22)

A method of writing smart contracts and generating tokens for multi-tranche fungible or non-fungible token offerings, comprising:
Compiling a file containing issuance tokenomics specifying the price, quantity, availability, and timing of tokens released in each tranche of the issuance;
Compiling a file containing a network protocol library containing tokens and smart contracts for one or more blockchain networks, including a programming language and variables defined for the token type to be created;
Submitting the file specifying issuing tokenomics and the file specifying one or more blockchain protocols selected from the network protocol library as input to a smart contract creation bot program;
A step of executing the smart contract creation bot program to create one or more decentralized application programs, where each program includes a smart contract (dApp) for creating a new token in one or more blockchain networks, and each blockchain network Requires its own unique smart contract (dApp), steps;
verifying the integrity of all smart contracts (dApps) created by the bot for accuracy or software bugs; and
This is the step of uploading and registering and executing the smart contract (dApp) written by each bot on each blockchain. Here, the process of executing the smart contract (dApp) is a transaction by the peer jury according to the operation of the blockchain's virtual machine. Verification is required, where participating peers are compensated with a gas fee paid in a cryptocurrency specific to the operation of the blockchain, including steps such as
A method of creating a smart contract and creating a token, wherein the generated token is maintained as a digital asset not distributed within a smart contract (dApp), or alternatively is transferred in whole or in part to one or more digital wallets or DeFi pools. According to paragraph 1,
The network protocol library includes specifications for major blockchain networks and blockchain virtual machines, and the blockchain virtual machines include Ethereum Virtual Machine, Binance smart chain, Cardano, Polkadot, Solana, Avalanche, Ripple-Coil, Hyperledger Fabric, You can create and run smart contracts (dApps) on a variety of blockchains, including Tezos, Tron, Algorand, Hedera, Stellar, etc., where the network protocol library supports NFT standards such as ERC-721, BEP-721, and ERC-721. Methods for writing smart contracts and creating tokens, supporting major smart contract compatible digital token standards including 20, BEP-20, and ERC-1155. According to paragraph 1,
The tokens are released in successive tranches unique to each blockchain network and are intended for investment by private, institutional and strategic investors, including seed, private, strategic, IDO and TGE-public investor tranches; Tokens for issuance to non-investors for engineering development, business development and liquidity; and methods for writing smart contracts and generating tokens, including unissued tokens held in smart contracts (dApps) or vault wallets. According to paragraph 1,
A smart contract creation and token creation method in which the buyer acquires released tokens by transferring digital assets from a personal or exchange wallet to a smart contract (dApp) and receives the equivalent value of the released token in return. According to paragraph 1,
To support multi-chain transactions:
A token belonging to the first blockchain is cryptographically wrapped according to the target second blockchain network, and then the wrapped token is transmitted to a non-affiliated second blockchain network, so that the token is non-affiliated in the first blockchain network. Teleported to a second blockchain network, or
If a token belonging to the first blockchain was previously teleported to a second blockchain and is teleported to a third blockchain, the previously teleported tokens in the second blockchain network are burned, thereby causing the tokens belonging to the first blockchain to be burned. A method of creating a smart contract and generating a token, wherein the token is cryptographically rewrapped according to a destination third blockchain, wherein the wrapped token is teleported from the first blockchain to a third blockchain network. According to paragraph 1,
DeFi pools are used to enable investors and buyers to acquire tokens.
The DeFi pool includes the token and one or more other digital assets,
Buyers acquire said tokens by exchanging them for other digital assets of equal value,
A method of creating smart contracts and creating tokens where, upon validation of an exchange, the number of available tokens in a DeFi pool is reduced and the number of other digital assets in said pool is increased. According to clause 6,
The DeFi pool supports several types of tokens, stablecoins, and cryptocurrencies, including stablecoins (USDT, USDC, BUSD, and DAI), or crypto wraps of cryptocurrencies, including the Ether wrap token (WETH), to execute transactions. A method of writing smart contracts and generating tokens, allowing for wrapping. According to clause 6,
The exchange process is transactionally one-way, wherein the DeFi pool can transfer tokens to a buyer in exchange for other digital assets, but the trader cannot redeem the tokens for other digital assets. According to clause 6,
Transactions within said DeFi pool are executed through the UIUX user interface or autonomous SwapBot application, where token buyers specify the name of the token to be purchased, the blockchain network on which the purchase will be recorded, the wallet from which the payment will be made, the type of digital asset to be used for the purchase, and the payment amount. Specifies a purchase code that enables an amount, access or discount, and in response the UIUX user interface or autonomous SwapBot application displays the amount of released tokens to be purchased, a method for creating smart contracts and creating tokens. According to clause 9,
The UIUX user interface or autonomous SwapBot application displays the buyer's wallet balance, verifies whether sufficient assets exist for the purchase, verifies whether adequate gas is available in the wallet to execute said transaction on the designated blockchain, and executes said transaction. A method of writing smart contracts and generating tokens that verifies that said purchase code is valid before allowing progress. According to clause 6,
A smart contract writing and token creation method in which previously undistributed tokens held in a smart contract or vault wallet are pushed to an investor's wallet by a smart contract (dApp) according to a defined vesting schedule. A method of executing transactions in a DeFi pool using the autonomous SwapBot dApp, comprising:
Starting a UIUX decentralized application to control the SwapBot dApp;
Entering the details of the transaction into the SwapBot dApp, where the details include the name of the token to be purchased, the blockchain network where the transaction will be recorded, the wallet where the payment will be made, the type of digital asset to be used for the purchase, the payment amount, and the details of the transaction. including a purchase code to enable access or discount for;
As a step of confirming the transaction, the SwapBot application displays the buyer's wallet balance, verifies whether the buyer's wallet has sufficient assets for the purchase, and appropriate gas in the buyer's wallet to execute the transaction on the designated blockchain. verifying that it is available, and verifying that the purchase code is valid;
Calculating the number of tokens to purchase based on the current market price displayed in the blockchain oracle; and
Executing a smart contract transaction for the DeFi pool according to transaction details entered into the SwapBot dApp,
A method of executing transactions in a DeFi pool whereby digital assets are transferred from the buyer's wallet to the DeFi pool as payment, and in return, the purchased tokens are transferred from the DeFi pool to the buyer's wallet. According to clause 12,
Payment for the token includes token; Stablecoins (USDT, USDC, BUSD or DAI); or a method of executing transactions on a DeFi pool, made against the DeFi pool using a cryptocurrency that includes a crypto wrap of a cryptocurrency, such as the Ether wrap token (WETH). According to clause 13,
The DeFi pool includes a token supply and a collection of crypto digital assets, wherein the purchase of tokens decreases the token supply within the DeFi pool while increasing the total value of the crypto digital assets in the DeFi pool. . According to clause 13,
The DeFi pool includes a token supply and a collection of crypto digital assets, wherein if an imbalance occurs between the total value of the tokens within the DeFi pool and the total value of the crypto digital assets, the DeFi pool will store the greater total value in the DeFi pool. A rebalancing is carried out by an automatic market maker (AMM) program through a combination of selling some of the assets held and purchasing assets with a smaller total value, a process that results in the total value of the two assets being substantially equal at the time of rebalancing. How to execute transactions in a DeFi pool, until done. A method of writing a smart contract to execute a token release through a collateralized transaction pool, comprising:
Creating and initiating a smart contract that creates two sets of tokens, wherein the first set contains tradable tokens and the tradable tokens are offered for trading, selling or investing, and the second set contains secured transactions. Containing steps, including tokens,
The collateralized trading tokens are generated at a fixed rate relative to the tradable tokens,
The tradable tokens are locked in a smart contract or storage and can be transferred after the smart contract or storage unlocks a portion of the tokens according to a vesting schedule or other conditions,
Investors purchasing tradable tokens receive collateralized trading tokens as temporary proxies for said tradable tokens until all or part of said tradable tokens are vested and unlocked;
Holders of collateralized transaction tokens can redeem the collateralized transaction tokens at a fixed rate with vested tradable tokens,
Tradable Tokens may be sold, exchanged, traded or otherwise pledged as collateral without restriction after said Tradable Tokens have been vested, unlocked and redeemed;
A method of creating a smart contract in which unconfirmed tradable tokens remain locked and cannot be redeemed with collateral tokens until the unattributed tradable tokens are assigned. According to clause 16,
Redemption of collateralized transaction tokens is performed by the collateralized kTx pool.
The collateralized kTx pool is created by a DeFi smart contract and includes a tradable token and a collateralized trading token. According to clause 16,
Tradeable tokens are released in successive investment tranches unique to each blockchain network, where the vesting schedule for the tokens varies depending on the various investment tranches, and some tradable tokens are created with smart contracts that can be traded immediately upon token creation. method. According to clause 16,
The purchase of the above tradable tokens and the release of kTx tokens include stablecoins such as USDT, USDC BUSD and DAI; Crypto labs like WETH; Tradable tokens held as collateral before vesting; and/or a method of creating smart contracts, facilitated through a multi-crypto kTx swap pool containing collateralized transaction tokens released upon purchase as proof of ownership. According to clause 16,
The smart contract includes provision of a staking pool, and the provision of the staking pool simultaneously or sequentially delivers the interest income of the investment for tradable tokens with confirmed or unconfirmed belonging. A method of creating a smart contract. According to clause 16,
A method of writing smart contracts where collateralized transaction tokens are burned to prevent reuse when redeemed. According to clause 16,
A method of creating smart contracts, where the purchase of tradable tokens or redemption of collateralized tradable tokens can be performed through an autonomous SwapBot dApp.