Advanced Transactional Protocols And Ecosystem For Smart Contract Authoring And Deployment

Abstract

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.

Claims

1. A method of distributing cryptographic tokens wherein: a number of fungible tokens are generated by one or more smart contracts during a token generation event, wherein a portion of the fungible tokens are made available for public sale and distribution by an issuer of the fungible tokens, and a portion of the fungible tokens remain locked in accordance with a defined vesting schedule; a number of transaction tokens equal to the number of fungible tokens are generated concurrently during the token generation event and wherein the transaction tokens are distributed to investors in exchange for payments received in the form of stablecoins or cryptocurrency wraps; and the transaction tokens are redeemed for an equal quantity of fungible tokens that are vested and have been unlocked for trading.

2. The method of claim 1 wherein the generation of the fungible tokens and the generation and redemption of the transaction tokens are executed autonomously by one or more smart contracts and recorded on one or more blockchain networks.

3. The method of claim 2 wherein the one or more smart contracts are concurrently launched on more than one blockchain network.

4. The method of claim 1 wherein the transaction tokens, after being redeemed for the unlocked fungible tokens, are irrevocably destroyed.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0274] FIG. 1 illustrates a blockchain hash chain and Merkel tree used for validating new blocks.

[0275] FIG. 2 illustrates blockchain virtual machine implementation on Ethereum.

[0276] FIG. 3 illustrates the process of wrapping ETH cryptocurrency to create the token WETH.

[0277] FIG. 4 illustrates the process of calling a smart contract, amending it, and registering the changes as a validated block.

[0278] FIG. 5 illustrates the relationship among the blockchain layers and sublayer to the OSI network (TCP/IP) communications network stack.

[0279] FIG. 6 hierarchically illustrates the resources needed to execute smart contracts, generate crypto tokens, and host DeFi pools.

[0280] FIG. 7 illustrates distinct smart contracts must be used to issue tokens on different blockchain networks.

[0281] FIG. 8 illustrates multichain token transactions.

[0282] FIG. 9A illustrates the process of an enterprise issuing tokens to investors and the risk of unauthorized selling.

[0283] FIG. 9B illustrates token trading in a pump-and-dump exploit.

[0284] FIG. 10A illustrates the process of NFT bridging.

[0285] FIG. 10B illustrates the problem of nested NFTs arising from repeated bridging.

[0286] FIG. 11 compares autonomous smart contract authoring to hand coded programming.

[0287] FIG. 12 illustrates the role of the LaunchBot in token generation and distribution.

[0288] FIG. 13 illustrates various decentralized applications comprising the disclosed Launchpad ecosphere for DeFi.

[0289] FIG. 14 illustrates the method for autonomous contemporaneous authoring and execution of multiple smart contracts on separate blockchain networks.

[0290] FIG. 15 illustrates a concurrent token launch on multiple blockchains with differing token vesting and prices.

[0291] FIG. 16 illustrates the role of a decentralized oracle in assessing asset spot pricing during a transaction.

[0292] FIG. 17 illustrates LaunchBot dApp executed autonomous smart contract authoring for a multi-crypto DeFi pool.

[0293] FIG. 18 illustrates a SwapBot dApp executed autonomous smart contract execution for trading in a multi-crypto DeFi pool.

[0294] FIG. 19 illustrates an exemplary user interface (UI) for SwapBot autonomous token trading.

[0295] FIG. 20A illustrates the initial steps required for procuring tokens through the SwapBot interface.

[0296] FIG. 20B illustrates the final steps required for procuring tokens through the SwapBot interface.

[0297] FIG. 21 provides an exemplary comparison of the operation of a token trading pool to that of a token issuing pool.

[0298] FIG. 22 illustrates the role of decentralized oracle in maintaining DeFi pool liquidity via an automatic market maker (AMM) dApp.

[0299] FIG. 23 illustrates AMM operational guidelines in a multi-crypto DeFi pool.

[0300] FIG. 24 illustrates the process of issuing unlocked tokens at TGE.

[0301] FIG. 25 illustrates an exemplary blend of tokens issued in a token generation event (TGE).

