Creating Liquid-tokens on Bitcoin Cash in a non-Invasive manner using OP_Return (Similar to Simple-Ledger-Protocol but with a lot of changes)

Tokens
#1

Peng Protocol : Peng(a) Design (Short)

OO A Distributed Network for Creating Liquid Simple-Ledger-Tokens Using OP_Return Transactions verified by Digital Signatures on the Bitcoin (Cash, SV) Blockchain(s).

Definitions

TxF; Transaction Fees
OPTx; Output Transaction (OP_Return)
SLg; Simple-Ledger
AqLiq; Adequate Liquidity
NFT; Non-Fungible Token
NEO; Node Endpoint Operator
HYPR; Hydra Protection
COIN; Bitcoin-Cash or Bitcoin-SV
D-Sig; Digital Signature
UTXO; Unspent transaction output
DRM; Digital Rights management
TeF; Test by finality

Protocol

~ Basics ~

A network of web-based bots secured by HYPR and absolute consensus, who perform OPTx’s to smart contracts that allow users to deposit/withdraw COIN and make use of custom tokens on a simple-ledger which are fully liquid. Peng is not a layer 2, it is an intermediary for Layer 1 transactions.

~ Bots ~

Provision for ‘Bots’: The ‘Peng’ Network will operate using distributed bots listed as follows; ‘Oversights’ ‘Viewports’ ‘Traders’ ‘Bailiffs’ and ‘issuers’ whose actions will function on D-Sig + ‘Absolute consensus’ to prevent fraud, and use ‘HYPR’ to prevent tampering.

~ Absolute Consensus ~

Integration of ‘Absolute Consensus’: Absolute Consensus ensures that 100% consensus is required to perform an action on a network, each request has to already be verified by a digital signature (Normally this would be enough to validate that an action absolutely originated from the address in question and is not being faked, but ‘Absolute Consensus’ assumes that the node verifying this request is lying).
A random node is selected from the network and presented with an encrypted message verified by D-Sig, the node has to verify that the D-Sig is correct, it then requests no more than 6 other nodes to verify it as well, if even 1 node rejects it; consensus cannot be reached. All the affected nodes are kicked from the network and the process restarts. A situation where consensus is never achieved is a “Cascade Shutdown”.
For the purpose of ‘Peng’, several other protective measures exist to prevent even a single node from agreeing with invalid transactions.

~ HYPR ~

Provision for ‘Hydra Protection’: HYPR is a proposed DRM software that works by seizing control of the computer at root level, on top of distributing the guarded program library to 19 heads in separate folders across a computer and restricting the user from accessing them, if one of the “heads” is tampered sufficiently; the HYPR will delete all “guarded” files plus any files which may appear similar to the guarded files.

~ Viewport ~

Provision for ‘Viewports’: These bots will host the web view; they provide an interface through which users can view balances and initiate transactions. Users can only view the balance of the wallet they own, this (+ any other action) is verified by D-Sig, every “login” with a complete transaction is cached for a few days. The Viewports encrypt and decrypt OPTx’s which make up entries in the Simple-ledger.

~ Oversight ~

Provision for ‘Oversights’: These bots will accept transactions from ‘viewports’ after the prior have achieved consensus, ‘Oversights’ cannot decrypt messages, they simply execute them into OPTx once they have achieved consensus and verified the D-Sig.

~ Issuer ~

Provision for ‘Issuers’: These bots will create new smart contracts and tokens, they cannot decrypt messages, they simply execute them into OPTx or contract creation once they have achieved consensus and verified the D-Sig.

~ Trader ~

Provision for ‘Traders’: These bots are exclusive to NFT simple-ledger entries, they execute NFT escrow requests and NFT listing requests.

~ Bailiff ~

Provision for ‘Bailiffs’: These bots execute ‘kick’ orders once queued and after achieving consensus, ‘Bailiffs’ have the final say in removing a NEO from the network. ‘Bailiffs’ manage checking a NEO when they need to join/rejoin the network.

~ Simple Ledger ~

Integration of ‘Simple Ledgers’: The ‘Simple ledger’ is a system of encrypting and decrypting messages stored in OPTx’s sent to a smart contract on a blockchain. Each message is a ledger entry, the details of each message is account information involving balances, when a transaction on the ‘simple ledger’ occurs it simply means that a new entry is made with an updated “nonce” and balance details. The auditors of this ledger always read the entry with the highest “nonce”.
Each token is an account unto itself, they are discerned by number and what smart contract their balance is stored in, every user’s balance has clauses for every token on the smart contract they deposit to, meaning the token balance can be updated from a single OPTx.
The liquidity for tokens is stored as the token account’s main balance and can be changed by a “swap protocol” which allows every user (with funds on the particular smart contract) to exchange their COIN for the token and vice versa.

