O Disclaimer : The Contents of this article are not reflective of the current state of the Peng SLg*
The following article shows how a user would interact with Peng(a) once fully built.
The user opens the webpage at the web address, something like https: //210.69.420.666 The link to the D-app will be available on the formal website, which would be something like; https: //peng-genesis.com
The user inserts their address in the blank space and clicks “initialize”. They are issued a code that needs to be signed in their wallet;
The user signs the message in their wallet and submits the encrypted output, this proves that they own the wallet in question using a digital signature (D-Sig) to verify the encryption.
The user is greeted with their dashboard, from which they have a number of options, let’s begin with withdraw;
This function is more complex, the user is required to first sign a D-Sig, once they present the output, they get an address that they need to send a certain amount of COIN to in order to pay Transaction fees (TxF).
Once the user sends, behind the scenes this is what happens;
What the user was interacting with was a ‘viewport’, which are distributed bots that present and manage the front-end in a trustless manner.
The address the user sent TxF to was an ‘oversight’, which are a second type of bot that have wallets (two kinds of wallets to be specific), the TxF is used to send an OP_Return transaction;
The OP_Return is a message placed in the output of a transaction (sometimes called an “Output Transaction”); it sends a user specified message to a non-existent address. But back to the point; Internal balance updates write new messages into the ledger without initiating the third kind of bot; a ‘main ledger’. But because we withdrew that constitutes an external update.
The ‘Main ledger’ in this case first withdraws the specified funds to a “checking contract” a ‘main ledger’s’ “main treasury” can only send to a “checking contract” — with enough excess funds to cover TxF — the checking contract then sends the funds to the user’s actual public key.
Creating a Token
So, let’s undo that; let’s deposit our funds back into the ‘main ledger’ smart contract, at the user’s account page they can “deposit”
Once our funds are back in the Simple ledger (SLg), we can click “create token” which will give us the option of creating a Non-fungible or a fungible.
Let’s go with Fungible for now.
The options allow the user the customize some basic parameters of the token, to deploy; the user must first sign a D-Sig, then send a specific amount for TxF and token creation fees (arbitrary payment to the node operators). The creation fee is calculated in Test-by-Finality or TeF, a concept I created to use average COIN transaction amount and NEO bandwidth speed to estimate the price of COIN without using an oracle. TeF is used to create stable currencies, if a deployer uses TeF in their token this means their token’s price is fixed at whatever they initially set, it cannot go above or below TeF. More info on TeF here.
So, once we process this transaction it should look like this on the blockchain;
However, our token will not be tradable unless we provide adequate liquidity for it, Adequate liquidity is 105% of the token’s initial price multiplied by supply. So, if we have a token with 1,000,000 initially worth 0.0025, we would need 2,625TeF to provide adequate liquidity. (The TeF price is converted to COIN).
Once adequate liquidity is added, the token’s supply is updated and it can now be bought or sold, anyone can add liquidity by sending COIN to the token’s address “Token#-Ae1w…vv37”. When adequate liquidity is above 105% all fees would instead be paid out to the deployer, fees can be as high as 5% but no more, and only as low as 0.01%
Conclusion
With this system the bots are acting as intermediaries, if users were simply allowed to issue ledger entries on their own without an entity to regulate it, that would lead to chaos, protective measures against bot tampering are outlined in the design paper.
HYPR is what makes this all possible, otherwise the system would need to be protected through encryption, and that would inevitably result in a layer 2 network as more and more systems need to be tacked on to compliment that encryption.
However, I will note this; the process for executing transactions using the web viewport is extremely convoluted and would require much acclimatization. To this end, an API will be made alongside a modified version of an open source Bitcoin wallet, thereby allowing users to automate the process, this could potentially be used in a mobile app as well, but the WebView will still be usable if you are so inclined. With that said, this document is concluded.
Thanks for reading, if you enjoyed the concept and have questions about the network’s security, you can read the design paper here.
