Patent Application
20220327529
This 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, the blockchain and its network replaces the role of commercial banks as transactional fiduciaries. Blockchain features include
As a transactional medium, blockchains enable two parties to engage in commerce without knowing or meeting one another, thereby protecting the privacy and true identity of both. A second key function of a blockchain network is its ability to validate a digital asset, virtual currency, or a smart contract to prevent counterfeiting, double spending and contract fraud.
The third function of a blockchain network is its ability to store data, i.e. to function as a database immune to single point failures or attacks. DLTs, an acronym for distributed ledger technology represent a entire class of linear database constructs. The terms DLT and blockchain are often used synonymously. While it is true that a blockchain is a DLT, the converse is not necessarily the case. A more accurate description is that a DLT is a special type of database, and a blockchain is one particular implementation of a DLT.
Specifically, distributed ledger technology (DLT) comprises a distributed database managed by multiple participants spread across multiple nodes. Ostensibly, storing data on different nodes confers an added degree of data security because an attack on any one node (or its local data storage devices) is unable to access the full dataset contained in the diffuse database. But storing data distributed across multiple devices in multiple locations does not ensure a DLT is decentralized.
A truly decentralized database requires both the data content and the database access to be distributed. A DLT database with centralized control access to a distributed database, e.g. a CFO's desktop computer, is not decentralized because focused attacks on the control interface can access the entire content of the DLT regardless of where the contents are held.
The blockchain, a fully decentralized version of a DLT overcomes this vulnerability by removing the central control node entirely. Every block contains content (the payload of the blocks) plus a block header. Contents of the block header vary by blockchain but generally include a block-number; a time-stamp to ensure blocks are entered sequentially; and the block's unique digital identity needed for cryptographic validation or mining.
The payload of a block may contain passive information such as financial transactions; an identifying “address” of a digital asset or virtual currency; a linear data base or file; a creative work; or other database records. The payload may also contain software in the form of a computer program or a decentralized application such as a smart contract (described in a subsequent section). The payload may contain both encrypted (ciphertext) and unencrypted (plaintext) data.
Aside from its payload, each block is time-stamped to provide an immutable chronological record of events. Another key element of every entry on a blockchain is a digital identity or signature, some means by which a third party can validate the block is valid and not fraudulent or corrupted.
Cryptography in DeFi: One way users control access to blockchain content and validate its authenticity is through the use of cryptography[35][36][37]. In broad terms, cryptography employs one of two stratagems,
In the reversible process of encryption and decryption, a payload's content (e.g. transactions, data, files, images) is encrypted using a defined algorithm with a cryptographic key to produce an encrypted file called ciphertext. Using a decryption key (uniquely corresponding to the encryption key), another party can then recover original unencrypted (plaintext) content from the ciphertext.
In order to decrypt the file, however, the reader must first obtain a copy of the decryption key in a process called a key exchange. A key exchange safely performed over unsecured channels is referred to as a public key exchange. Although the mechanisms of public key infrastructure (PKI) for exchanging cryptographic keys are many, one common algorithm is a split key exchange.
During a split key exchange, the intended recipient of encrypted content (not the sender) creates two keys—a public encryption key and a private decryption key. The cryptographic 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 recipient then sends the encryption key to the sender node to encrypt their content accordingly and the resulting ciphertext is sent to the recipient. Since the encryption key is not useful for decrypting the ciphertext, both the public key and the encrypted file can be communicated publicly over open channels (hence it's the name “public key”).
In most cases, however, sharing a cryptographic key with a user requires prior approval to access the contents of a block. Such applications are referred to as permissioned systems because access must be granted by an administrator. Ironically, not only is PKI used by blockchains for trusted validations, but now blockchains are being symbiotically used to improve the integrity of PKIs.
While PKI methods can be used to protect content in a blockchain, it is unnecessarily complex for validators simply to verify the authenticity of the chain has not been corrupted or the provenance of its blocks altered. Instead an alternative approach called a permissionless system is preferred, one where miners don't need to request access to the blockchain and where sufficient information is publicly available to independently verify the veracity of the chain.
This is where the role of a cryptographic hash comes in. A hash is a cryptographic process whereby a file of any size is encoded into a fixed length ciphertext based on the content of the file being hashed, not on a separate cryptographic key. Properties of a cryptographic hash include:
Compared to encryption, an important distinction of hashing is that the process is unidirectional—once a file is hashed the original content cannot be recovered or extracted from the hash output. Although at first glance the process of making a file no one can read seem useless, as it turns out hashing has become a critical component in verifying all blockchain transactions today.
The unique property of the hashing process is its deterministic yet highly non-linear behavior. Even the most minute perturbation in the source file produces vastly different unrecognizable hash code outputs. Statistically, this property means the only way the hash of one file will match the hash of another file is if the two files are identical. Metaphorically, a hash is a digital fingerprint useful to reject imposters, exclude fraudulent blocks, and prevent content tampering. A hash's fingerprint feature can be used to confirm a sequence of blocks in a chain are self-consistent and belong together. The hash of a hash of a hash, is called a hash chain, for example:
H[H[H[H[x]]]]≡H4[x]
Hash chains render sequential verification of a chain simple—the insertion of a fake block will produce a cascade of inconsistency errors easily detected as fraudulent by any third party validator. Adapting hashing to the process of validating a blockchain for 3rd party inspection, blockchains employ nested hash chains. In nested hash chains, each block includes both a hash H[x] of its predecessor blocks plus new content including transactions, data, images, etc. For example if x=n, n−1, n−2, n−3 . . . the nesting of a hash chain can be represented by the data structure:
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 depicted in
In a nested hash chain each block is hashed and embedded into the block header of the subsequent block on the chain. As shown the content of the entire block 2b (labelled as block (n−2)) is hashed by hash function 4b and the output embedded into sub-header 5 contained within block header 3 within block 2c. Similarly the content of pervious block 2a is hashed 4a and embedded into the block header of block 2b. In this manner no block is free of containing the hash of all the blocks before it in time. Metadata sub-block 6 may also contain a time and date stamp making the blockchain linearly temporal. During a block's validation, if the hash recorded in any specific block does match the result of hashing the previous block, that block doesn't belong there and the blockchain being evaluated is corrupted or fraudulent.
Aside from using hashing to validate the legitimate sequence of blocks, hashing can also be used to validate the content within blocks. Unlike sequenced blocks on the nested hash chain, hashed data of transactions contained within a block are not sequential but hierarchical, with each hash linked to its parent following a parent-child tree-like relation with the most populated hashed transactions comprising upper branches of “leaf” entries. Also depicted in
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 repeated fashion until a single hash remains. Using ∥ to denote concatenation, the hash pair HAB and HCD are given by
HAB=H[HA∥HB]
HCD=H[HC|HD]
This action describes the hash processing executed one layer below the leaf layer. If more than two hashes remain forming an intermediate layer, the process is repeated until only two hash files remain. The final hash, referred to as the Merkel root HMR, hashes these remaining two hashes:
H
MR
=H[HAB∥HCD]
The Merkel root 11 therefore represents a singular unique hash of all constituent hashes in the tree. By including this Merkel root in sub-header 7 of header 3 in block 2c and similarly in every block of a blockchain, a quick check can be used to confirm block integrity throughout the tree. If the hash of the block doesn't match the Merkel root in the header, the content of the block has been tampered with, meaning the block may contain fraudulent transactions or a corrupted smart contract.
Importantly, hashing provides a means for a validation node or miner to confirm the veracity of a pending block before installing it onto the chain. But how can the juror nodes be trusted? Ensuring sincere validation is yet another role of cryptography in blockchain processing. To avoid the risk of a corrupted authentication, validating a transaction and recording it is performed by a consensus mechanism, a process of voting by an anonymous jury-of-peers. Since the juror nodes in the blockchain's network are unaware of the identity of the parties involved in any transaction they are validating, there is no logical motivation for the jurors to cheat or vote prejudicially when evaluating the integrity of a new entry.
Although nodes can vote without doing a thorough job vetting hashes, jurors exhibiting a chronic history of disagreeing with other nodes are suspect and ultimately removed from jury consideration. Another means to discourage improprieties among miners validating transactions is to employ a mechanism of proof. In one such concept (Proof of Work), each block header includes the hash of a random number called a nonce, a cryptography term meaning a number used once. Borrowed from the field of trusted communication, by introducing randomness into transactions a nonce is used as a form of authentication to prevent replay attacks, thereby preventing outsiders from executing a hack by guessing the next action from the last. In order to gain the opportunity to validate (mine) the block, the validator must first extract the nonce value (a random number having an varying number of leading zeroes) by solving the hash-nonce puzzle.
This brute force effort requires using energy and spending money thereby discouraging insincere effort or fraudulent results. In PoW implementations, these same hash-nonce puzzles are used to mine new cryptocurrencies. In addition to validating blocks, cryptography may also be used as credentials for confirming the authenticity of the content itself, e.g. art, music, tickets, etc. a feature especially important in trading non-fungible tokens. By employing cryptography in block confirmations and digital signatures, a blockchain is able to confer to users “trust in a trustless environment”.
Blockchain Properties: Properties of a blockchain include the following key features and characteristics:
Benefits of a redundant distributed virtual machine include timely and confident resolution of transactions and tasks, even when nodes or its communications network go offline. An early example of redundant computing with juror-based decision making was the computer used to control NASA's space shuttle.
A decentralized redundant network should, however, not be confused with distributed computing. In distributed computing, a task is divided into separable pieces and assigned to each node to do its fair share of the work. By paralleling the effort, the time to complete a task is reduced in proportion to the number of nodes contributing to the task. Likewise the total energy consumed to perform the compute job Ejob is spread across the virtual machine having “n” nodes, where each node consumes an average energy of Ejob/n per job.
In contrast, in decentralized computing. a single task or job is identically performed in parallel by “n” network nodes operating in unison as a redundant array of compute nodes. As such, the time required to perform a job is not reduced at all by the virtual machine's redundancy. In fact, in decentralized computing the slowest speed node in the network determines the transaction rate of the blockchain's virtual machine. Moreover the energy required by decentralized computing increases from Ejob consumed by a centralized computer to n·Ejob in its decentralized version, meaning decentralized computing is less energy efficient than a central computer, not more so.
Proof. A key concept in implementing reliable consensus determinations is the means by which to ensure all participation nodes are sincere, i.e. that their vote is verified to be meaningful. Verifying a node is a sincere juror is called “proof”, although a more insightful description of keeping a node honest should be called proof-of-sincerity. But how can a blockchain virtual machine ensure its nodes are acting sincerely on the best interests of the blockchain's integrity and its user community?
The first step toward ensuring transactional integrity is to protect the identity of the parties participating in a transaction, thereby preventing the validators from engaging in conspiratorial or prejudicial voting, or “gaming” the system, i.e. intentionally committing malfeasance.
Common means by which proof is achieved to thwart corrupted voting is by ensuring that a juror node either has something to lose if they vote insincerely or dishonestly, e.g. that (i) they must have either spent money and effort to participate in the validation process (“Proof of Work”)[67], (ii) the value of assets they themselves hold could be adversely affected by their actions (“Proof of Stake”), or alternatively (iii) that the juror node holds certain credentials authenticating them as a participant whereby they only earn remuneration by consistently voting with the majority (without knowing a priori what the majority vote is).
First deployed as part of the Bitcoin blockchain and then later adopted by Ethereum, Proof of Work (PoW) intentionally wastes electricity as an necessary expense to mine new blocks. Spending discourages malfeasance or mischief by making such exploits cost the hacker money they can only recover so long that they are not disqualified for bad behavior. Recently, PoW with its horrendous carbon footprint has come under intense global scrutiny as being energy wasteful, environmentally irresponsible, and ecologically unsustainable. Alternative, greener methods such as Proof-of-Stake are now being adopted.
Migration to Proof-of-Stake (PoS) has however, been much slower than projected, in part because users aren't convinced that the nothing-at-stake problem can be avoided, a malicious deceit where a node misleads other nodes that it holds significant economic interest in the native cryptocurrency of a blockchain when in fact it doesn't. In PoS consensus voting, ineligible nodes if undetected can commit fraudulent transactions (such as double spending) or intentionally subvert valid transactions. Other options include credential-based consensus validations involving time-stamped “Proof of History” (PoH) or the HyperSphere's “Proof of Performance” (PoP), a decentralized consensus algorithm employing dynamic node governance and inimitable cryptographic hop-codes (a type of nested hash chain referred to as a transient blockchain).
These newer consensus algorithms, in addition to improving transactional speed, offer substantially smaller carbon footprints and improved resilience to hacking compared to their predecessors. In fact, the HyperSphere hop code generates cryptographic proof of a node's contributions as part of the network moving data and doing real work—energy that would have been used even if no consensus validation was involved. In other words, PoP validations can be executed as part of packet communication without consuming any additional energy.
But because of their intrinsic differences, these newer consensus mechanisms cannot be retrofitted into extant blockchains, and instead must be built into a blockchain's architecture at its inception.
Security. As described previously, cryptography provides security to the blockchain and its transactions in numerous ways including authenticating the integrity and provenance of blocks on the chain and facilitating a means by which new blocks, once confirmed, can be appended onto the chain. Cryptography also enables verification of a block's Merkel tree to ensure its contents have not been altered, thereby preventing double spending, fraud or tampering with a smart contract.
Using hash-nonce puzzles or security credentials issued via a blockchain virtual machine, cryptography is used to confirm the sincerity of juror nodes involved in approving transactions. Through private keys, cryptography protects the assets stored in decentralized wallets and transacted through smart contracts. Using digital signatures, the authenticity of an asset can also be verified, an especially important feature for trading collectables using non-fungible tokens (NFTs).
While blockchain transactions are protected cryptographically, network communications over the Internet are still exposed to surveillance, metadata analysis, phishing exploits, and malware. Transactions executed via Internet browsers, unsecured wallets, and badly designed protocols remain particularly vulnerable to attacks designed to abscond a user's private encryption keys. To thwart such hacks, an added degree of blockchain protection can be achieved by altering network communication, specifically by obfuscating or encrypting packet data on OSI layers 3, 6, and/or 7 (i.e. network, presentation, and application layers respectively)—methods unique to the HyperSphere.
Unlike the mining and validation of passive cryptocurrency vulnerable to DDoS and consensus attacks, the hard-coded instructions of a smart contract (once uploaded to the blockchain) are immutable. Thus limited, a cyberhacker can only interfere with smart contract execution by operation of the blockchain's virtual machine (BCVM) hosting it or by disrupting the system's state machine, e.g. using time jacking, reentrancy, etc. The risk of DeFi cyberattacks is amplified by badly written code, greatly increasing the attack surface of smart contracts exposed to hacking. To prevent such risk exposure an exhaustive review by trained dApp and cybersecurity experts is required.
Transparency. Decentralized unitary blockchains such a Bitcoin and Ethereum are public, providing open inspection of block entries and transactions. Public unitary blockchains facilitate tracing genealogical history of transactionally related addresses including wallets, digital assets, and smart contracts. Downloads of permissionless smart contracts also enable inspection of smart contract code by authors, users, and accredited 3rd party validation services. The downside of the transparency of public unitary blockchains is their susceptibility to various attacks including backtracing of high value wallets. Fortunately wallet addresses, although public do not disclose the wallet's owner's true identity.
Transaction Speed. The speed of a blockchain depends on its validation mechanisms and on its temporal and hierarchical structure[79][80]. Proof of Work is, for example, significantly slower than Proof of Stake, which in turn is slower than Proof of History and Proof of Performance. Single public unitary blockchains are intrinsically slow and degrade in their transactional throughput the larger (i.e. longer) the chain becomes. Parallel chains like DyDAGs have to the ability to deliver higher transaction rates because shorter chains with fewer blocks can be checked more quickly and with a greater degree of parallelism.
When executing a smart contract containing logic and arithmetic calculations, the operations per second (OPS) rate becomes a critical factor in smart contract execution time. In most implementations, blocks are mined, i.e. transacted, in fixed intervals called block time specific to the blockchain's network. For example, Ethereum previously ran with a block time of 15 seconds and in 2012 reduced its block time to 12 seconds. Newer competing chains are faster, with block times as short as 2 seconds. By contrast bitcoin, a first generation blockchain takes 9 minutes to resolve a block. To perform the same amount of work in less time requires higher speed computing. But since a blockchain doesn't control the hardware its miners or validators use, it cannot stipulate the hardware or a minimum performance level for nodes in its networks. Since all transactions are time-stamped upon the block's recording on the chain, a means to measure and monitor a network's evolving performance already exists. A simple statistical analysis of recent chain transactions immediately reveals current processing times of the blockchain's community of nodes. Improvements in computing performance, i.e. miners buying faster processors, are thereby manifested statistically in transaction rates even though the particulars of computer architectures and GPU semiconductor technology nodes being used are unreported. As such, improvements in network performance can be adjusted to reflect ever improving performance for any specific BCVM.
Increasing a decentralized network's performance criteria does however carry risk[82]. As blockchain specifications are upgraded, the network unavoidably becomes controlled by an increasingly smaller population of more capable compute nodes that only wealthier miners can afford, thereby threating node diversity and decentralization. The other key factor deciding the arithmetic OPS rate is the block size. Rather than measuring blocks in terms of bytes, block size is measured by the maximum amount of gas allocated for a block. Since gas is a unit of measure for the computational effort required to execute certain operations, the gas limit measures a block's maximum computational effort, where gas required per operation is specified by gas consumption rate G, and where
For example before its gas limit and OPS rate increase in April of 2021, the EVM had a Gas Limit of 12.5M, a 12 second Block Time, and a consumption rate G=3 per fixed integer operation [85], so that
This instruction processing rate is quite slow by computing standards, being comparable to that of the IBM System/360 computer of 1965. By contrast, today's readily available graphics processors for gaming perform floating point (not fixed integer) calculations at rates of 30 TFLOPs, eight order-of-magnitude faster than EVM based dApps. While it may appear obvious to improve throughput, the gas limit can be increased to accommodate larger blocks, the risk that a significant number of nodes will be unable to complete the job within the allocated block time grows exponentially with linear increases in block size. Incomplete block validations must be discarded and repeated, thereby increasing gas fees and delaying the completion of a smart contract's transaction.
Smart Contracts (dApps): Rather than simply storing passive data, 2nd generation blockchains (and beyond) support decentralized applications (dApps) called smart contracts. A smart contract comprises software-based if-then-else conditional logic able to react to changes in state variables specified in the contract including time & dates, trades, prices, token supplies, and prior transactions. Smart contracts can also perform fixed integer arithmetic operations, but cannot perform floating point calculations.
Blockchains enable smart contracts in several ways including (i) providing a decentralized platform to store and distribute dApps to users, (ii) facilitating a live database recording transactions as updates to the newest most-current instance of the contract, (iii) providing a consensus mechanism to validate new contract instantiations, and (iv) operating as a blockchain virtual machine (BCVM) needed to execute smart contract instructions.
Inspired by the concept of decentralization first demonstrated by the file sharing program BitTorrent combined with a deep appreciation in the frugal application of distributed processing using nodes of limited computing capability (i.e. performance comparable to ES-EVM), the notion of an “unstoppable computer” lacking any dedicated hardware platform was born. This pioneering proof-of-concept in decentralized applications, the Ethereum Virtual Machine or EVM, proved to be far more impactful than anyone could have foreseen.
In fact, the fundamental design of nearly all blockchain virtual machines remains essentially unchanged from its Ethereum blockchain progenitor. Architecturally, as depicted in
As depicted, realization of an Ethereum virtual machine comprises three elements, namely (i) an immutable dApp 20a comprising EVM code 21 stored on the blockchain; (ii) a world state σ 20b maintained in an updated yet persistent state as “account storage”; and (iii) a machine state μ 20c comprising a volatile instance of the Ethereum virtual machine existing temporarily during transactional processing.
The computing kernel of EVM comprises software stored on the Ethereum blockchain as the EVM's operating system. Using the blockchain as virtual read only memory (virtual ROM), this EVM OS code 21 cannot be revised or edited except by launching updates as entirely new instances on the blockchain. Even then, the prior version remains perpetually available. In this manner, the Ethereum blockchain functions as a trustworthy platform to distribute software, in this case the Ethereum Virtual Machine. To invoke the EVM, a smart contract written in the Javascript like language called Solidity make a function call to the EVM OS.
Upon its launch on the Ethereum network of nodes, the EVM OS collects variables data from its designated decentralized account storage representing a world state σ. Loading this data into the EVM allows the system to catch up with the events that occurred during its hibernation, i.e. to make it current. 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 transferred from account storage into the EVM OS as a starting point for processing.
Data in the account storage 26 is filed sequentially in key-value pairs comprising a cryptographic key 32-bytes wide identifying each state variable 27a and a corresponding current value of the data 27b, also 32B wide. Because this data is always loaded from account storage 26 when booting up the EVM OS and rewritten at the commencement of a job, the world state μ data is described as “persistent”.
At the heart of EVM OS executable code is its machine state μ 20b, a clocked state machine comprising a program counter 22, a gas gauge 23, a program stack 24, and scratch pad memory 25 operating as virtual RAM. During EVM launch, operating instructions are loaded from virtual ROM while present state information is loaded from account storage. Transfers into the state machine occur in 32B data bursts and stored in either 1B wide memory or pushed onto the 32B wide program stack. The machine state μ is volatile, and does not survive beyond execution of a smart contract except via data written to storage as world state σ 20c.
Like RPN-based programs and calculators, the program stack in machine state μ comprises a mix of data and ordered operating instructions, executed sequentially with each advance in the program counter. Completed operations are “popped” off the top of the program stack as execution continues until either the task is complete or gas runs out. Careful programming of smart contracts for the EVM state machine is warranted to avoid transactions exceeding the maximum allowed block size. Block overflows produce a fault condition leading to permanent loss of the mining efforts for the block, failed program execution, incomplete transactions, and possibly indeterminate states. Looping, hold states, and floating point arithmetic operations are also forbidden as there is no way to determine a priori if the program step will compete or exceed the Gas Limit or Block Time.
Finally special care must be given to ensure smart contracts executed on the EVM are confirmed to be bug free. Operations writing data to an improper address or contracts stuck in a suspended state can lead to an unrecoverable loss of assets.
Operation of the EVM is only exemplary. The implementation of any blockchain virtual machine is chain specific employing 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, and others. Some of the foregoing blockchains actually comprise blockchain platforms for hosting client customized virtual machines and networks.
One such platform is HyperLedger, an umbrella project for open-source blockchains of the Linux Foundation with major backing from IBM and SAP-Ariba. Frameworks developed atop HyperLedger include Hyperledger Fabric, Hyperledger Iroha, Hyperledger Sawtooth, and Hyperledger Besu plus a large array of developer tools.
Another platform for blockchain development is Polkadot. Created by Ethereum cofounder and developer of Solidity, Gavin Wood, Polkadot is intended as a development ecosphere for blockchains. An integral component of this system is Relay-Chain, an integration tool supporting network interoperability of parachains, parathreads, and sharding, methods allowing developers to create their own blockchains supporting customized governance and tokens while supporting rapid processing and high transactional throughputs.
One such smart contract platform developed on Polkadot is Moonbeam, an Ethereum compatible network allowing developers to deploy existing Solidity-based smart contracts and associated dApps to Moonbeam without major changes. By porting Solidity dApps to Moonbeam on Polkadot, purported beneficial performance improvements over Ethereum hosting include reduced costs and higher transactional throughput.
Smart contracts also play a special role in creating, distributing, and trading digital assets called tokens including both fungible and nonfungible tokens (NFTs) described here below.
Crypto & DeFi Transactions. Blockchains support a variety of digital assets and their transactions. Example include chain-native cryptocurrencies like BTC and ETH, fungible utility and security tokens such as USD for a variety of funding, investing and commercial purposes, and non-fungible tokens (NFTs) used for acquiring and trading collectibles with limited edition content. A smart contract enables unrelated parties to engage in shared activities such as trading (swapping), lending (staking), borrowing, and market making (liquidity providing). It can also be used to autonomously generate new token offerings.
Like a group of individuals pooling money to buy lottery tickets together as a collective, a smart contract can be used to anonymously pool investments from a group of unrelated investors and venture capitalists to jointly fund a project; invest in or fund an index or synthetic fund; or capitalize a DAO or corporation. A smart contract enabling shared investment from unrelated parties is referred to as decentralized finance pool, a DeFi pool, or a liquidity pool[100]. The DeFi pool is virtual and decentralized, not physically existing in any one server, device, website, storage device, or located in a specific country or domicile. A DeFi pool is therefore simply a smart contract shared by investors.
The platform or website hosting and granting access to the DeFi pool is not a participant in the pool. Existing at arms length from the pool's operation, the host platform is nothing but a link or user interface (UI/UX) created to access the pool's smart contract. All terms and conditions for the pool are defined by its smart contract not its platform. As such, no platform or device has any control whatsoever over the terms and conditions of trading in the pool and among its participants. A DeFi pool therefore is peer-to-peer (P2P) commerce.
Tokens created by the smart contract are autonomously generated algorithmically by, for, and on behalf of the pool's participants. Except in the case of a corporate token offering, tokens issued by a DeFi pool in a token generation event (TGE) have no issuer. Since there is no issuer, a TGE does not meet the legal definition of a securities offering. This subtle but important distinction that token issuance without an issuer does not constitute an “offering” will remain a hotly contested legal matter for the foreseeable future.
Because there is no central authority able to regulate autonomously executed smart contracts, investors and token traders are advised to consider DeFi trading in the context of caveat emptor (buyer beware) and to take extra precautions to ensure that a smart contract is bug free and its DeFi pool represents a legitimate project or development. In the case of corporate offerings, a appropriate degree of due diligence is advised, the same as suggested in the case of buying private and public equities.
Cryptocosm Summarized: Given the foregoing in-depth discussion, several major high-level take-aways can be surmised.
What Are DeFi Tokens?: Broadly speaking digital tokens are cryptographic tokens created by the execution of a smart contract on a public or private blockchain. Such tokens can be
The first two examples, government issued digital money and private access tokens are not decentralized and therefore beyond the purview of this whitepaper. The third bullet, non-fungible tokens comprise their own DeFi token class. Unlike fungible tokens which comprise a population of indistinguishable digital tokens of equal value useful in commerce, non-fungible tokens exhibit properties of uniqueness, identity, and ownership (royalty rights).
Trading of NFTs in various blockchain specific marketplaces and communities requires extensive cross-chain transactions whereby gas fees, not utility, become a significant factor.
The fourth bullet, decentralized fungible digital assets known as DeFi tokens represents an enormously broad and expanding asset class. Deployed on public permissionless blockchains, DeFi tokens are generated not by puzzle solving, but by executing smart contracts—dApps hosted on one or more blockchain virtual machines (BCVMs).
One distinguishing difference between DeFi tokens and cryptocurrency is their “total supply”. Unlike cryptocurrency where new coins can be mined at any time (even at a loss), the total supply of a token at its launch is fixed in quantity and cannot be adjusted afterwards. DeFi tokens come in a variety of forms including:
Crypto Cash Equivalents: The first two bullet items, i.e. cryptocurrency wraps and stablecoins, (herein referred to simply as “crypto”) operate as crypto cash equivalents in the cryptocosm. These assets have a defined value at the time of a trade and therefore can be used in swapping a publicly tradable asset of defined value for a private or publicly traded token of speculative future value. The worth of crypto cash equivalents at the time of a DeFi token trade are well defined by high-volume global markets. Some tokens are further collateralized by non-cryptographic assets such as gold or fiat currency to combat volatility. Such tokens, referred to as stablecoins, carry value pegged to its fungible counterpart.
For example, Tether is a stable coin pegged to the United States dollar whereby value {1 USD}≈value {1 $USD}. Stablecoins bridge the token and cryptocurrency worlds as they may be traded on digital currency exchanges and also be used in the autonomous execution of a smart contract. In the commercial press, stablecoins are often incorrectly referred to as cryptocurrency (akin to BTC and ETH) because they perform the functions of storing value and transacting commerce. Stablecoins are not however chain-native cryptocurrencies, they are tokens, which is the reason why they can be used in smart contracts without first wrapping them (when BTC and ETH cannot).
For example, the US dollar based stablecoins USD, USDC, DAI and BUSD are pegged to the United State dollar at fixed 1:1 conversion ratio (within some small slippage range). Other stablecoins are now being issued pegged to the Euro, the British pound, the Japanese Yen, and the Singapore dollar. In the case of a highly-traded volatile currency like ETH, its cash equivalent value varies constantly. As such, during any DeFi transaction, the Ether must be valued at its “spot” trade price—its market value frozen at a specific moment or window in time. To avoid any misunderstandings, a particular public digital currency exchange, e.g. Binance, is specified as the exchange on which reference trading price is based.
Chain-native cryptocurrency like ETH suffers several disadvantages compared to tokens. Firstly, they are locked to their own blockchain and are not interoperable across chains. Secondly, they are not ERC-20 compatible meaning they cannot be used to transact trades by smart contract. Thirdly, as a liquid, tradable, and fungible cryptocurrency they cannot be locked or held as collateral except by transferring them to a custodial wallet (wallets having private keys controlled by another party).
The solution to this quandary is tokenization—converting chain-native cryptocurrency into tokens. The token conversion process, turning fungible assets into smart-contract compatible tokens, is performed prior to engaging in any dApp based commerce, and therefore does not affect real-time transactional throughput. The process of tokenizing cryptocurrency is called “wrapping”. Token wrapping involves locking an asset into a smart contract and generating a specified number of corresponding tokens. The aggregate worth of these tokens at inception equals the value of the underlying asset securing the tokens. Token wraps are thereby mirrors of the underlying asset used to create them, whose value depends on the asset collateralizing the token and on the quality of the smart contract used to create them. Token wraps are therefore also called tokenized cryptocurrency.
Any crypto asset can be wrapped. Token wraps of cryptocurrency are frequently identified by attaching the prefix “W” to the cryptocurrency's symbol name. For example WETH is any wrap of Ether, WBTC is Bitcoin wrap, and so on. For convenience, token wraps are generally issued on a 1:1 basis with their underlying asset and maintain a constant price ratio despite market fluctuations in the asset base's value. In other words, if the price of ETH rises, so too does WETH.
For example, the value of Bitcoin wrap is equal to the real-time value of Bitcoin, price {1 WBTC}≈price {1 BTC}. Similarly on the Ethereum network, price {1 WETH}≈price {1 ETH}. Because the price ratios of tokenized cryptocurrencies are fixed relative to their underlying assets and since it is generally understood that a smart contract can only transact tokens, it is commonplace to exclude the W prefix when referring to wrapped cryptocurrencies, and to casually refer to cryptocurrencies and their token counterparts as equivalent.
The process of tokenizing an asset through wrapping involves execution of a smart contract. In the process of wrapping shown in
Technical standards for token wraps vary but generally mandate the method in which tokens are transferred and how users can access data regarding a particular token. The standards specify the minimum required token data need to facilitate trade analytics, exchange tokens, or to transfer them into or from a crypto-wallet. The Ethereum blockchain, for example, supports a number of technical standards for tokens, the most common one being ERC-20 comprising a standardized API[104] used for fungible tokens including transfer, payment, and balance-tracking functionalities. The acronym ERC, meaning Ethereum Request for Comments, refers to information requests, i.e. data exchange, needed to successfully process pending token transactions.
Fungible DeFi Tokens: The generation of fungible tokens by smart contract hosted on a permissionless blockchain provides a means by which new tokens are created without the need for mining and wrapping existing cryptocurrency. In this regard, executing a smart contract to generate tokens is ecologically sustainable (green) compared to PoW cryptocurrency mining. During the token generation process, a smart contract is authored specifying the type and quantity of tokens to be minted, then executed by uploading the smart contract to its intended host blockchain.
Once generated, DeFi tokens are sold (swapped) to investors. Concurrently, or in phases, the purchased tokens are distributed to investors through a process called a token launch. DeFi token launches may be executed on behalf of a variety of token sponsors, including
Proceeds of token sales are directed to its sponsor which in turn has an implicit (or explicit) obligation to deliver a product or service for investment received. For example, a corporation is obligated to deliver a product or service; a project is committed to deliver working software or dApps, a trading pool is obligated to deliver a means for people to swap, stake, or borrow a specified lists of tradable assets, and an artist must deliver their creative works (or rights thereto) to collectors. Token offerings lacking defined deliverables are considered scams or fraud.
Since the tokens are issued via a permissionless blockchain, the crypto-economy considers the token launch as decentralized finance. Token distribution during a launch can be executed in a variety of mechanisms, namely
In all of the above cases (but airdrops), token distribution is limited to professional investors who have passed rigid KYC/AML verification generally as executed by a decentralized exchange (DEX) or a centralized digital currency exchange (DCX). General partners and investors in venture capital (VC) funds are also considered as qualified professional investors. Suspiciously absent from the foregoing list is an initial coin offering or ICO, a process analogous to a initial public offering (IPO) for equities where a company sells tokens directly to the unqualified public.
Following a brief but intense period of ICOs between 2017 and 2019, courts ruled that many ICO token issuances represented unlicensed public security offerings. It was also determined that many issuers failed to perform sufficient identity verifications to confidently establish candidates as accredited investors. Expectedly, token sales made directly to the general public are now considered verboten in many countries and jurisdictions.
Even so, out of a preponderance of caution, many companies issuing tokens restrict their distribution, excluding nations banning or limiting the sale of digital assets and cryptocurrencies such as the United States of America and its territories, Canada, the United Kingdom, and the Peoples Republic of China (including Hong Kong). Investors should be mindful as to applicable laws in their country of citizenship and residence.
As a final point it would be remiss not to mention that the act of creating new tokens does not by itself represent a token generation event. There is no requirement to issue generated tokens at the time of the token's genesis event. In fact, there is no requirement to ever distribute them. For example, an engineering project seeking funding through a DeFi token offering may, for whatever reason, change plans and cancel their offering, generating but never distributing their tokens. If so, the smart contract goes abandoned, and perpetually persists on the blockchain without ever executing a token sale or a single transfer.
DeFi Token Standards: To ensure ubiquitous interchangeability, fungible DeFi tokens must comply with agreed standards specific to a blockchain. Two of the most common standards include Ethereum's ERC-20 standard and Binance's BEP-20 standard. These standards specify key factors determining an offering's tokenomics. The ERC-20 standard for Ethereum specifies six mandatory and three optional function calls of argument (*), namely:
ERC functions provide information needed for smart contracts to reliably perform prescribed tasks (such as transferring assets to wallets or to other smart contracts). Although tokens can be transferred directly using the transfer (*) function, sending digital assets manually implicitly carries risks. For example, transferring tokens to a smart contract incapable to receive them will result in irrevocable loss, one where the sent tokens will be credited to the receiver's address and the transaction recorded as “complete, but where the recipient's contract can't recognize them.
For exemplary purposes, numerous ERC-20 compliant tokens include Chainlink (LINK), Shiba Inu (SHIB), OmiseGO (OMG), EOS, Tron (TRX), ICON (ICX), Maker (MKR), Basic attention token (BAT), Ox (ZRX), Quant (QNT), IOT Chain (ITC), and Jasmy. The stablecoins Tether (USN), USDC, Dai, and BUSD are also ERC-20 compliant tokens. Ironically, the Ethereum blockchain's native cryptocurrency ETH is not.
Smart contracts using ERC-20 compliant tokens can reduce the risk of errors by invoking certain proofing and compatibility checks before executing a transaction, for example using the function calls approve (*) and transferFrom (*) transfer tokens pursuant to meeting defined criteria. Even so, ERC-20 compliant tokens are far from foolproof and subject to numerous failure modes.
To circumvent these issues, alternative token standards to ERC-20 have been developed including backward compatible ERC-223 designed to prevent loss of funds during transfers. Other notable options include ERC-721 for non-fungible tokens (NTFs), ERC-809 for renting rival NTFs, and ERC-1238 for non-transferable tokens or badges. Despite offering enhanced features and benefits, widescale adoption of these alternate token standards remains elusive, and ERC-20 retains its unrivaled hegemony on the Ethereum blockchain.
Similar standards, sometimes with extended features exist on other blockchains like BEP-20 on the Binance smart chain, and evolving standards on newer blockchain networks. It should be cautioned, regardless of the asset traded by smart contract transactions on a given blockchain network and BCVM, the gas required to fund the community of validators executing the smart contract is specific to each blockchain. So while execution of a EVM smart contract transacting ERC-20 tokens requires ETH for gas fees, execution of a BSC smart contract transacting BEP-20 tokens requires the Binance BNB token, not ETH for gas.
Features of Tokens: The value and utility of tokens are not simply intended to emulate a fungible replacement for fiat currency. Cryptocurrency can do that. As defined by their role, purpose, and features, tokens can do things that neither fiat nor cryptocurrency can. Tokens can, for instance, can carry state information, passing genetic-like credentials conferring privilege, rights, benefits, preference, privity, privacy, or access despite no direct involvement between transacting parties.
Like an exclusive golf club membership, tokens can enable unique privileges to their holders by granting access to products, content, or services unavailable without the token. For example, tokens issued to an entertainer's fan club members can enable preferred seating unique to their most faithful followers. Tokens can also be used to provide economic incentives to users, allowing them to receive discounts for purchases, earn gifts, or upgrade to a nicer hotel room.
For example, online music purchases using tokens may receive bonus songs not included in an album. Accumulating tokens may earn free online streaming services of movies or music. Similar to airline miles, tokens can also be used to access unused inventory (like an empty business class seat) at discounts or for free. Unlike air miles which are administered by an airline or group of carriers issuing the mileage, however, tokens do not involve staff or costs to administer or distribute. In DeFi, there is no central authority issuing tokens or controlling distribution.
Another uniqueness of fungible tokens is their indistinguishability. Tokens of a specific type (e.g. USD, USDC, aIOT, UNI, YFI, etc.) are all identical in characteristics to all other tokens having the same symbol and therefore are indistinguishable from one another. A crypto wallet containing enterprise tokens cannot differentiate which tokens came from earlier purchases, which ones were acquired later at a higher price, and which ones were received free via a promotional distribution, i.e. a crypto airdrop. ERC-20 tokens do not carry an identifying code defining their identity or able to register its owner like stock certificates do.
Because of indistinguishability, tokens do not bestow personal ownership rights or involve identity registration. Tokens used for riding a train or bus do not have the rider's name on them. Anyone can use them. Accordingly, tokens offer the convenience of transferability, easily swapped among friends, bartered for favors, or donated for charitable purposes. Indistinguishability has one downside—it is impossible to determine if a token has been stolen and from whom. For this reason, the security and privacy provisions of crypto wallets holding tokens are of paramount importance to protect token assets from cybertheft.
Tokens can also carry economic value. Like chain-native cryptocurrency, ERC-20 compliant tokens created by wrapping a cryptocurrency (generically referred to as WETH), can be used in trading in crypto commerce in lieu of ETH or BTC. Unlike non-token cryptocurrencies, smart contracts enable tokens to facilitate conditional properties such as locking, pegged pricing, bonus awards, conditional releases, etc. not possible with pure cryptocurrency. For example, an airdrop of BTC enables its recipient to immediately trade their cryptocurrency while a token airdrop can remain locked for a defined time or until a specific condition is met. As such, tokens can be used to encourage behavior or incentivize long-term participation in a pool or business.
Tokens can also grant privilege—facilitating access to a product, service, or preference for its holder. Operating like a membership pass to participating businesses, a token holder can gain access to a venue, receive beneficial pricing, or request special privileges reserved for elite token types, e.g. access to a hotel's presidential suite, book a private box at a sporting event, schedule a post-show meet-and-greet with a performing artist, request an exclusive VIP table held in reserve at a 5-star restaurant, etc. As mentioned previously, tokens conferring benefits with undefined economic value are referred to as NFTs, an acronym for non fungible tokens. The benefits of NFTs, e.g. ownership, are not limited to non-cash transactions. Hybrid tokens may combine NFT features with embedded value.
Another unique capability of tokens compared to cryptocurrency is awareness. The trading of dumb cryptocurrency is unconditional. If the crypto coin is valid it can be immediately transferred or sold irrespective of economic conditions or the consequence of their trades. Tokens in contrast can solicit and consider off-chain conditions in managing transactions. By employing blockchain oracles to import information of on-chain and off-chain events, smart contracts can dynamically react, or using artificial intelligence even adapt, to changing economic and environmental conditions including prices, dates, volumes, etc.
For example, smart contracts can limit a token's use for services only in defined GPS regions or on specific cellular networks, thereby ensuring compliance with local legal ordinances. A smart contract may autonomously prevent or limit swapping (buying or selling) in times of volatile trading or price crashes. Conditional value is of particular benefit in commerce especially in realizing stable coins—tokens which maintain a fixed price ratio to a commodity (such as gold) or which are pegged at a pre-defined ratio to the value of a specific fiat currency. USD for example is a token whose commercial price is pegged (within some nominal range) to the United States dollar (USD).
Transacting DeFi Tokens: DeFi token transactions occur in three major phases of an token's lifecycle, namely
Creating a new token, i.e. token generation, involves executing a smart contract defining the type and properties of the issued token. Smart contract authoring is a critical element in properly executing any DeFi offering as the launching of a smart contract live is an irrevocable event—once done it cannot be undone. Specifically terms of a smart contract cannot be changed after-the-fact and mistakes cannot be removed. The consequences of a badly written smart contract ranges widely from unnecessarily incurring users excessive gas fees to causing a complete loss of invested capital. Failure root-causes include arithmetic errors, logic errors, improper function calls, a stuck program counter (frozen states), incomplete or misdirected transfers, and more.
In essence, the tokenomics of an token offering and its execution are inexorably defined by its smart contract. The number of tokens generated, i.e. the token total supply, cannot be increased at a later date. Locked tokens cannot be unlocked unless the conditions specified in the smart contract occur, e.g. in accordance with a defined vesting schedule. Unlocked tokens cannot be locked after the fact and vesting schedules, once defined, cannot be altered. So the creation of a reliable error-free smart contract is fundamental to a successful token issuance. Smart contracts represent a particular type of software called a decentralized application or “dApp”.
Developing dApps: Writing new smart contracts is the role of a dApp developer, a team of software programmers familiar with blockchain-based decentralized applications. Decentralized application programming is significantly different than programming for a smart phone, personal computer, cloud server, web server, IOT device, or connected vehicle.
In conventional computing, the application program runs on top of an operating system which locally delivers dedicated resources including hardware comprising one or many compute engines, cache memory, and non-volatile storage. The hardware host resources are owned or leased by the software owner. When a user signs a service agreement with Amazon or Google web services, the contract is similar to a car rental in that the client owns the right to use the leased hardware for the specified term just as though they bought a server themselves, irrespective of which server in their cloud actually performs the tasks on any given time or day.
When a programmer has unlimited access to dedicated hardware, the software programs it hosts can be incredibly inefficient executing instructions that serve no purpose and storing data that isn't needed, because it simply is too small a concern to care about. Web programmers are particularly notorious for creating inefficient code based on pre-fabricated HTML templates, with compiled programs bloated by all their predecessor's dead-end coding contributions.
One field of engineering where sloppy programming doesn't work is in software for real-time communication devices and services. In real time systems, inefficient code affects system performance. Doing unnecessary calculations slows the system's ability to transport data adversely impacting the network's latency and throughput, i.e. data bandwidth. In professional radio communication systems, for example, propagation delays not only affect network performance metrics, but may result in complete and irrevocable loss of packets, payloads, and content. Not surprisingly, only the best programmers are capable of real time programming.
Smart contracts may be written in any number of computer languages, varying with both intended use and the targeted blockchain virtual machine host for contract execution. Programming languages used by various blockchain virtual machines and their blockchain users are listed here:
Many in the above list comprise general-purpose high level programming languages derived from C or Java. Other commonly used smart contract development include:
Of the foregoing, Solidity, a Java derivative language, controls the lion share of the smart contract programming market as it is the primary language employed on Ethereum EVM and Binance BSC. Rust appears to be a rapidly growing alternative used by both HyperLedger and Solana. Other blockchains claim to be agnostic to the languages employed in their smart contract execution. They include the Kimodo, Multichain, NEM, OpenChain, and Polkadot networks.
Efficient bug-free dApp development requires extensive experience to circumnavigate programming pitfalls. Accidental arithmetic errors, fixed integer decimal placement, hidden loops, undetected wait states, and incomplete transfers can result in catastrophic losses to investors, affecting the success of a project or the survival of a company. Given the plethora of programming languages, cross chain launches are especially complex and prone to execution risks. Poorly architected code, even if bug-free can still suffer from excessive gas fees or slow execution during high traffic events resulting in opportunity loss for investors.
One way to avoid badly implemented or buggy smart contracts is to employ an autonomous smart contract authoring system. But writing a dApp which authors bug-free smart contracts requires even greater skills than manually writing a smart contract. Only limited enclaves of skilled developers exist across the world able to master such challenges.
Executing dApps: A smart contract launched onto its host blockchain becomes immediately available for distribution and ready for use. As illustrated in
In greater detail, the smart contract lineage is traced from its parent to its last entry on the blockchain, i.e. its most current instance, using a peer-validated Merkel tree (aka Merkel chain). Each instance of the smart contract is recorded on the blockchain sequentially using a time-stamped and peer-validated block. Like chain-native cryptocurrency, blockchain processing of smart contracts is executed by jurors to validate each new entry.
Dissimilar from cryptocurrency mining, however, miners validating smart contracts affirm the block's authenticity, but not its content. During validation, jurors do not (and often can not) interpret the meaning or functions contained within the smart contract. For reasons of security and privacy for example, portions of a smart contract can be hashed or encrypted and may not be decipherable by any trader except members within a defined pool. In order to ensure a contract is prepared properly, it is critical that only the most recent version of the smart contract is used as the starting point in writing a new contract.
The latest instance of a smart contract includes the most up-to-date contractual information, i.e. parametrics, needed to synthesize accurate executable code. Parametrics define conditional information that change over time needed to execute the smart contract, including date, time, interest rates, number and type of tokens in the pool, locking mechanisms, etc. For example, before a new contract can be written and recorded for swapping two tokens, the last smart contract must confirm enough tokens exist to execute the transaction. If a buyer tries to purchase more tokens than exist in the pool the contract cannot be executed. If a trader wants to execute a smart contract on the Ethereum blockchain using USN, the trader's wallet must contain sufficient ETH for the gas fee or the transaction cannot be processed.
Although program execution appears as a simple chronological sequence, to maximize throughput of the network smart contracts are constructed in hierarchical layers (subroutine calls) to avoid unnecessary consensus validations.
Unlike the Internet's OSI layers, no standardized nomenclature for blockchains exist at this time. Regardless of terminology, the lowest layer in the blockchain stack is the infrastructure or network Layer 0 used to deliver network 44 and communication services to the blockchain 33. Blockchain Layer 0 (network layer 42a) provides services to blockchain Layer 1, the protocol or implementation layer 42b which manages data 26, the mining and storage of block content and chain-native cryptocurrency 34a; and system operations including the blockchain virtual machine (BCVM) 20 and consensus mechanisms 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, the transaction or application layer 42c used to execute dApps, smart contracts 37, and token 50b generation on the BCVM, providing scalability, and offloading tasks otherwise consuming system bandwidth on blockchain layer 1 bandwidth. Layer 2 implementations may include lightweight computing capability called “state channels” that does not require the same frequency of validation as blockchain Layer 1 processes. In this regard, blockchain Layer 2 is faster but less secure than Layer 1. Note that the term “application layer’ for layer 2 in the blockchain stack is not the same thing as Application Layer 7 in the Internet's TCP/IP communication protocol (the Internet supports all blockchain processing). Blockchain Layer 2 which relies on Layer 1 similarly provides services to blockchain Layer 3, the so-called Aggregation layer. The purpose of the aggregation layer is to bundle applications and services of Layer 2 for the convenience of users. For example despite representing different applications, staking (lending) and borrowing may, for customer convenience be bundled into a unified service sharing a single DeFi pool.
Notably, by processing tasks on a single blockchain layer or spreading them across multiple layers impacts performance, efficiency and security. These tradeoffs led Vitalik Buterin, the founder of Ethereum to coin the phrase “The Blockchain Trilemma” in recognition of a developer's challenge that implementing blockchain processing with fewer validation checks improves speed but invariably compromises decentralization and security, considering if a network hosting a smart contract is
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. As such, consistent high-quality smart contract programming is necessary to avoid hacks and failures in decentralized finance transactions.
DeFi Pools: As illustrated in
In one class of smart contract used to issue tokens (called a token launch), DeFi tokens 50 are generated and released into the wild in accordance with some defined schedule or set of conditions. Investors may acquire tokens as a direct purchase from the issuer, or alternatively by executing a token swap in a DeFi pool. In the context of a token launch today, a “DeFi pool” 46 is a smart contract facilitating the exchange of two digital assets—the newly generated DeFi token and a crypto cash equivalent (such as USDC, BUSD, WETH, etc.).
Unlike a DeFi trading pool (where either asset in the pool may be bought or sold at will), during a token launch the newly issued token can only be purchased, not sold. Such a DeFi pool may be referred to as a launch pad or an issuing pool. Two methods exist for an investor to acquire a newly minted token in private token presale—either by a direct purchase or through a DeFi pool. In a direct purchase after completing KYC/AML and pursuant to applicable regulatory statutes, a buyer purchases directly from the issuer. In DeFi, a prospective investor opens an autonomous transactional interface called a protocol and swaps a specified amount of crypto cash for the token being issued. In high-quality token offerings, demand generally exceeds supply.
As such, the maximum purchase quantity is unavoidably limited, i.e. allocated, on a per-person basis. Transactionally, a DeFi pool functions like a bank-less bank with “products” offering new issuances to venture capital, lending to stakers, borrowing for debtors, currency exchange (token swapping) for traders, and liquidity providing opportunities to market makers. Although a DeFi pool offers services much like a business entity, the pool itself is ethereal. There is no owner, operator, guarantor, or legal entity controlling its actions or defining its quiddity (its unique essence). In this regard, the operation of a DeFi pool is autonomous, and its existence, virtual. DeFi is diffuse in nature, with no physical presence within a single device, server, location, country, or legal domicile. If something goes wrong, there is no one to sue, and no one to blame but oneself.
Experientially, users interact with the DeFi pool using what appears to be a web interface. In reality, a DeFi user interface (UI) invokes an application program connecting their crypto wallet directly to the Ethereum, Binance, or other host blockchain. For the sake of security and privacy, no web interface should act as a data conduit in any crypto transaction. Web intermediaries cannot be trusted as they can easily capture, steal, and profiteer from access to a client's security credentials and private keys exchanged during a transaction, including the risk of wallet theft. Decentralized transactions thereby depend on trustless autonomous operation—not relying on anyone or anything to execute a transaction. Although theoretically, traders can write their own smart contracts to engage in transactions within a DeFi pool, in practice smart contracts are not written from scratch but instead are based on a contractual template called a protocol to define the specifics of a pool.
DeFi Protocols: Smart contracts play two major roles in supporting investors and entrepreneurs in today's rapidly evolving crypto-economy, specifically to facilitate
Although both of these functions can be performed using a hard-coded smart contract, custom dApp development is slow and prone to errors. The alternative is to employ a transactional protocol for smart contract authoring. A transactional protocol, or simply a protocol, refers to software that autonomously creates smart contracts in accordance with user instructions. Theoretically, a smart contract authoring program for DeFi trading should be able to support a diversity of common DeFi transactions. In practice, most available protocols are designed to operate as single-function automatons, capable of performing only a solitary dedicated task, for example:
Separating investing and trading activities into separate protocols, while easier for developers, creates a more confusing user interface and a degrades user experience. Moreover, numerous inadequacies in the design and programming of present-day DeFi protocols adversely impact traders flexibility in participating in a DeFi pool. These inadequacies has an especially significant impact on companies or projects seeking to launch their own tokens. Important unaddressed issues limiting today's protocols include the following:
With all the issuing pools being separate the process of purchasing the token is also inconvenient for investor 30 where payment with WETH involves transaction 53a, payment with USDT involves a separate transaction 53b, and payment with USDC involves transaction 53c, all with their own gas fees, even though the investor is only purchasing a single token 50c. Real world examples include the challenge of purchasing a token such as Jasmy with USDC instead of WETH requires changing DeFi pools. Similarly a SHIB-USD token pair cannot be mixed with a SHIB-BUSD pair, a SUSHI-WBTC pair cannot be pooled with a SUSHI-DAI pair, and so on. Aside from being terribly inconvenient for investors seeking to acquire tokens using a mix of cryptocurrencies and stablecoins, a rigid single token-pair DeFi pool forces 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 are unable to support multiple networks, let alone cross-chain transactions. For example, a token offering on Ethereum employs EVM specific smart contracts not usable on the Binance's network or BSC virtual machine. This forces investors to trade exclusively on a single network even if transaction times degrade or gas fees become prohibitive.
Beneficially, multi-chain support as shown in
Another missing features is the ability to intelligently minimize gas and transaction fees by employing minimum transaction algorithms in multi-swap trades.
Unlocked Tokens: A major issue plaguing DeFi investing today is the problem of early selling and insider rug-pulls. The early selling problem is intrinsic to a corrupt or badly-executed token launch by enterprise 51 where as shown in
The problem with the unauthorized selling is there is no way to distinguish tokens approved for sale from those legally traded. Indistinguishability is a fundamental characteristic of a fungible currency, meaning once tokens are unlocked there is no way to restrict their trade. A rug pull is therefore the inevitable consequence of issuing unlocked tokens at the time they were first generated. One alternative means by which and issuer may prevent presale token holders from early selling is through delayed distribution—withholding the issuance of tokens to their buyers till a later date. This option although effective, is problematic in that few investors will agree to a purchase without some collateral protecting their invested capital until the token transaction is fulfilled.
One especially problematic exploit is the pump-and-dump (P&D) exploit shown in
NFT Specific Issues: While fungible tokens based on ERC-20 and BEP-20 standards share many features, benefits, and deficiencies as NFT based on the ubiquitous ERC-721 standard, one major difference is that most decentralized finance, although involving transactions on multiple chains, do not involve cross chain trading. Once a USDT token is generated for the BSC network it is not transported for use on the EVM network, but instead is converted in an exchange first In contrast, the market for NFTs varies by interest group (e.g. antique cars, comic books, sports, fine art, music, etc.). For whatever reason these groups often are traded in communities residing on different blockchains.
Most NFTs for example are first minted on the Ethereum then transferred to one or more different networks for marketing and community sales. In this sense NFT are not simply multi-chain assets but operate transactionally across multiple networks, i.e. NFTs involve cross-chain transactions. To accomplish this feat, NFTs employ wrapping (the same technology used to tokenize chain-native cryptocurrency such as ETH) to be compatible with their target blockchain. An example of this process is shown in
As shown the original instance of NFT 88f created on EVM 33a was transferred to the BSC 33b network to become 88g because its prospective buyer was already trading on the Binance network. To transfer the NFT from Ethereum network to BSC, NFT 88f must first be wrapped so as to follow the protocols and code structure specific to the BSC smartchain. In other word the Ethereum based NFT is disguised as a Binance token by wrapping so it can operate in BSC 33b. After the sale, ownership of the NFT changes to create a new BSC token 88h. The process of wrapping and transferring a NFT from one blockchain to another is referred to as bridging.
Later however its owner wants to sell the same token to another buyer who happens to be on EVM 33a, the token is bridged to be compatible with EVM 33a not by reverting to its original form, but by wrapping token 88h with an Ethereum wrapper to generate BSC compatible NFT 88i comprising a wrap of a wrap. After selling the token to another Ethereum buyer, the new EVM token 88j is again wrapped and bridged to Polygon network 33c as NFT 88k, then sold to a new owner as 881, the rewrapped and bridged to another EVM buyer as token 88m. Token 88m therefore comprises a EVM wrap of a Polygon wrap of a EVM wrap of a BSC wrap of a EVM native NFT token, i.e. a wrap of a wrap of a wrap of a wrap, nested four layers deep. Although this is not a problem for traders who have no interest in accessing the NFT's true content, for collectors the situation is extremely problematic when unwrapping is needed.
Specifically as shown in
Considering the limited choices in DeFi protocols today and their intrinsic deficiencies, we are forced to concede that:
A fully autonomous smart contract authoring system capable of concurrently generating multiple smart contracts from a single source file for a variety of blockchain networks from a single source file is disclosed, eliminating the risk of random programming errors and transactional losses. In one embodiment, the autonomous generator of decentralized applications employs a library of network protocols and token standards validated by third party experts to eliminate systematic errors during smart contract authoring. The autonomous authoring program includes smart contracts for launching new tokens and creating a variety of DeFi pools, each with unique price and vesting terms, along with companion dApps for trading, a UIUX interface, an automatic market maker for maximizing pool liquidity, decentralized oracle for real time data needed to support rational trading practices.
In another embodiment, the autonomous smart contract authoring program generates multi-crypto pools able to support trading and remuneration using a variety of cryptocurrency wraps such as WETH and a number of stable coins such as USDT and BUSD. The disclosed AMM is furthermore capable of supporting balancing of all assets contained in any multi-crypto trading pool
In another embodiment, the autonomous software generates a pool comprising the token to be launched and a collateralized transaction kTx token acting as its proxy, whereby the kTx token distributed to investors is collateralized by an equal amount or value of enterprise tokens generated at its token generation event (TGE). The kTx tokens can later be used as proof of purchase and for redemption to claim the issued enterprise token in accordance with a smart contract defined autonomously executed vesting schedule. In another embodiment, the vesting schedule, price per token, and total supply of the issued token is arranged into distinct tranches as defined by the token issuer.
In another embodiment the kTx tokens may be hypothecated before its underlying collateral asset is vested and unlocked, either through a combined swapping and staking, combined swapping then staking, or by swapping or staking is collateralized token exchange (a KDEX) as a derivative market.
In another embodiment the autonomous smart contract authoring program is able to generate both fungible and non-fungible tokens, i.e. FTs and NFTs based on its input file and metadata.
In yet another embodiment the dApp is able to teleport NFTs cross chain without the need or hidden cost of nested wrapping, thereby facilitating a speedy cost efficient vehicle for cross chain trading.
This disclosure describes innovative advancements in the reliable processing of blockchain hosted data and decentralized applications (dApps) and their application for
Autonomous Smart Contract Authoring Ecosphere: As described previously, the rapid growth of decentralized finance (DeFi), the generation and distribution of fungible and non fungible tokens, and the issuance of autonomous permissionless DeFi pools for trading, investing, asset swapping, lending (staking), borrowing, and liquidity providing (market making) has prompted the emergence of a burgeoning industry in creating and launching decentralized applications (dApps) for the processing digital cryptographic assets using smart contracts executed on blockchain virtual machines.
As illustrated in
The obvious solution to the problem is to automatically generate the software, but no such standardized program generation code exists, particularly since each blockchain has the singular purpose of attracting the majority of clients onto their platform and to discourage use on other networks. For example the company Binance which host the Binance smartchain virtual machine using its own proprietary BEP-20 token standard has no interest making it easy for clients to use the networks offered by Polygon, Solana, or Cardano.
As such, this patent describes a pioneering autonomous smart contract authoring program for launching new dApps and tokens referred to herein as a LaunchBot authoring program. As depicted in
In order to perform error-free blockchain smart contract authoring, LaunchBot 71 must know the specifics of the offering—the offer's tokenomics as specified by input file 70 and also the unique requirements of the blockchain networks on which the toke is to be made available for trading. The network specific requirements including the software language employed (Solidity, Vyper, Simplicity, Vama, Obsidian, etc.) and various fungible token standards (ERC-20, BEP-20 etc.) or non-fungible token standards (ERC-721) are precisely specified in a network protocol library 83. Specific to a particular blockchain protocol, each executable smart contract 72 may also ne referred to as a protocol because it embeds instructions and code interpreted by a specific blockchain virtual machine (BCVM).
Although LaunchBot 71 program is able to author smart contracts from input file 70 made in accordance with network protocol library 83, executing the autonomously generated smart contract 72 requires interaction with additional decentralized applications supporting its operation. These utilities, while not able to conduct transactions on their own, gather and provide important information to smart contract 72 during its operation. As shown in
As disclosed herein, the combination of the integrated suite of interoperable decentralized applications comprising LaunchBot 71 authoring dApp, Protocol Library 83, UIUX dApp 82a, Oracle 82b dApp, AMM 82c dApp, and SwapBot 99 trading dApp, facilitate a turn-key solution, a Launchpad Ecosphere 80, to token launches, token trading, blockchain processing, and token life-cycle management (including vesting, distribution, staking, etc.).
The process of a multi-chain token launch using the disclosed Launchpad ecosphere 80 is illustrated in the flow chart of
In the context of clients of autonomously generated smart contracts, the term enterprise 50 is used in the broad definition which e.g. according to the Cambridge dictionary includes “an organization, esp. a business, or a difficult and important plan, esp. one that will earn money” (which covers pretty much anyone or a group of people seeking a common goal). In that regard, the list of enterprises wishing to offer tokens today, both fungible and NFTs, is an ever growing list including corporations, institutions, sports teams and franchises, VC funded projects, consortiums, infrastructure for blockchain commerce, investment and real estate portfolios, any group of investors wishing to sponsor DeFi pools as liquidity providers and market makers, universities, honorariums, estates and home offices, portfolio and fund managers, financial service providers, crypto-backed credit card companies, and more.
Unlike conventional business commerce, token issuers may comprise projects and DeFi pools having no legal standing, registration, or physical domicile such as decentralized autonomous organizations (DAOs). Musical and video artists; painters, sculptures, and graphical artists; curated art museums and auctions; architectural and interior design, online and play-to-earn gaming (P2E) and other art-business cross-over industries, like sports and sports gambling are uniquely suited as they include hybrid offers of fungible token offerings plus NFT collectables.
Other markets for fungible-NFT linked offerings include the use of fungible (ERC-20) token staking (locked deposits) not for interest income but to confer privileged access to upcoming and VIP only events and offerings, e.g. first-come-first-serve auctions, concert seats, meet-and-greets, exhibition access, upgrades, and more. Another developing application for NFT launches involves proof-of-authenticity important in the fine art and collectables market for paintings, luxury watches, baseball cards, vintage comic books and manga, rare tickets, books and more.
Tokenomics 70 may apply to both fungible and NFT offerings. The tokenomic term sheet for fungible token offerings includes the total token offering; the blockchain networks hosting the token; the vesting mechanism such as push vesting or proxy kTx redemption (described later); the vesting schedule and price per token by tranche; the method of payment (i.e. which crypto can be swapped on a specific network) including the option for multi-crypto pools; tradable versus locked tokens at TGE; as well as the IDOs, DEXs, CEXs, and DeFi pools supported in the offering. In contrast, non-fungible token (NFT) offering generated by Launchpad ecosphere 80 include owner and royalty considerations (to be embedded into issued ERC-721 tokens), vesting, and supported marketplaces. Regardless of whether an offering is a fungible or non-fungible token, or a mix thereof, the tokenomic model defined by tokenomics 70 long with the selected blockchains for the offering determine the smart contracts produced.
The interdependence of a multi-chain enterprise token offering authored by LaunchBot 71 based on tokenomics 70 and the applicable blockchain and token protocols from protocol library 83. As shown by example in
The same offering generated by LaunchBot 71 via smart contract 72b created for the Ethereum network (and the EVM virtual machine) employs ERC-20 tokens distributed through multiple channels including Seed Tranche 93a, Strategic Tranche 93b, IDO 93c and TGE 93d at the price-per-token (PPT) of $0.01, $0.025, $0.025, and $0.04 respectively. Although the Seed, Strategic, and IDO tranches share a common 6 month cliff vesting, the Seed tranche 93a has a 36-month vesting (2.8% per moth) while the Strategic and IDO tranches 93b and 93c each offer a more preferable 24 month vesting schedule (4.2% per month) as compensation for their higher selling price. The tokens offered by smart contract 72b on the EVM for the public offering TGE 93d are immediately unlocked with no vesting schedule. Unlike BSC smart contract 72a, execution of EVM smart contract is able to accept payment 92b using a wide range of ERC-20 tokens including (by example), WETH (Ether wrap), USDT, BUSD, and USDC. The list of tokens is exemplary and not intended to be limiting.
Another feature of Launchpad ecosphere 80 is the important role of its Oracle 82b. As illustrated in
Multi-crypto DeFi Pools: In conventional token offerings, remuneration for acquiring a token asset during swapping is facilitated through multiple DeFi pools comprising separate token-pairs, one for each form of payment. The practice of subdividing swap pools for a new token issuance into separate smart contracts is unwise and limiting as it reduces trading liquidity and greatly complicates trading transactions, adversely impacting a trader's user experience. If a trader selects a DeFi pool for its plentiful supply of enterprise tokens but with the wrong form of crypto as payment, they will be unable to complete the transaction.
The solution to such a quandary is the inventive feature described herein as a multi-crypto DeFi pool. Such a pool as depicted in
Pool 74a once balanced is shown in
Value (PRYS)=(# of PRYS)·PPT(PRYS)
Value (crypto)=(# of WETH)·PPT(ETH)+$1·(# of USDT+# of USDC+# of BUSD+# of Dai)
for cryptocurrency wrap WETH of value 34a, and stablecoins comprising USDT of value 75a, BUSD of value 75b, USDC of value 75c, and Dai of value 75d and where assuming for stablecoins PPT (USDT)≈PPT (USDC)≈PPT (BUSD) PPT (Dai)≈$1.0, the DeFi pool is balanced at
Value (PRYS)=Value (crypto)
and its total market cap is given by the total sum of its assets or
Value (pool 74a)=Value (PRYS)+Value (crypto)=2Value (PRYS)=2Value (crypto)
In operation, purchases and sales (swaps) of pool assets are managed by a software based trading bot dApp referred to herein as SwapBot 99 managing transfers to and from wallet 31 in accordance with the trade instructions received via UIUX 82a and recorded by smart contract 72. In the event that a traded asset has a time varying price per token, i.e. either enterprise token 73 or a cryptocurrency wrap (such as WETH 34e), the spot value of the assets are calculated based on real-time market data gather by Oracle 82b. Until enterprise token 73 lists on a private DEX or public exchange, its price-per-token is assumed to remain at its last traded price.
Despite any complexity in implementing smart contract 72 managing multi-crypto pool 74a, investor see the pool as a convenient means to obtain a newly issued enterprise token 73 using a variety of available crypto payment methods, thereby improving user experience while ensuring a pool's healthy liquidity. Through the disclosed inventive SwapBot 99 and UIUX 82a, access to buy or sell enterprise token 73 through multi-crypto DeFi pool 74a on several networks is easily facilitated through interface 95a shown graphically in
As shown in step 1 of
In step 3, the user selects the blockchain network 95c from a menu of available network options 83z downloaded from the protocol library in accordance with the LaunchBot's generation of the DeFi pool. If a specific currency is available at TGE, the crypto cannot be added later. In an alternative embodiment, the smart contract includes provisions for supporting all major currencies but UIUX 82a prevents access (making it possible to enable later). In the example shown Ethereum is selected as the network for the trade.
In step 4, the user selects the form of crypto payment 95d from a list of options 92b. In the example shown, since the Ethereum blockchain was chosen as the transaction's network, the ERC-20 version of USDT is selected for payment. If however the Binance network had been selected the USDT made available would be made in accordance with the BEP-20 standard, not ERC-20. Once the currency for payment 95d is selected, in step 5 the SwapBot reports the present currency balance 95e in the wallet. If in step 95q the crypto balance is sufficient the transaction may proceed. If not, a new currency must be selected in step 95d or the transaction cancelled altogether.
Continuing to step 6 in
In this manner UIUX 82a combined with SwapBot 99 is able to support token distribution for both issuing pools, i.e. when an enterprise is launching a new token, and trading pools supporting DeFi trading. The primary differences between these two cases is one of token locking and the role of AMM DeFi 82c. The difference is illustrated in
In reality the enterprise tokens are allocated into different tranches so that the token value is increasing as the offering proceeds. This effect is not included as it does not aid in explain the operation of the SwapBot. Later in pool 74h the inventory of enterprise tokens available for sale has dwindled in supply and value to 75 while the aggregate cash value collected by the enterprise through the offering now comprises the sum of asset values 34e plus 75a, 75b, and 75c, having a value approaching the original projected value 215.
In essence, in an issuing pool the SwapBot sells the newly issued enterprise token for crypto (cash equivalent) and does not replenish the token supply. Moreover, the major change in value assumed by this model is the change in the number of tokens and crypto in the pool and not market price fluctuations. After the offering is complete, the enterprise is free to receive the collected crypto to fund operations and development in accordance with stated use of proceeds.
By contrast, the use of the SwapBot in DeFi pool trading is completely different. As shown in this example pool 74m is funded by a liquidity provider to contain a set value of enterprise tokens 76 and an equal amount of value of crypto divided among various digital assets including WETH 34e, USDT 75a, BUSD, 75b, USDT 75c and Dai 75d. In such a case, both tokens and crypto each start with an aggregate asset value 215, so that the total pool value is the sum of the enterprise value plus an equal value of crypto, or double the value 215 of the issuing pool.
During trading depicted by pool 75n, the sale of enterprise tokens to the pool reduces the aggregate amount of crypto and increases the available amount of enterprise tokens 76 creating an imbalance between the two columns in the amount 75y. To rebalance the pool, investors acting as liquidity providers must rebalance the pool by either injecting capital into the pool in the amount of 75y in crypto, by selling some of the enterprise tokens in the market (i.e. outside the pool) and returning the net proceeds into the pool, or some combination thereof to ensure the pool remains balanced. While in pool 74n the crypto assets are lower than the tokens by an amount 75y, by contrast in pool 740 the converse is true where there is a shortage in enterprise tokens having an aggregate value 75z less than the crypto reserves. In such an instance investors must procure new enterprise tokens from the market and inject it into the pool using their own cash or by using a portion of the excess tokens to balance the pool.
In either case, to maintain liquidity for both buyers and sellers, the pool must be rebalanced till the asset values are equal irrespective as to whether the net value of the assets is greater than or less than the starting value 215. This is the job of the automatic market maker AMM 82c shown in
Each time a rebalancing occurs the DeFi Oracle 82b must ascertain the current market value of the pool's constituent assets base on current market information 84 and on-chain recorded transactions 33. The imbalance in value is sum of the number of tokens time its current price less the aggregate sum of all the crypto each valued at its market price as illustrated in
For example among the stablecoins, the volume and liquidity of USDT is by far greater than its peers. In contrast, Dai is a relatively small player in the stablecoin market. As shown in the table of Value Allocation Ranges, the AMM targets a USDT balance of 68% of the pools value with a slippage of approximately ±3.5%. The total amount of WETH 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: Important considerations in the tokenomics of a new token launch are the total token offering (fully diluted) and the circulating supply of tokens. To prevent rampant selling by insiders (rug pulls) or panic selling and to encourage holding a newly issued token for long term gains, it is important to limit the supply of unlocked tokens available for selling at or soon after the public release of a token, i.e. at its TGE (token generation event).
The problem of buy-sells is illustrated in the flow chart of
As soon as the token becomes available for public trading, the investor transfers unlocked token 126b to smart contract 125b, swapping it back into crypto 124b and then selling it in CEX exchange 123b for fiat money 122b and a quick profit. If the selling occurs when the trading volume of the token is low, even modest levels of selling can crash the selling price and irrevocably harm the perceived value of the token discouraging future investments.
Because the tokens are fungible, all issued tokens are identical, interchangeable and indistinguishable. As such it is impossible for some of the tokens issued to be locked while those used in the TGE public listing are unlocked and tradable. Either all the tokens are locked or al are unlocked. One solution to prevent early selling of presale tokens is simply not to distribute them, but simply to hold them in a dedicated enterprise wallet until a mutually acceptable date. While this solution appears trivial it creates a number of serious problems.
In particular, token investors generally are not the of people who trust in centralized authority—that's one reason they became DeFi traders, for its decentralization. Unremarkably they expect to receive proof-of-purchase at the time they procure their tokens. Having the issuer hold their tokens in a private wallet (for which they have no key) means they must trust the issuer will distribute the tokens at a later date (possibly months or years later) and that the issuer is responsible to manually execute the distribution process. Such a procedure is the antithesis of DeFi as it is neither autonomous nor permissionless. Manual processes are also not trustworthy but fraught with the potential for error or usurpation either through incompetence or malfeasance.
Another problem with manual distribution is its complexity and high cost. Every offering includes a combination of different tranches having their own vesting schedules. For example,
In order to provide confidence that token 73 distribution will occur as agreed, one approach is to execute the distribution through smart contracts 72, one per network, generated by the aforementioned LaunchBot 71 authoring system and certified by a third-party code validator (such as Certik) as compliant with a smart contract 72 defined vesting and distribution schedule using bug-free executable code. The complexity of multiple tranche multiple network token distribution is exemplified by the flow chart of
One exemplary vesting schedule comprising seven categories of unlocking schedules from 12 to 18 months with 0 to 12 month cliff vesting is represented graphically in
While push vesting overcomes the issues of trust and vulnerability to hacking, the large number of airdrops, numbering in the thousands as executed over several years duration, is extremely expensive. Despite the high degree of automation, other problems may occur using push distribution. Since blockchain transfers are irrevocable, any change to a recipient's wallet address could result in the token being sent to a dead or locked wallet and lost forever. They is no means by which tokens once pushed to investor wallets can be clawed back. Moreover, for a variety of reasons such as tax implications investors may not wish to receive their tokens immediately upon vesting.
kTx Collateralized Transactional Tokens: A uniquely innovative technology for token distribution management disclosed herein is the collateralized transaction token having the acronym kTx (where k symbolizes the word collateralized and Tx is the abbreviation for transaction). In this method of token distribution investors do not receive tradable enterprise tokens for their investment but instead receive kTx tokens as proxies for the tokens they purchased. Like a redemption coupon, the kTx tokens can be exchanged for enterprise tokens at any time after the specific class of enterprise tokens becomes vested. Because fungible tokens are identical, indistinguishable, and interchangeable, there is no need to link the vesting of ant particular enterprise token a specific owner or wallet. Whenever a category of tokens becomes vested, every 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 enterprise tokens to investors. Instead they come claim their vested tokens whenever they so desire using the kTx token as proof of ownership and as a redemption coupon. In this way, the burden of token airdrops upon vesting and the corresponding risks of a wallet address errors are completely eliminated.
In the manner prescribed, the collateralized kTx token acts a ‘proxy token’ representing the real asset held in reserve locked in the issuing vault. The issuing vault is not a separate wallet or physical entity but a construct comprising the unissued portion of tradable enterprise tokens locked within the smart contract from inception, i.e. at TGE.
Although any conversion ratio is possible, in general one kTx is issued for every generated enterprise token, meaning the kTx-to-enterprise token redemption ratio is 1:1. Because the kTx tokens distributed to investors at the time of their investing mirror the number of unclaimed enterprise tokens, the enterprise tokens act as “collateral” for the kTx tokens. Since the kTx tokens are never listed on any public exchange their intrinsic value reflects the value of their underlying asset, the enterprise token. Because they carry their collateral's implicit value the kTx tokens can be used as proof-of-ownership and may be utilized in private transactions, allowing the kTx token to be hypothecated in a variety of transactions (such as staking) even though its underlying collateral is still unvested and locked. The nominative collateralized transaction token is therefore descriptive—the token may be used in transactions in accordance with the net present value of its underlying collateral.
Although it is possible to create a kTx token after TGE (as a secondary trading market or derivative) in practice the kTx token is cogenerated with its collateral enterprise token within the same smart contract. Although inception of the enterprise token and its kTx proxy occur simultaneously within the issuing smart contract at TGE, it is easier to visualize the process stepwise as depicted in
In step 151c however, enterprise 214, a business or DAO with purpose or value, approves and instructs smart contract 150 to generate a fixed number of enterprise tokens 162c in the amount equal to the supply of kTx tokens, i.e. on a one-for-one basis. The total value of proxy pool 160c is not double the value of the enterprise tokens it contains, as only one of the tokens can be issued and circulating at a time. Specifically, for every fixed number of kTx tokens issued, the same number of enterprise tokens must remain in pool 160c as collateral. If the kTx tokens are redeemed for enterprise tokens, the kTx are surrendered to the pool and thereby removed from circulation. In one embodiment, kTx tokens once redeemed are burned, i.e. irrevocably destroyed, preventing their redistribution later to avoid risk of reuse and any fraud therefrom. Because the proxy pool contains only kTx and enterprise tokens, the proxy pool is incapable of selling either asset for value. Instead it relies on a companion pool, the swap pool, for enabling trade.
This next step in deploying the kTx transactional tokens is the creation of a swap pool as shown in
In other words, the kTx supply is registered in two pool pools—together with the enterprise token in proxy pool 160c and together with fungible tradable crypto in swap pool 185d. Thereafter, investor 179 transfers crypto 191 into the swap pool and receives kTx token 190 at the same price as its collateral, the enterprise token to be issued at TGE. After receiving a crypto transfer into swap pool 185e, the asset value of crypto 163e grows commensurately while the kTx token supply 161e drops by an identical amount 177. The total aggregate value of the underlying collateral for kTx tokens 161e plus the market value of the crypto 163e received at the moment of the trade equal the sum total 215, the same value just prior to the swap.
As illustrated in
In so doing, early selling of locked enterprise tokens is completely eliminated while still facilitating convenient distribution. Rather than unlocking and distributing enterprise tokens, in
Compared to the problematic unauthorized early selling issue depicted previously in
Once a fixed portion of enterprise tokens become vested 208c, an equal number of kTx tokens can be redeemed 110c from proxy pool 209 via smart contract 205d, delivering to the investor fungible tradable enterprise tokens 206c which may be held or alternatively sold.
If the investor wished to sell their unlocked enterprise tokens 206c they can execute such a trade in an exchange of through smart contract 205e receiving crypto 203c at market rates and subsequently (if desired) converting the crypto into fiat money 202c in exchange 203c. In this manner only vested and unlocked enterprise tokens can be redeemed for an equal number of kTx tokens upon vesting. As such early selling is prevented autonomously without any intervention by the issuing enterprise.
Changes over time in the token supply within the swap pool during trading are illustrated in
A superior representation of tokenomic transactions in an issuing pool is shown by the tri-column graphics shown in
During kTx redemption shown by tri-column pool 209c investors redeem the kTx tokens 207b for enterprise tokens 206c causing the kTx level 218c to rise as the supply of available enterprise tokens 219c dwindles. During the redemption phase, the crypto asset level 220c remains constant (at least until the enterprise withdraws the funds received from the pool to fund operations and development in accordance with the offering's use-of-proceeds). Redemption of kTx tokens for enterprise tokens need not occur at the moment of vesting. For many reasons include income reporting and taxation, investor may choose not to claim their vested tokens.
Although the aforementioned description of kTx based trading involved only a single denomination of crypto, the principle of a multi-crypto pool is equally applicable in multicurrency pools as shown in
Token Swapping and/or Staking: Using the disclosed methods, the enterprise token once generated may be used to stake a DeFi pool in exchange for earned interest. The DeFi pool APY may be fixed or variable, and the term, daily, monthly, quarterly, or yearly. In this manner token holders are economically encouraged not to sell their tokens.
In particular, kTx holders may hypothecate their tokens for additional returns either by (i) staking them to earn interest, (ii) subdividing a portion for staking and another portion for swapping, aka kTx stake & swapping, or (iii) swapping their kTx tokens in a manner that automatically invests the enterprise token into the staking pool for some fixed duration. For example
Alternatively
NFT Transactions: The same autonomous LaunchBot dApp is able to generate NFTs. As shown in
If a trader wishes to engage with collectors on a separate blockchain, the token ecosphere includes a NFT teleporter feature as shown in
This application is related to and claims the priority of U.S. Provisional Application No. 63/168,597, filed Mar. 31, 2021, titled “Advanced Transactional Protocol And Ecosystem For Smart Contract Authoring And Deployment” and U.S. Provisional Application No. 63/281,317, filed Nov. 19, 2021, titled “Autonomous Protocol And Platform For DeFi Token Launches And Collateralized Token Trading.” Each of the foregoing applications is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63168597 | Mar 2021 | US | |
| 63281317 | Nov 2021 | US |
