Hi, r /btc, I'd like to share with you a concept I created for designing de-fi systems that function on Bitcoin Layer 1, no side-chain or forks required. Hope you like it :)
The system described in this post is called "Peng(o)". This post outlines how Fungible and non-fungible tokens (Similar to ERC-20 and ERC-721 on EVM chains with a few improvements) can be created and managed on Bitcoin BTC while preserving the security of its users. This would allow the creation of secure stablecoins using the trustless TeF algorithm (not an external data source). With non-fungible tokens it will be possible to create subscriptions, reoccurring payments, on-chain escrows and trust funds.
Peng is designed in such a way that it would be impossible to "hack" a token or have special privileges that would allow "rugpulls" to occur.
The system is purely in its design phase. Peng is open source; Apache 2.0, DRM is only used to secure post-genesis versions of node software.
Creating L1 Tokens on Bitcoin will require three things;
- OP_Return
- Smart Contract Treasuries
- Distributed bots
OP_Return
https://i.ibb.co/CtXy6PB/OP-return-Peng-bitcoin-btc.png
An "OP_Return" is a message in a transaction output as seen in the example above, OP_Return is used to create a new "account" within the distributed Peng Network, the bots read all associated OP_Return transactions sent to the Peng(o) multi-sig address and use that as an account list.
In the above example we can see a line for "variables", the variables are an "internal ledger" or json directory stored within the distributed bots that hold the user's actual balance.
https://i.ibb.co/WW2dNzp/Peng-o-OP-return-example.png
So what the user does when they need to deposit for the first time is interact with the web app, which will request a digital signature to prove that they own an account, this signature plus the randomly generated code issued for encryption is stored on the OP_Return itself.
The user would then need to send the required fee to create the OP_Return to an address controlled by the distributed bots. While also sending the desired amount for deposit to the treasury multi-sig, the transaction is expected, so even before it is confirmed on the blockchain the bots will update the user's balance in the internal ledger and the user can begin transferring to other accounts, but each deposit from an unconfirmed transaction is tainted in an "error chain", this means if the transaction is rejected or reverted; every subsequent transaction logged can be undone and redone without the tainted coins.
When a user has created their account they do not need to pay a fee to create a new OP_Return message and can deposit freely, this is because the OP_Return stores a static account and does not need a new message on-chain to update balances, balances are updated from within the internal ledger.
Proofing
https://i.ibb.co/prTPVJQ/Peng-screen-3.png
Each transaction requires a proof, this shows that the user in question owns the address they want to transact with and is achieved through the use of digital signatures as seen above. The user is issued a code which they need to sign in their wallet, they present the output and it is corroborated with the public key and original code, this proves they are the rightful owner of the address.
The proof for each account creation is appended on the OP_Return, and the proof for each transaction is appended to the json file within the bot (only the last 10 transactions for any account is logged, each transaction is sorted by "nonce" or number once, a simple way to count each transaction). Every internal transaction is public and auditable.
Smart contract treasuries
On Bitcoin(BTC) it is already possible to create smart contracts that obey simple parameters or rules, for example a user could create a contract that will send a specific amount of BTC to a specific address after a specific number of blocks have passed. How Peng incorporates this is that all funds are held within a "Treasury contract", this is a multi-sig address, which means six keys are required to pass a transaction, each of these keys represents a bot sub-group in the distributed network.
To expand on this; bots within the network are assigned sub-groups, each sub-group possesses a key which is created automatically post-genesis, meaning no one sees the keys before they are generated, the security of this is guaranteed in the heading further down; "distributed bots".
https://i.ibb.co/y44NyRc/peng-o-token-format.png
Tokens on Peng are similar to accounts, their creation is made on an OP_return and their variables are stored within the internal ledger, multiple types of token updates exist, in the above image we see the most common which is a token_buy, when a token is bought two updates occur; one for the user and one for the token account, this sends a certain amount of coin to the token's account while sending a certain amount of the token to the user's account.
Each user can only hold (4) tokens at a time, when a user buys a token for the first time what this does is add their public key to a token registry and the slot used to hold said token, this slot is then used for all future buys of the same token. The mechanism for this swap is single sided and not constant market, single sided means an enforced amount of token is swapped for a specific amount of coin, the impact of each buy is then recorded and used to update the price.
This means liquidity is not a pair, the liquidity for each asset is stored separately, ensuring that even if liquidity for one asset should drop significantly so long as there is enough for a particular trade it will enforce the correct price.
https://i.ibb.co/qNYC327/Bitcoin-Total-transactions-vs-usd-price-logarithmic.png
The use of this system to create stablecoins would use a static price in TeF, TeF is simply a data source gotten from the average transaction amount per block on the main blockchain then divided by 100,000,000, this becomes 1TeF.
TeF is correlational with the value of the main blockchain vs the greater commodities market because as more people buy the coin it becomes scarcer and therefore each transaction will have an average of fewer Bitcoin being sent, so in this way TeF is closer to the USD price of the chain while not being USD.
More information on TeF and its variants can be found on my medium; here. Tokens pegged to TeF using the existing swap protocol will always trade at the exact TeF price.
Distributed bots
https://i.ibb.co/bry3XFJ/Screen-3.png
The Peng webapp and everything else managed by the network would be hosted by distributed bots, anyone can host a bot and receive rewards per transaction, transactions are randomly assigned to nodes in the network and make use of "absolute consensus".
This is possible thanks to the network's DRM software known as HYPR, HYPR prevents reading or writing of the node software by anyone but itself, it does this by embedding itself in the kernel and seizing control of the computer. When the computer is booted up, HYPR boots with it and runs a simple taskbar launcher which can be used to start or stop the bot.
Further details and protective measures for HYPR and the protocol as a whole are expanded upon in my design for Peng(a), which is designed to work on BitcoinCash (BCH) and can be found on my medium; here.
How this is an improvement over token swaps on EVM chains
A. Swap protocols on EVM chains typically use a constant market algorithm, this means the assets are paired and go up or down in value depending on which asset is more scarce. The problem arises in how price is calculated; total holders vs circulating amount vs liquidity, each buy is simply a transfer, each transfer is also a buy, each time a token is transferred it is recorded as purchase, this means if someone were to distribute the token's supply to a large number of addresses this would greatly increase the price of the token. However, because those were not actual purchases; liquidity was not added, so there is a liquidity deficit. The image below illustrates that but in an extreme example;
https://i.ibb.co/j88CM3v/mcap-Market-Cap-Coinlist-Rug-2.png
The ERC-20 token shown above was distributed to millions of addresses, thus its circulating supply and number of holders made it seem more valuable than it actually was, this exploit can and has been used to "game" the constant market system. Peng solves this.
B. Users cannot pull liquidity; this is because liquidity on Peng is a network primitive and not a token standard that can be customized, When users create a token its supply is not active until adequate liquidity is reached; this is; preset supply of the token multiplied by the preset price. Once liquidity is added the deployer still has to buy the token same as everyone else. The incentive for creating a token are the fees taken on each transaction which cannot exceed 5%, though fees are only paid out once liquidity is above 105% of the price multiplied by supply, each fee below that is instead used to refill the liquidity pool.
C. Users cannot define special privileges on the Peng Main-network, this means a user cannot "hack" a token using a backdoor, because there is no backdoor. However because it would be possible to create sub-networks using Peng(o) multi-sigs that can in turn have their own internal ledger, it would be possible for someone to create a webapp where there are backdoors that allow rugpulls, but the user would have to be lured to such a site in the first place, sub-networks are not shown on the main-network in any fashion.
With that said I will conclude the post here, thank you for reading, I do require assistance with implementing Peng, if you have any critique or recommendations please let me know below.
[link] [comments]
source https://www.reddit.com/r/btc/comments/10bxxit/creating_tokens_on_bitcoinbtc_using_op_return/
No comments:
Post a Comment