[0302] FIG. 26 illustrates locked, vested, and unlocked token distribution to various sales channels.

[0303] FIG. 27 illustrates exemplary tokenomics of a token offering.

[0304] FIG. 28 represents LaunchBot token distribution using push vesting airdrops.

[0305] FIG. 29 illustrates the creation of a collateralized transaction token (kTx) DeFi pool.

[0306] FIG. 30 illustrates the implementation of a kTx swap pool and token distribution therefrom.

[0307] FIG. 31 illustrates a token offering pool may be emulated in parts comprising a collateralized kTx pool and a kTx swap pool.

[0308] FIG. 32 illustrates kTx token distribution through various channels.

[0309] FIG. 33 illustrates the process of issuing kTx tokens at TGE.

[0310] FIG. 34 illustrates a comparison between an unlocked token launch and one comprising collateralized locked (kTx) tokens.

[0311] FIG. 35 illustrates various stages in deploying a kTx pool comprising inception (launch), kTx sales, and kTx redemption.

[0312] FIG. 36 illustrates a three asset representation of the various stages in deploying a kTx pool comprising inception (launch), kTx sales, and kTx redemption.

[0313] FIG. 37 Illustrates an exemplary stepwise token vesting followed by kTx redemption.

[0314] FIG. 38 illustrates a multi asset representation of a multi-crypto pool with kTx tokens.

[0315] FIG. 39 illustrates the use of kTx tokens in swap then stake investing.

[0316] FIG. 40 illustrates the use of kTx tokens in swap and stake investing.

[0317] FIG. 41 illustrates kTx derivatives trading involving swapping or staking.

[0318] FIG. 42 illustrates the autonomous generation and distribution of a NFT portfolio.

[0319] FIG. 43 illustrates the disclosed method of NFT teleportation.

DESCRIPTION OF THE INVENTION

[0320] This disclosure describes innovative advancements in the reliable processing of blockchain hosted data and decentralized applications (dApps) and their application for [0321] Autonomous Smart Contract Authoring Ecosphere [0322] Multi-chain smart contract authoring and transactions [0323] Multi-currency DeFi pool transactions [0324] Decentralized data oracle for rational asset trading [0325] Collateralized transactional (proxy) tokens issuance and vesting [0326] Cross-chain teleportation of digital assets

[0327] 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.

[0328] As illustrated in FIG. 11, many smart contracts 69 are created by hand coding of software by software programmers 68. This trend has resulted in a variety of problems resulting in theft or loss of billions of dollars of assets and invested capital. The cause of these unfortunate outcome are many, some based on ignorance or negligence, others due to intentional malfeasance and criminality or susceptibility to vulnerabilities, hacking, or market manipulation. Aside from simple cryptographic key and wallet theft, reasons for smart contract failures include the following: [0329] Many programmers are unfamiliar with the software (such as Solidity) used to implement decentralized applications and smart contracts. [0330] Many programmers have no experience in writing program code to run on blockchain virtual machines (BCVM). Unlike today's high performance notebooks, desktops, and smartphones, in order to ensure decentralization cloud of network nodes is limited by its low performance connected devices. As such the performance of BCTMs is limited to extremely low throughputs in the hundreds of thousands of instructions per second, the speed of computing in the 1960s. Complex programs can produce extremely slow response, indefinite wait states, infinite loops, or crashes in the middle of a transaction, possibly resulting in an irrevocable loss of assets involved in a transaction [0331] Most programmers are used to floating point mathematics and unfamiliar with fixed integer arithmetic required by dApp software. [0332] Popular token protocols such as ERC-20 have instructions such as “transfer” that are “no longer recommended” as they may be unable to detect a transfer was incomplete and irrevocably transfer the asset into nothingness. [0333] Hand coded programs have undetectable random errors producing a plethora of malfunctions or worse. The cost of using a third party to certify the integrity of every hand coded program is enormous. [0334] Each smart contract has peculiar vulnerabilities unique to the blockchain it is launched on and the token-pair it transacts. Launching a new token able to trade with multiple currencies requires a new smart contract for each token pair. For example, launching the fictitious enterprise ‘PRYS’ swappable for Ether and the four common stablecoins requires five smart contracts per network—one for each token pair, i.e. ETH-PRYS, USDT-PRYS, USDC-PRYS, BUSD-PRYS, and DAI-USD. If the token is launched on three chains, the number of hand-coded smart contracts will triple, each susceptible to their own random errors. [0335] Criminals and unscrupulous programmers can build in back doors for hacking and embed intrinsic vulnerabilities to various “legal” exploits such as front-running (the trading version of line jumping in an exchange live order book)