~ Main Ledger ~

Provision for ‘Main Ledgers’: ‘Main Ledgers’ are smart contracts which obey specific OPTx’s, users deposit funds into the ‘Main ledger’. New ‘Main ledgers’ can be created once the maximum number of tokens for one ‘main ledger’ is reached. This has to be done by user request.

~ Balances ~

Each OPTx is a full balance of the user’s SLg COIN and all tokens on the particular ‘main ledger’. Different balances exist for ‘Tokens’ ‘Users’ and ‘Traders’. Each user balance has “Token” fields, which are empty slots by default, only when a token’s account is “activated” and its “Token-self” field is filled; does it becomes active, the “Token-self” field is the supply of the token and is at first blank but updated by a user’s request. The Token’s SLg COIN balance is its liquidity and can be swapped to or from using the “swap protocol”. Tokens cannot be created without “adequate liquidity” which is 105% of the token’s supply * initial price set by the user.
All tokens have a liquidity fee which is set by the user and billed on each sell, payout of fees only occurs when liquidity is above 105% of the token’s price * supply, payout is calculated by deducting [fee] from each token sell order, the difference is returned to the user’s SLg COIN balance. Once a token has adequate-liquidity; all sell order deductions are instead sent to the “creator”, which is the public key that activated the token and defined its fields. Token names are stored on the ‘viewports’, the actual token name is “Token #” @ xxx…xxx address.

~ Non-fungibility ~

NFTs can be created by using a second type of OPTx which does not have a COIN balance or “Token-self” balance, but instead has an “owner”, “metadata” and other fields which allow trading or listing the NFT.

~ Allocation ~

Each NEO is entitled to an allocation as reward for being part of the network, these rewards come from TxF and token creation fees and are held within their node’s ‘Oversight’ wallets until being sent to the NEO owner’s public key.

~ Fees ~

There will be two tiers of fees; transaction fees, which are billed based on miner fees + 10%, and TeF which is an intricate algorithm that allows fees to go up when prices are low and go down when prices are high, it does this without an oracle or price checking (Because oracles can be subject to losses in connection or seizure in the data source).

~ Genesis ~

‘Genesis’ Refers to starting up the network for the first time, this is achieved by booting up a ‘Bailiff’ from the “genesis key”, the ‘Bailiff’ hosts the Proto-viewport pending the creation of ‘Viewports’, and generates the web address (no domain name), then other bot sub-groups need to join, once there are 6 of each bot sub-group the network can begin transacting. The “genesis key” is an offline version of the bot installer, it still makes use of “Bailiff checks”. The “genesis key” cannot be used once the network is in full swing.

~ Cascade Shutdown ~

A Cascade shutdown is a hypothetical situation wherein “kicked” NEO’s do not rejoin, where only one set of ‘Bailiffs’ remain and they fail to achieve consensus, the system “shuts down” as ‘Bailiff’s’ kick one another off the network.
However, as stated, all “Kicked” NEO’s will immediately attempt to rejoin, ones which fail checks are terminated by HYPR. HYPR cannot be circumvented with existing technology.

~ Monetization ~

Implementation of Peng Vanity Addresses: There will be a collection of 99,999,999 possible vanity addresses. Each vanity address can be named and will act as an account that exists purely within the Peng SLg; these can be used remotely to carry out transactions anonymously. Each vanity address will cost 100,000TeF(e) (Or $5 at current estimates), which will be shared equally between the NEO that processes the transaction and the 4 users who own “Peng Genesis” NFTs.

Full design paper available on my google drive.

Additional Content

In the following article I show a hypothetical scenario with images of how Peng would function, you can read it here.

#2

Why don’t you paste the whole article here then?

Otherwise this will look like ordinary spam.

This is the “Bitcoin Cash Research” site, medium isn’t it.

1 Like
#3

Okay I’ll edit the post, and send it over without images.

#4

You can paste images here, you know.

#5

PS.

You’re 2 years late with a new token system anyway. BCH has CashTokens now. CashTokens is superior to any non-native or custom token system, because it is built-in and ultra scalable by design.

You gotta do some reading.

1 Like
#6