[0336] 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.

[0337] 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 FIG. 12, LaunchBot 71 automatically and autonomously converts input file 70 into smart contract 72, where smart contract 72 is a blockchain specific decentralized application. In other words, the LaunchBot 71 authoring program creates smart contract 72 computer code in accordance with its input file 70 to generate token 70 and to create a method to distribute the newly launched token 70 to the market 90 by generating token issuing pool 74 able to exchange a quantity 76 of fungible tokens for other tokens 75a comprising stablecoins) e.g. USDT, USDC, etc.) or wraps of cryptocurrency (such as WETH).

[0338] 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).

[0339] 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 FIG. 13 they include: [0340] A intuitive user interface designed to provide immediate feedback to a trader (good user experience) in response to entering data (for example to instantly recalculate the number of tokens to be purchased once a purchase code is entered). Since blockchain transactions are irrevocable, UIUX 82a is important to prevent accidental or unintended trades or financial losses resulting from operator error. UIUX 82a, is interoperable with smart contract 72 as its interface. UIUX 82a may be embedded within smart contract 72 or alternatively operate independently as a decentralized application with a secure application processor interface (API) to all instances of smart contract 72 on any blockchain. [0341] A decentralized Oracle 82b to collect on-chain and market data and pricing from centralized exchanges (CEXs) and decentralized exchanges (DEXs) and to transfer the information to UIUX 82a for display and to calculate swap ratios when trading one token for another, or valuing volatile wrapped cryptocurrency at market spot prices. Because multiple instances of smart contract 72 can be launched on differing blockchain networks, Oracle 82b must support multi-chain monitoring with cross-chain interoperability. [0342] An automatic market maker decentralized application, AMM 82c used by liquidity providers investing in DeFi pools to dynamically level the pool asset values in the pool, maximizing liquidity and prevent external arbitrage losses, especially in the inventive multi-crypto trading pools with multi-chain interoperability as disclosed hereon. [0343] A trading bot decentralized application SwapBot 99 used to interface UIUX 82a to any and all instances of smart contract 72 hosted on various blockchain networks.

[0344] 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.).

[0345] The process of a multi-chain token launch using the disclosed Launchpad ecosphere 80 is illustrated in the flow chart of FIG. 14. As shown, using Launchpad ecosphere 80 Enterprise 50 prescribes the tokenomics 70 of a prospective offering. In response Launchpad ecosphere 80 passes terms and conditions of tokenomics 70 to LaunchBot 71 authoring program which when combined with requisite details of blockchain networks contained in Protocol Library 83 autonomously and concurrently generates multiple blockchain-specific smart contracts 72a, 72b, and 72c, in this example representing executable dApp code for three BCVMs, namely the Binance smartchain (BSC), Ethereum virtual machine (EVM), and Solana's Ouroborus. As part of interoperable tool suite, Launchpad ecosphere 80 generated smart contracts 72a, 72b, and 72c include APIs, function calls, or other links to various dApp functions 82 including UIUX 82a, Oracle 82b, and AMM 82c.

[0346] 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.

[0347] 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.

[0348] 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.

[0349] 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.

[0350] 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 FIG. 15, two smart contracts 72a and 72b autonomously authored based on the input data to LaunchBot 71 are not symmetric, bit differ by the target blockchain. For example, smart contract 72a created for the Binance BSC network (and the BSC virtual machine) employ only BEP-20 tokens distributed in limited quantity through Initial Decentralized Exchange (IDO) offering 94c at a price-per-token at $0.03 and with 6-month cliff vesting following by monthly vesting for 24 months (4.2% unlocked monthly), and token generation event (TGE) offering 94d at a price-per-token at $0.04 and with no locking, i.e. immediately tradable. Execution of BSC smart contract 72a is only able to accept payment 92a using Binance BNB and BEP-20 USDT crypto.

[0351] 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.

[0352] Another feature of Launchpad ecosphere 80 is the important role of its Oracle 82b. As illustrated in FIG. 16, for any trade involving the swapping of a digital asset having a volatile market price, the value of such as asset must be ascertained using its “spot” value in the market at the moment of the trade. The role of Oracle 82b is to determine the real-time value of an asset in centralized exchanges and other markets 84 and to confirm the most recent trades, i.e. on-chain transactions 33 registered on the token's host blockchain. The current price of a volatile asset, e.g. cryptocurrency wrap 34a, determines its exchange rate for enterprise tokens 73 swapped between investor wallet 31 and smart contract 72 in accordance with instructions from investor 30 entered via UIUX 82a.

[0353] 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.

[0354] The solution to such a quandary is the inventive feature described herein as a multi-crypto DeFi pool. Such a pool as depicted in FIG. 17 comprises pool 74z containing the aggregate value 76 of issued token 73 and a heterogenous complement of swappable assets, referred to herein as “crypto” comprising the aggregated value assets 34e, 75a, 75b, 75c, and 75d. In an issuing pool as more tokens 73 are sold, the total value 76 of the remaining tokens likely diminishes even if the price-per-token increases. Conversely the value of the total of crypto assets increase. The creation of the multi-crypto pool is embedded into smart contract 72 as the dApp generated by LaunchBot 71 made in accordance with input 70 defining the offer's tokenomics. Once the issuing pool is depleted of newly issued enterprise tokens, a liquidity provider can infuse capital to balance the crypto value and token value, generally by selling the asset of greater value (crypto z), buying more of the assets of lesser cumulative value (token 73), or both.

[0355] Pool 74a once balanced is shown in FIG. 18 where the value of the crypto equals the market trading value 76 of enterprise token 73, whereby