New users can’t post more than one image. Or I could wait till I’m not considered a “new user” that also works. But come to think of it ‘general functions’ needs images, apologies but I will be posting the design paper (short form) instead.

#7

I know about CashTokens, I’ve read into it, CashTokens isn’t until May.

#8

Your token system looks like an interesting academic project.

However, how does it compare to CashTokens regarding scalability and implementation difficulty?

#9

The main question that is on my mind is “what is your intention here?” Do you intend for this project to be:

  • Just a side hobby?
  • Competition/Alternative to SLP?
  • Compatition to CashTokens?
#10

Thank you for reading, to answer your question;
Scalability
Peng will not use exiting proof of work models, nodes are selected at random to process a transaction and pass it on to the blockchain, as previously stated in the main document it would not be possible for nodes to tamper with their software to manipulate the system due to it being under HYPR. More users equal more rewards for NEOs but comes with more burden, the heightened rewards will attract more people to host NEOs (which can be done on most computers, high specs are not required), and vice versa, more NEOs will decrease the chances of one node getting selected for a transaction, which will decrease the rewards and cause some to shut down their nodes.

Test by Finality is also a way to ensure that a node does not slow the system down (that’s in the full version of the design document at the end of my post).

Peng(a) is only as fast as the blockchain it is deployed on, however I have also designed a system called Peng(o), which is less dependent on the blockchain it is deployed to, but I’m still writing articles (with images) on the differences between Peng(a), Peng(o) and Peng(e).

#11

Another important question:

  • I see the “PENG protocol” will be supposedly running both on Bitcoin-SV and Bitcoin Cash. Will it be possible to move the tokens between PENG-SV and PENG-BCH?
#12

When I created this project it was out of a great sense of fear, I actually began working on it sometime in September 2022 before major announcements for CashTokens had come out. It was based on SLP but recognizing the limitations of the previous system, Peng allows the creation of tokens which have liquidity (can be traded and have prices fixed or otherwise).

What I was afraid of is something I can only describe as a doomsday scenario for EVM chains. Liquidity on EVM chains is subject to a number of exploits but the one that troubles me the most is something I call “liquidity drinking”.

Essentially; most liquidity pools use something called “constant-market”, which pairs tokens to each other, so if you have COIN/TOKEN and their amounts are 1000/1000, their value is equal, but if one should be bought, then the pool becomes 900/1000 based on the amount bought, the one with less supply in the pair becomes more valuable. Constant market in theory allows prices to go up until the asset is more valuable than all the liquidity on the chain (so what’s the issue?). The issue is; price is calculated by comparing the amount of each asset in the pair with the total amount in circulation and total number of holder. One person buying up a coin does not significantly increase the price compared to numerous.

However, the system cannot discern a legitimate purchase from a transfer, this means if one person were to buy a token and then distribute that token to xxxx number of addresses, the price would increase as though xxxx addresses bought the coin, but because those addresses did not put liquidity into the pair; the amount of tokens in circulation will not match the liquidity. An extreme example of this can be seen here: mcap_Market-Cap_Coinlist_Rug (2)
But less extreme would be a coin with $1,000,000,000 worth of liquidity but several times the value of tokens in supply. “Airdropping” also achieves this, every single time a token is airdropped that creates a deficit. The primary aim of Peng is to warn developers of this flaw and offer a better system. Peng’s “Swap protocol” prevents liquidity drinking but does not allow a token to be falsely inflated in price.

#13

I have thought of that and though it would be possible it is not something I am interested in doing. Peng is designed in a way that anyone can create a multi-sig and that multi-sig would be managed by what can only be described as another Peng layer or Peng(r), this layer can accept COIN from Peng(a) on either BCH or BSV and using liquidity on both sides can transfer the appropriate COIN to a new wallet on the other side. My only issue with BSV is how authoritative they can be in the managing of their chain, which is why I wouldn’t want to personally create such a bridge. Even creating Peng(a) on BSV will have to be on express permission from someone in charge.

#14

Oh and on Implementation Difficulty:
The biggest hurdle of designing a blockchain system is the cryptography, some things which seem easy from a conventional programming background are several times harder when cryptography is involved. This is part of the reason Peng is non-invasive, it is more like building a payment app than building a blockchain network, but it inherits the spirit of immutability and trustlessness.

#15

Oh well then, this is unfortunate.

It seems to me like you’re creating A LOT of unnecessary complexity (multiple separate token networks on multiple main chains) for no huge added benefit.

I guess I wish you luck with your academic side-project.

1 Like