Value (PRYS)=(# of PRYS).Math.PPT(PRYS)

Value (crypto)=(# of WETH).Math.PPT(ETH)+$1.Math.(# 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.

[0356] 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 FIG. 19 and by flow chart in FIGS. 20A and 20B.

[0357] As shown in step 1 of FIG. 20A, the SwapBot application 95a is opened on UIUX 82a hosted on a smartphone, desktop computer, or notebook. In step 2, the user selects Connects Wallet 95b to link their private (generally non-custodial) wallet 31 to SwapBot application 95a. In the example shown, the user selects their hypersecure CyberWallet. To process a transaction, the wallet needs to include an adequate amount of cryptocurrency to pay for transactional gas fees of the specific network, for example ETH on the Ethereum network, BNB on the Binance smartchain and so on.

[0358] 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.

[0359] 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.

[0360] Continuing to step 6 in FIG. 20B, the user then enters their intended purchase amount 95f specified in crypto and in step 7 selects the token they wish to acquire by entering its token symbol name 95, in the example shown the fictious token PRYS. The icon for the token 73 will automatically appear visually confirming the selection. At the same time, the number of calculated tokens you will receive at the market price (or at the TGE price if the tokens remain locked) are displayed. In step 8, if the user enters a purchase code 95h granting them a special price (e.g. PPT=$0.01, $0.025, $0.035) then special price is selected by conditional branch 95r and the newly calculated amount of tokens to be purchased 95i is displayed in step 9. Once the trader confirms the calculated amount is correct, in step 10 pressing the purchase button 95j executes the trade.

[0361] 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 FIG. 21 contrasting purchases through SwapBot from a token launch against normal DeFi pool trading. In token issuing pool 74f enterprise tokens may be bought but not sold in the pool. As such, the pool commences selling with a fully collateralized offering of enterprise tokens 76 equal to the asset starting value 215 and with essentially no crypto 34e (shown slightly above zero for illustrations sake). At a later date pool 74g shows the aggregate value of enterprise tokens 76 has dropped and been replaced by an increase in crypto comprising WETH 34e and BUSD 75a. Assuming for the sake of simplicity there is no change in the market price of these crypto assets during launch the sum of the aggregate values of enterprise tokens 76 plus that of crypto 34e and 75a should still equal the calculated starting value 215 of the offering.

[0362] 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.

[0363] 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.

[0364] 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.

[0365] 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.

[0366] 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 FIG. 22. In such cases liquidity providers 86 may input or remove value from multi-crypto pool 74a or to buy or sell the pool's assets to maintain balance between the cumulative crypto value of 34e, 75a, 75b, 75c, and 75d, and the enterprise token 76.

[0367] 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 FIG. 23. Unlike any other DeFi pool, AMM 82c is designed to balance the pool not only between the token's value 76 and the aggregated value of its WETH, USDT, BUSD, USDC, and Dai crypto assets, but also to maintain certain ratios among its crypto based on market liquidity and recent trading volumes. In the table shown, the inventory of each crypto asset has a target range comprising a minimum, a maximum and a target. Whenever the relative quantities of theses tokens fall outside the specified range, the AMM automatically adjusts them irrespective of whether the value ratio between the aggregate crypto value and the token are still within guidelines.

[0368] 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.

[0369] 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).

[0370] The problem of buy-sells is illustrated in the flow chart of FIG. 24 where an investor buying an enterprise token at a presale discount is able to unload the asset at a higher price as soon its public trading commences. The token issuer has no idea who is responsible for selling and how deep the selling pressure goes, especially when panic selling ensues. For example, investor converts fiat money 122a into crypto 124a (such as USDT) in centralized exchange CEX 123a, then purchases the new fungible token FT 126a during its presale through smart contract 125a. If the enterprise distributes the presale tokens to the investor they deposit the assets, token 126a in non-custodial wallet 121 and possibly subdivide the assets further into a myriad of smaller wallets (too numerous to track).

[0371] 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.

[0372] 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.

[0373] 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.

[0374] 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, FIG. 25 illustrates the wide variety of token recipients in a common tokenomic model 100 including institutional investors (VCs) 55a, strategic investors 55c, and private tranche investors—all of which expect purchased tokens to be offered in a locked state and vested over time. At TGE an additional category of locked tokens are reserved for engineering and business development 55b to defray project expenses, and are therefore are made available for free, albeit typically using a longer vesting schedule. Other tokens are necessarily released in an unlocked state from inception including the relatively small portion allocated for IDOs (initial DEX offerings) and for a public listing 90 at the token generation event (TGE). Additional unlocked tokens are distributed to one or more DeFi liquidity pools 74m to provide a means for market making following the TGE.

[0375] 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 FIG. 26 where tokens issued for private sales 31 are vested 104, sales to DEXs and CEXs 108 may be unlocked 103 or vested 104, and tokens for pool liquidity 741 are necessarily unlocked 103. Tokens in vault 101 may be locked 102 (to be manually unlocked later) or alternatively may be unlocked as per a vesting schedule 104. The problem with this approach is that tokens once distributed cannot be comingled with others intended to remain locked during vesting.

[0376] 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 FIG. 27 as divided including allocations for liquidity 111, business 112, development 112, public offering 114 and investors 115. One LaunchBot 71 implemented smart contract 72 distribution plan involves time vesting and distribution from token vault 101 using automated “push vesting”. As depicted in FIG. 28, LaunchBot specified distribution using push vesting means when a token becomes vested it is “pushed 117”, i.e. unlocked and airdropped to a specified address for recipient wallet 31 on particular dates. For example the first airdrop 105a occurs only after 6 months. Thereafter as shown, airdrops 105b, 105c, 105d, and 105e occur monthly on the 7.sup.th, 8.sup.th, 9.sup.th and 10.sup.th months respectively. Push vesting continues until all tokens are distributed.

[0377] 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.

[0378] 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.

[0379] 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.

[0380] 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.

[0381] 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 FIG. 29. As shown, LaunchBot generated smart contract 150 first creates 151a proxy pool 160a as registers for tracking the total number of kTx tokens 161a and the total supply of enterprise tokens 162a. At the moment of birth the total assets contained in the pool are zero. Instantaneously thereafter in step 151b smart contract generates a fixed supply of kTx token 161b. At this moment, the generated kTx tokens in proxy pool 160b hold no value as they are not collateralized by any asset of real value.

[0382] 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.

[0383] This next step in deploying the kTx transactional tokens is the creation of a swap pool as shown in FIG. 30. In step 151d, the smart contract creates a new register 163d for transacting and holding fungible tradable crypto (such as WETH, USDT, USDC, BUSD or Dai). The second half of swap pool 185d contains the kTx token supply 161d, the same supply as kTx 161c recorded in swap pool 160c.

[0384] 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.

[0385] As illustrated in FIG. 31, because the kTx token supply 161e is shared by both proxy pool 160c and swap pool 185e, the combination of the two operate as a virtual token offering pool 199f containing crypto 163f and enterprise tokens 162f and with aggregate value 215. So by selling enterprise tokens to investors but delivering kTx tokens instead, the purchaser feels the confidence in knowing they hold a proxy token which represents their underlying collateral and which can be redeemed at a subsequent date for the fungible enterprise token once it is listed and unlocked.

[0386] 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 FIG. 32 token offering pool 160c issues proxy tokens 190 while retaining its locked token supply 162c. As shown, kTx trading occurs via swap pool 185, through IDOs with exchanges 108, to private wallets 31 or retained in vault 101 for later distribution such as a secondary (follow on) offering. So although investors are purchasing the enterprise tokens, they receive kTx tokens in their stead. Although the kTx tokens themselves are issued unlocked, because they remain unlisted indefinitely, they cannot be sold or traded on any public exchange. There only value is in their redemption for their enterprise token collateral. The vesting 104 and unlocking 103 of locked tokens 102 does not refer to the kTx token but in its ability to be redeemed for its enterprise token collateral.

[0387] Compared to the problematic unauthorized early selling issue depicted previously in FIG. 24, using kTx collateralized tokens early selling quandary is completely eliminated as shown in FIG. 33. As in the prior example, investor 200 converts fiat money 202a into crypto 204a in exchange 203a and then invests in a token presale executed by smart contract 205c. But rather than receiving enterprise tokens, proxy pool 209 releases 210a only kTx tokens 207a to the investor. Through SwapBot 71 the kTx tokens are delivered in unlocked form to the investors wallet 201. Although the kTx tokens are unlocked, the enterprise token collateral remain locked pursuant to vesting 208c.

[0388] 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.

[0389] 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.

[0390] FIG. 34 contrasts the collateralized token launch process to an unlocked token launch where rather than crypto 204a being converted into a fungible tradable token 206a by smart contract 205a, improved smart contract 205c made in accordance with this invention issues a kTx collateralized transaction token subsequently deposited into wallet 201. While in an unlocked 208b token distribution, fungible token 206b can immediately be sold 205b in exchange for crypto 204b, in the improved process the kTx token 207b can only be redeemed for a fungible enterprise token 206c when smart contract 205d determines vesting 208c has occurred. Once claimed, the fungible token 206c can be held 211g in wallet 201 or otherwise sold 211f for crypto 204c by smart contract 205e.

[0391] Changes over time in the token supply within the swap pool during trading are illustrated in FIG. 35 where at inception 213 enterprise 214 starts with an even value 215 of enterprise tokens 2919a and kTx tokens 218a. During kTx sales but prior to unlocking investors 200 purchase enterprise tokens from enterprise 214 with crypto 204a but receive kTx tokens 207a instead thereby diminishing the available supply of kTx tokens 218b in swap pool 209b but retaining the token collateral 219b. After vesting during redemption shown by pool 209c, the level of enterprise tokens 219c drop as tokens 206c are distributed to investors 200 redeeming their kTx tokens 207b causing the reclaimed kTx token supply 218c to rise until such time that all enterprise tokens have been issued. In one embodiment all kTx recovered by exchanged are burned and irrevocably destroyed to prevent the risk of theft and misuse. Although the dual column diagrams illustrate the relative levels of the kTx and enterprise tokens the graphic fails to accurately account for all the transactions because the cumulative crypto payments are not represented.

[0392] A superior representation of tokenomic transactions in an issuing pool is shown by the tri-column graphics shown in FIG. 36, describing the relative asset values at inception, during kTx sales, and during kTx redemption in pools 229a, 229b, and 229c respectively. Specifically at inception 213 enterprise 214 populates tri pool 229a with an equal amount or crypto 219a and kTx tokens 218a while the token value 220a is essentially zero. During kTx sales investors 200 supply crypto 204a and in return receive kTx tokens 207a and proxies for the enterprise token collateral for the pool. The process of selling kTx token selling causes the token value 220b to rise while the number of kTx tokens in the pool diminish 218b to a value near zero. During the kTx sales the total enterprise tokens 219b remains constant.

[0393] 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. FIG. 37 illustrates the swap pool asset levels over a exemplary 18 month vesting period starting with value 215. As shown, at 6 mo, 9 mo and 12 mo the vested number of tokens rises from 0% to 20% to 40% respectively although no kTx tokens were redeemed, the enterprise token level 219a remains at 100% and the kTx level 218a remains at zero. Then at 18 months when the investor is 80% vested, wallet 231 redeems kTx tokens 27b in an amount of 80% shown by 218z, that is 100% of its vested unlocked enterprise tokens. In response to the redemption of 218z kTx tokens, the pool issues unlocked tradable enterprise tokens 206c is an amount dropping the level of remaining enterprise tokens 219z down to only 20% remaining.

[0394] 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 FIG. 38. As shown, liquidity providers 255 supply crypto assets 254 to tri pool 250 comprising enterprise tokens 253, kTx tokens 252 and multi-crypto pool 250 which may include any combination of WETH 244, USDT 245a, BUSD 245b, USDC 245c, and Dai 245d. Graphically is convenient to represent multi-crypto pool using icon 241 when interacting with crypto 240, kTx tokens 243, and enterprise tokens 242.

[0395] 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.

[0396] 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 FIG. 39 illustrates a swap then stake feature where an investor's kTx tokens are deposited 313 to vesting contract 310 in advance of vesting. Upon vesting the kTx tokens are automatically redeemed from swap pool 311 for enterprise tokens and staked for an defined term in staking contract 312, thereby effectively locking the tokens up for a longer duration in exchange for a higher rate of return. FIG. 40 illustrates an alternative method where the kTx tokens 313 are used concurrently for staking 312 and for swapping 311 pursuant to a defined vesting schedule 312.

[0397] Alternatively FIG. 41 shows kTx tokens may be used in advanced of their collateral unlocking to for token swapping in a collateralized token decentralized exchange (KDEX) or alternatively for staking in interest bearing accounts. The value of kTx tokens in the KDEX may be reduced from its collateral's true market value. As the vesting date nears the market value of the kTx tokens in the KDEX will gradually approach the market value of the underlying enterprise tokens.

[0398] NFT Transactions: The same autonomous LaunchBot dApp is able to generate NFTs. As shown in FIG. 42, the input file 300 for generating a portfolio of NFTs includes metadata file 301. LaunchBot 71 combines the input and blockchain specific data from network protocol library 83 to generate smart contract 302 launching the new NFTs 303 on one or more networks. Unlike fungible tokens issued in a DeFi pool the generated NFTs are immediately available for trading with metaverse collector 305 in any number of NFT marketplaces irrespective of the blockchain on which the non-fungible tokens are first generated.

[0399] If a trader wishes to engage with collectors on a separate blockchain, the token ecosphere includes a NFT teleporter feature as shown in FIG. 43. In token teleportation, a token holder of NFT 350 on the EVM can offer teleported NFT clone to a buyer on BSC, where smart contract 351 identifies the target wallet and network. But rather than transferring a wrapped token as bridging procedures use, a new wrap is initiated from the original token 350 and teleported to the buyer as NFT clone 354. Meanwhile the prior token instance 351 is burned 353 destroying any duplicate risks. In this manner, all teleported tokens only contain a single wrap and never involve nested wraps with hidden gas expenses.