1 of 100

Peerplays Community Docs

Introduction to Peerplays

The code for this documentation portal is on GitHub and we would welcome all contributions from the community.

What is Peerplays?

Peerplays is the humanizing crypto platform.

Peerplays is a decentralized, global crypto platform, bringing a new paradigm of fairness, transparency, speed, and security. Built with Graphene technology and Gamified Proof of Stake (GPoS), Peerplays provides the fastest, most decentralized blockchain consensus model available today.

Why Peerplays?

Peerplays is building an ecosystem of decentralized products and apps, offering people a real alternative to untrustworthy and greedy centers of control.

The Peerplays blockchain is a game-changer for people and communities around the world:

Provably Fair – Every Peerplays software component has been designed to provide a fair experience. And, unlike with traditional platform operators, all Peerplays software is open-source and publicly audit-able. Peerplays sets new standards for provably-fair networking.
100% Real-Time Transparency – Peerplays publicly broadcasts each transaction as it is executed on the blockchain in real-time. As soon as a transaction is placed, anyone can view the full audit trail of that transaction, marking a step-change in economic standards for transparency.
Fast, Secure, Anonymous Control – Peerplays integrates with all digital currencies (Bitcoin, ETH, HIVE, etc.) to provide fast, cryptographically-secured deposits and withdrawals, immediate access to funds, and anonymous control over each and every transaction.

Who is Behind Peerplays?

A number of different groups and individuals share jurisdiction over the Peerplays blockchain, which ensures no single entity can gain control over the network. These groups and individuals include Witnesses, Advisors, and PPY token holders. For more information on the governance of the Peerplays blockchain, please visit the Governance section of this website.

The Peerplays blockchain software has been developed by the Peerplays Blockchain Standards Association (PBSA), a non-profit organization based in Canada. For more information on PBSA, please visit .

Concepts

Consensus Mechanisms Compared

The differences among POW, POS, & POP (and their variations)

1. Consensus

In the realm of crypto-economies, consensus is the way decisions are made that impact a whole network despite having no central decision-maker. Systems must be in place to allow everyone to agree on transactions happening in real-time across the globe. This is why the developers of blockchains have carefully crafted mechanisms of consensus to try to preserve decentralization while also maintaining mutual agreement of all members of the network.

Here we will explain the most widely used and well known consensus mechanisms, Proof of Work and Proof of Stake. We will also introduce a new consensus mechanism which serves to be the latest evolution and a paradigm shift to the approach of consensus, Proof of Pulse.

Technology

Intro to Peerplays Tokens

A brief guide to the various tokens of Peerplays.

1. Overview

Cryptocurrency (crypto) tokens represent tradable assets or utilities that reside on a blockchain. There are many uses for these tokens and their usefulness is growing in scope and scale at a remarkable pace. For example, just some of the things tokens are used for today:

a store of value, like fiat currency

Staking (PowerUp) in Peerplays

Downloads

The Diagram in PDF form to easily view and share:

The Diagram in Draw.io's XML format. You can edit the diargam using this file in Draw.io:

Gamified User Namespaces and Subject Matter Expert Committees

A brief introduction to GUNs and SMECs using the SPK network as an example.

1. Gamified User Namespaces

SPK network, a Peerplays community, will have its own namespace when users register that will always end with .SPK. Under this authority, dapp protocols will automatically whitelist these users for various operations relating to community governance. The gamified user namespace (GUN) will provide a means of onboarding new user accounts at little to no cost and will gamify the process of becoming a full user.

Registration > randomname.SPK - keys (no fee)
Deposit Funds > option to choose username.SPK (fee set by a Subject Matter Expert Committee, or SMEC)
Engagement via Rewards Engine Parameter > option to choose username.SPK (fee set by SMEC)

The user accounts that operate under .SPK will have special switches which are associated with SPK network SMEC which will allow them to be able to vote on the rate of fees for operations. Before voting these operations will be whatever the current rate on Peerplays stands. Voting capabilities will be available only to the holders of SPK-NFTs, BRONCA-NFTs, or LARNIX-NFTs depending on what works best for the SPK network.

There will be many random sources which will be shared for account registration due to the faucets being built into network infrastructure nodes.

2. SKP Network NFTs Backed by Liquid Staking

SPK-NFTs are created by staking SPK and will have the capability to lock for up to 10 years (can be longer if set in the token parameters). If no period is selected they will, by default, stay locked with an inverse time to withdraw. This means if they stay locked for 30 days, it would take 30 days to withdraw if they initiated this on the 30th day to get their SPK out of the NFT. The NFT is then burned.

An alternative to destroying the NFTs would be to sell them on the NFT Marketplace and get access to their SPK or any other asset they want to sell it for instantly without the SPK needing to be unlocked from the NFT for whatever staking period may have been selected.

The staked SPK goes into the SPK Liquidity Pool with AMM DEX to power liquidity in SPK markets. The SPK market fees then flow back to all the SPK-NFT holders proportionally. The SPK-NFT that gets issued will have a PowerUP rating associated with the amount of SPK that was used to stake into the NFT. This gets used as the measure for rewards they receive. This means that the longer term someone commits to the staking period, the greater the rewards they will receive. When rewards are paid out they must be claimed by the user account and can be in the asset of their choosing supported in Peerplays. This means they could get SPK, BTC, PPY, HIVE, or any other assets available. If this is not desired, limited options can be made available in user interfaces.

These NFTs will be governed by dynamic properties while at the same time being capable of having custom "skins" for users preferences which can have additional gamification benefits.

For more information on Staking and Liquidity Pools, see here.

3. Subject Matter Expert Committees (SMECs)

Based on the SPK-NFT PowerUP, the user will be able to cast voting in various matters relating to the network.

Voting power is determined by the length of time the NFT has existed and the staked length. A linear scale starting from zero to the period staked provides that amount of weight multiplier the voter carries. This means someone who stakes for 10 years will not get the full weight multiplier on their stake, but instead will have it added to their account over the period of the stake with each coinday. Likewise, someone who has decided to stake by default with accumulating locking will experience the same multiplier effect over time. However, the staker of 10 years will have their weight increase from day one, as their multiplier has been predetermined by the 10 year commit.

This ensures that long term actors are the ones who will be able to carry more influence, but they will only have that influence accumulate over time. The only way for new people to gain this added vote power would be to accumulate SPK-NFTs from the marketplace which have been aged, thus increasing the subjective value of the SPK-NFTs.

Using the SPK-NFT the user can vote on the parameters of the network to determine what rates should be paid for fees on various operations. Some operations may be the rewards earned for holding SPK-NFTs that are generated from the DEX/AMM Liquidity Pools. These come from parameters set in the SPK market which will only be able to be controlled via voting among username.SPK accounts, and SPK-NFTs.

Another element which username.SPK users will be able to use are the operations of the SMEC which enables the users to vote for a committee of members which can be funded through various mechanisms. The SMEC do not have direct access to the funding pool but instead must approve proposals which should be used for their mission intent. Effectively the SMEC acts as a manager, and the ones who are doing the work are being paid by the proposal. Payouts for the funds only occur monthly when the SMEC publishes a progress report on the activity so as to provide concise communication feedback to the community at large.

Multiple SMECs can be created by the username.SPK community for any number of reasons beyond just funded work. Typically SMECs might include, but are not limited to, marketing, sales, development, legal, and payment gateways. The SPK.SMEC could also be configured so that the SPK market fees can flow to the SPK.SMEC for funding.

Peer-to-Peer Autonomous Organizations: Flow Diagram

Flow Diagram

Downloads

PDF

XML

Wallet User Guide

Version 1.5 of the Peerplays Core Wallet added the GPOS functionality for the first time; this document will step you through the new features it implements to ensure you qualify for maximum participation rewards.

GPOS Panel GPOS Landing Page Power Up Power Down Vote Thank you for voting!

GPOS Landing Page

The landing page is the entry point to use the different GPOS features.

Power Up

Clicking on Power Up will take you to the deposit screen where you can vest PPY towards GPOS and in turn, add to your participation rewards.

You can click Power Up at any time since you are free to come back and vest more PPY at your discretion.

Power Down

Clicking on Power Down is very similar to Power Up except this time you'll be taken to the withdraw screen.

You can withdraw form your GPOS balance at any time up to the value of your balance.

Important: If you have a GPOS balance of zero the Power Down button will be disabled

Vote

For anybody familiar with earlier versions of the Peerplays wallet, the voting section is much the same as before. Only the steps to go through to access this feature have changed.

Important: If you have a GPOS balance of zero the Vote button will be disabled

Power Up

After clicking on the Power Up button on the you'll be taken to the Power Up screen; from here you can add to your GPOS balance.

The functionality of this screen is very straightforward. Simply select an amount of PPY to vest by either entering it in the Deposit field, or scroll the amount up and down using the + and - buttons.

Important

Power Down

If you have a GPOS balance then you can access the Power Down screen from the .

After clicking on the Power Down button you'll be taken to the Power Down screen; from here you can withdraw from your GPOS balance.

Unsurprisingly the Power Down screen follows a very similar format to ; you just use it to withdraw from your GPOS balance, instead of adding to it.

And just like the screen you can select an amount by scrolling up and down using the + and - buttons. The amount you select will be shown in the Withdraw field and reflected in your New GPOS Balance.

You can withdraw up to the total amount of your Opening GPOS Balance.

Vote

If you have a GPOS balance then you can access the Vote screen from the .

After clicking on the Vote button you'll be taken to the Vote screen from where you can vote for Witnesses, Advisors and Proxies.

The voting functionality hasn't changed from previous versions of the Peerplays Wallet so will only be documented briefly here.

Proxy

Proxy voting allows you to select another token holder to vote on your behalf. As far as GPOS goes this still constitutes participation as you have made a commitment to the operation of the blockchain.

Thank you for voting!

You made it this far; now you qualify for participation rewards for contributing to the governance of Peerplays.

After you vote you'll see the following screen:

So like the avatar says, go and share your experience with your friends, family and the Peerplays community.

FAQ

General

What is GPOS?

GPOS is short for Gamified Proof of Stake which is an advanced implementation of the DPOS consensus mechanism.

GPOS gives voting weight and rewards to all token holders that commit some of their PPY balance as a vested GPOS balance. For more information see Gamified Proof of Stake.

What is a vested balance?

The best way to understand this is to compare it to the difference between stock options and shares. If you hold stock options you have a stake in the company, but the options have no value unless you can profit from them and to do this the options have to first be vested as shares.

GPOS works the same way, instead of all token holders being entitled to dividends just by virtue of holding tokens (shares), token holders now have a PPY balance (options) that they only profit from when they are vested in GPOS (become shares).

Are there any fees associated with GPOS?

Yes, there is a fee of 1PPY for Powering Up (depositing) and a nominal fee of 0.01PPY for Powering Down (withdrawing).

What happens to the fees?

The fees are 'burned', that is to say they return to the reserve. The reserve can then be drawn on for block rewards for the block producers.

No, in fact far from it. GPOS gives you every opportunity to not just receive the same dividends as before but actually get higher dividends if there are token holders that don't vote. Just remember to vest a GPOS balance and then vote at least once a month.

Why is GPOS better for Peerplays?

GPOS encourages all PPY token holders to take a much bigger interest, and say, in the governance of the blockchain. This will strengthen the democratic process that goes into electing the operators of Peerplays, and make them much more accountable.

Before GPOS token holder voting was poor and that opened up the opportunity for one or two major token holders to influence the operation of the blockchain. Full participation by token holders in the voting process will mitigate this risk and keep the blockchain secure.

GPOS Panel

What is the difference between Qualified Reward and Estimated Rake Reward?

Qualified Reward is the percentage your maximum possible reward based on voting performance. This reward decays at a rate of 16.67% per month.

Estimated Rake Reward is the potential percentage reward you could receive based on the Qualified Reward percentage, the amount of PPY you have vested and your share of the total GPOS balance.

For more information see

Power Up & Power Down

Why can't I vest my entire balance?

There as a 1PPY fee every time you power up (deposit) to your GPOS balance. So you must make sure you have enough PPY left to cover the transaction fee.

Voting

Does GPOS affect how I vote?

Yes and no. The functionality of the voting feature in the Peerplays wallet hasn't changed in the newest version, only the steps you go through to vote have changed.

But GPOS will effect your voting habits as it requires regular participation.

Participation Rewards

How are participation rewards different from traditional dividend payments?

GPOS introduces a number of significant changes to the old method of dividing the Peerplays rake between all token holders relative to how many tokens they hold.

The biggest change is that the percentage of the rake is based on the total of all GPOS vested balances, and not the cumulative value of all PPY in circulation. This gives the opportunity for regular voters to get a larger share of the rake than before by virtue of other unreliable voters.

I'm confused, just how exactly are my rewards calculated?

At first the new formula for calculating your estimated reward percentage can be a bit confusing; this example should help:

If you have a GPOS balance of 1,000PPY, and have voted recently, so you have qualified for a 100% reward, and the total GPOS balance on the blockchain is 4,000,000PPY when the rake is distributed, then your percentage of the rake would be:

(1,000 / 4,000,00) * 0.025%

What you'll actually receive as a dividend is based on the monthly rake, so if the rake is 100,000PPY then you'd receive 100,000 * 0.025% = 25PPY.

Sidechain Operator Nodes (SONs)

Sidechain Operator Nodes - SONs facilitate the transfer of off-chain assets (like Bitcoin, Hive, or Ethereum tokens) between the Peerplays chain and the asset's native chain. These nodes often run the Peerplays node software and node software of other chains.

The software used to run Witness, API (full), Seed, and SON nodes is named witness_node. All these node types are run with the same software. What makes these nodes different is how that software is configured and how it's used.

SONs will also require the use of software supplied by other chains, like Bitcoin Core for example.

BOS nodes use a collection of software known as the Bookie Oracle Suite.

New to SONs?

Here's everything you need to know about how the Peerplays SONs work? what are the problems they solve?

Bitcoin and Ethereum are slow and expensive to use.

Currently, Bitcoin can process only 4.6 transactions per second. The average confirmation time for a BTC payment is about 10 minutes. For context, Visa does around 1,700 transactions per second on average. On the other hand, Ethereum fees are extremely expensive and through the roof. Scalability is a serious issue for both networks.

Is there any way to overcome these problems? Sidechains may provide a solution.

If you’re new to Sidechains, then this is the perfect place to start.

What are Sidechain Operating Nodes?

In order to improve the performance of Bitcoin and Ethereum, a unique mechanism is required. Sidechains can help move tokens, perform transactions faster and cheaper.

Sidechains provide the way to seamlessly transfer value between multiple blockchains and to operate Sidechain SONs node are used.

Sidechain Operating Nodes (SONs) means a lot to the blockchain world. SONs provide a way for blockchains to interact with each other. Those nodes are in harmony with each other like a handshake which ease the process of transferring tokens from Peerplays blockchain to and from another blockchain.

Sidechains solve a problem known as Inter-Blockchain Communication (IBC). This problem takes place when blockchains have different protocol types (also called consensus mechanisms, like Proof of Work, Proof of Stake, Delegated Proof of Stake, etc.)

Peerplays SONs are decentralized, trustless, and elective.

How do SONs Work?

Hinted through their names, these Sidechains run alongside a root or “parent chain.” When you transfer funds, they're locked on the parent chain and then released onto their respective sidechain. You can then move them around at will until you decide to return them back to their original chain.

Anyone can enable a Sidechain Operating Node. However, that is not enough to run a SON. You must be an ‘active participant’ in the Peerplays community and receive votes in order to qualify to become a SON. Since Peerplays blockchain is Gamified Proof of Stake, this incentivizes voting for those who run SONs.

Once a SON finds a particular transaction which is signed by 2/3rd of other SONs, that SON will post the transaction to the Peerplays blockchain. Upon receiving the transaction, the SON will verify the transaction details with the appropriate blockchain. If the data on the source blockchain sidechain seems to be intact, the SON will sign the transaction and publish it. This helps prevent any SON from malicious transactions.

Why are SONs important?

SONs help the blockchains scale and develop more quickly. Blockchains like Bitcoin or Ethereum have to validate every new transaction on their own. But SONS only have to periodically refresh information from the root chain with updates about transactions. Which means massive scalability without sacrificing security or decentralization!

The problem with blockchains out there that offer inter-blockchain communications like Cosmos and Polkadot is that they ‘talk’ only with other blockchains that are identical like them. This doesn’t really solve the problem of blockchains interacting with one another. It creates a situation where a ‘foreign’ blockchain must switch over to another blockchain that is able to communicate with a blockchain that is ‘compatible’ with Polkadot or Cosmos.

That’s why Peerplays SONs technology is an innovative, elegant solution.

How do SONs impact me?

You can think of SONs as a two-way street. The value of two blockchain tokens is going back and forth safely and smoothly.

To paint a picture, let’s imagine you’re sending your bitcoin from an address to a sidechain. This bitcoin is then represented on the other side of the new blockchain. You are then able to move this represented bitcoin without touching your original bitcoin.

This offers scalability for bitcoin. For example, let’s say another blockchain can perform 50,000 transactions per second. Now Imagine being able to operate your bitcoin at that speed. This opens up endless possibilities about the applications Bitcoin could be used in.

It could really be the answer for worldwide adoption.

SON Fees & Performance Requirements

SONs get paid out from a daily reward pool for signing transactions and the weight of voting. Both the transactions they approve and reject are counted in. Bitcoin transactions in Peerplays blockchain get validated to ensure they originated from the SONs.

When a SON changes, their private key on the bitcoin address gets replaced with the private keys of the new incoming SON.

The performance of SONs is also tracked. Their errors, uptime, missed blocks, and similar errors provide historical performance data for voters. Witnesses have the power to freeze a SON or blacklist them if necessary.

Peerplays SONs

Bitcoin and Ethereum are slow, expensive to use, and not scalable enough for mass adoption and usability. They can’t support high transaction throughput.

SONs provide an alternative way for blockchains to communicate with each other, which opens up new possibilities in terms of scalability and interoperability.

Peerplays SONs are decentralized, trustless, and elective. The side chains are as secure as they can get. They can keep the scalability trilemma at bay (security, decentralization, and scalability).

Public open decentralized blockchains are the way to go forward. We here at Peerplays are committed to making sure whatever we create is not centralized and can’t be manipulated.

FAQ

1. What is the transaction finality time for withdrawals and deposits of BTC?

Six transaction confirmations are the recommended value for transaction finality on the Bitcoin blockchain and thus its recommended to set the value at 6 confirmations for Bitcoin SONs. (reference: https://web.archive.org/web/20210218094358/http://bitcoins.net/guides/bitcoin-confirmations)

2. What is the daily reward pool set at right now for sons nodes?

Funds equivalent of 200 PPY is set aside and its distributed among SONs proportional to their performance. This value can be changed by the committee.

3. I have also noticed that my server is running at 100% at all times. Is it trying to mine test btc?

No, when you are connected to SONs network as a seed or a SON itself, you won't be doing any PoW mining. SONs just listens on the Bitcoin network for any incoming transfers to Peerplays BTC addresses.

NFTs and Marketplace

NFT marketplace in Python

Describing here the steps to verify the Marketplace_python on local or server machine.

Machine configuration : Local or server machine.

Step 1: Clone Marketplace_python binaries on machine

Project Url :

Clone binaries on Machine:

Step: 2 Install virtual env on machine

Go to project:

Run:

Step: 3 Install python requirements

Run:

And then:

then:

Step: 4 Run unit tests

Run:

Expected result should be as below:

NFT Operations in Python

Describing the steps to verify the NFT_python on local or server machine below.

Machine configuration : Local or server machine.

Step 1: Clone NFT_python binaries on machine

Project Url :

Clone binaries on Machine :

Step: 2 Install virtual env on machine

Go to project :

Run:

Step: 3 Install python requirements

Run:

then,

And then,

Step: 4 Run unit tests

Run:

Expected result should be as below:

Cheers, all unit tests are passed and you successfully verify the NFT_python

NFT command reference

Step: 1 Create Metadata

Command used : nft_metadata_create <<account_name>> <<metadata_name>> <<metadata_symbol>> <<base_uri>> true true true

For example : nft_metadata_create account01 sknft sknft sknft null null true true true

Step:2 Update Metadata

Command used : nft_metadata_update <<account_name>> <<metadata_id>> <<new_name>> <<new_symbol>> <<new_base_uri>> null null true true true

For Example :nft_metadata_update account01 1.30.1 sknft01 sknft01 sknft01 null null true true true

Step: 3 Create NFT

Command used : nft_create <<account_name>> <<metadata_id>> <<Owner_account_name>> <<approve_aacount_name>> <<token_uri>> true

For Example : nft_create account01 1.30.0 account03 account03 sknftmint true

Step:4 Get NFT balance

Command used : nft_get_balance <<account_name>>

For Example : nft_get_balance account01

Step:5 To verify the owner of created NFT

Command used : nft_owner_of <<nft_id>>

For Example : nft_owner_of 1.31.1

Step:6 Safe NFT transfer

Command Used : nft_safe_transfer_from <<Operator_account_name>> <<transfer_from_account_name>> <<transfer_to_account_name>> <<nft_id>> true true

For Example : nft_safe_transfer_from account01 account01 aaccount02 1.31.1 true true

Step: 7 NFT Transfer

Command used : nft_transfer_from <<Operator_account_id>> <<From_account_id>> <<To_account_id>> <<nft_id>> true

For Example : nft_transfer_from 1.2.31 1.2.31 1.2.28 1.31.37 true

Step:8 NFT Approve

Command used : nft_approve <<new_operator_account_id>> <<new_account_id>> <<ndt_id>> true

For Example : nft_approve 1.2.19 1.2.19 1.31.1 true

Step : 9 To approve all NFTs at once

Command used: nft_set_approval_for_all <<Owner_account_id>> <<Operator_account_id>> true true

For example : nft_set_approval_for_all 1.2.21 1.2.21 true true

Step: 10 To see the approved account details

Command used : nft_get_approved <<approve_nft_id>>

For Example: nft_get_approved 1.31.0

Step:11 Approved for all

Command used: nft_is_approved_for_all <<owner_account_id>> <<operator_account_id>>

For Example : nft_is_approved_for_all 1.2.21 1.2.21

Step :12 Get list of all created NFT

Command used : nft_get_all_tokens

With this - all the created NFTs are listed on the machine.

User Guide

The user guide helps user to understand the various functionalities of NEX application. The below section guides the user to perform desired operations,

1. Account Creation

This section helps the new user in account creation. It also explains the existing user login operation. Click the below link to learn about this in details,

Account Creation

The page to create login for new users

Creating an Account

Navigate to PeerplaysDEX dashboard.
Click on Create account to create a new login.

3. Enter the desired Username.

The user name should start with lowercase.

The user name should not contain,

Capital Letter
Special Characters

4. For the first time, the password is auto-generated. Copy that password and paste it into the "re-enter your auto-generated master password" box.

5. Click "Download Recovery password file here" option to download the Keys to use for future login.

6. Enable the checkboxes and click on create account.

7. After successful login, the following screen will be displayed.

Bitcoin Transaction

An example to get the bitcoin address

Depending on the wallet that you’re using, you may have to use a tool like bitaddress.org to find your Public Key if it’s not already displayed in your wallet.

Wasabi Wallet, for example, displays your Public key.

But wallets like Trust Wallet and Exodus require you to use external tools like bitaddress.org to find your Public Key.

In this example, we’ll be using Wasabi Wallet as the Deposit address and Exodus as the withdrawal address.

As you can see in the image below, the Deposit Address (Wasabi Wallet) is bc1qhlu97p4ehnvt2274na5xqra5n8a8cnumavatn3

The Deposit Public Key is 02d5a014ec94974a01b5b81550bbcf6a629715140d38e7da5f1c2c71ccdcd8b61c

The Withdraw Address (Exodus Wallet) is bc1qrk768lztvrjduama2ruuut9eweamtz5ru4vmhl

But we must find the Withdraw Private Key.. Here’s how:

Open your wallet. As seen in the image above, click on the three dotted lines and click “View Private Keys.” Then Click ”Yes, I’m sure.”

Next, type your account password.

And now you’ll see your Bitcoin deposit Address as well as your Private Key. Copy the address that starts with bc1 and it’s Private key.

The Withdraw Private Key is L5896NkkABQ9PCcWHQiM1tAyFWoPtaEf1uLRQ5eG7nTvzXeXY29g

We will now use the Private Key to find out our Public Key. Simply head over to . Then, click “Wallet Details”.

Paste your Private Key and click “View Details.”

You will find your Public Key over here. Make sure you copy and paste the compressed, 66 characters [0-9A-F] and NOT the 130 Characters key.

We now have the Deposit Public Key, the Withdraw Public Key, and the Withdraw Address.

Deposit Public Key (Wasabi Wallet – already displayed): 02d5a014ec94974a01b5b81550bbcf6a629715140d38e7da5f1c2c71ccdcd8b61c

Withdraw Public Key (Exodus Wallet – found through bitaddress.org): 038F14B6B61EF0AE7EF8317E757807CA8322257C96D54635979C1FBBB899621AF2

Withdraw Address (Exodus Wallet): bc1qrk768lztvrjduama2ruuut9eweamtz5ru4vmhl

Settings

The settings page helps the user to manage the activities of the accounts like language selection, lock account, notification settings, key management, and membership.

There are three sections in the settings page,

General
Key Management

Wallet

The wallet option allows the user to view the asset available in that account. It also has the option to send and receive assets from other accounts.

The Wallet has three sections,

Asset
Send
Receive

Profile

The profile page displays the information about the orders, activities and notification of the account.

1. Orders

The order tab displays the collection of all details about the Open order and Order history happened from the beginning of account creation.

It also provide the option to download the PDF/CSV file in a single click.

Logout

To logout of the account, the user has two option.

The user can click on the account name in the header tab and choose logout option.

2. The user can click the menu option and logout will be at the bottom of the list.

Witnesses

Bookie Oracle Suite (BOS)

Data Proxies

Couch Potato

Random Number Generator (RNG)

RNG API

Get a random number

bound: The upper limit for the random number.

A random number within the bound range.

API

Peerplays Core API

Asset API

Asset

get_asset_holders

Get asset holders for a specific asset.

Block API

Block

get_blocks

Get signed blocks.

Network Broadcast API

The network broadcast API is available from the full node via web-sockets.

Transactions

broadcast_transaction

Broadcast a transaction to the network.

The transaction will be checked for validity in the local database prior to broadcasting. If it fails to apply locally, an error will be thrown and the transaction will not be broadcast

trx: The transaction to broadcast

broadcast_transaction_with_callback

This version of broadcast transaction registers a callback method that will be called when the transaction is included into a block. The callback method includes the transaction id, block number, and transaction number in the block.

cb: the callback method
trx: the transaction

Block

broadcast_block

Broadcast a signed block to the network.

block: The signed block to broadcast.

Network Nodes API

The network node API is available from the full node via web-sockets.

Obtain Network Information

get_info

Orders API

Orders

get_grouped_limit_orders

Get grouped limit orders in given market.

vector<limit_order_group> graphene::app::orders_api::get_grouped_limit_orders(
    std::string base_asset, 
    std::string quote_asset, 
    uint16_t group, 
    optional<price> start, 
    uint32_t limit)const

base_asset: ID or symbol of asset being sold
quote_asset: ID or symbol of asset being purchased
group: Maximum price diff within each order group, have to be one of configured values

The grouped limit orders, ordered from best offered price to the worst.

Wallet API

The wallet (cli_wallet) requires a running full node to connect to because it does not offer P2P or blockchain capabilities directly.

If you have not set up your wallet yet, you can find more information here: CLI Wallet Setup.

Account Calls Asset Calls Blockchain Inspection General Calls Governance Privacy Mode Trading Calls

Blockchain Inspection

get_block

Returns info about a specified block.

Bookie API

Listeners

subscribe_to_market

Subscribe a listener to a betting market.

updateListener: An object of type updateListener.

Python Peerplays

Introduction

Its the Python library for communicating with the Peerplays blockchain.

The code is maintained at https://gitlab.com/PBSA/PeerplaysIO/tools-libs/python-peerplays

Ids

1.2.x : accounts

1.3.x : assets

Notes

p.rpc.get_account_balances("jemshid", [])

p.rpc.get_global_properties

private-key = ["TEST6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV","5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3"]

GitLab

Known Issues

Decentralization

1. What is Decentralization?

You've been hearing the word decentralized being thrown around. What does it mean?

Decentralization refers to the transfer of control of an activity or organization to several local offices or authorities rather than one single entity. This can be ambiguous because "several" can refer to anything from as few as three to as many as there are members of an organization (like multiple boards of directors vs. every single member of the organization.) In many organizations, this can create a smoke screen where the perception of freedom is created to hide the real aim of the organization; control for the few. The more decentralized the organization, the greater capacity there is for its members having control. In order to assess the level of control we will have when joining an organization that claims to be decentralized, we must assess the organization’s methods of decentralization.

2. Quantifying Decentralization

Examine the level to which the organization has dispersed its control. First, how many modes of power have been decentralized and to what extent has each mode been decentralized? To judge the number of modes, we must understand these modes and the impact that they have on an organization. These modes are decision making, narrative, enforcement, and innovation.

2.1. Decision Making

Decision making refers to the ability to choose and implement avenues of change within bounds. This could mean the day-to-day decisions in each department, which has generally been the role of employees and managers within centralized systems. The power to make decisions extends to the highest level of the organization. Decision making determines how money is obtained, how it is distributed, which solutions are attempted, which risks are considered worth taking, how compensation is determined, and so on.

Much of the decision making power in centralized systems have been delegated across departments with a single party or small group of parties responsible for the implementation of suggestions made by each of these departments. For example, a human resources department may assess the compensation needs of all employees based on department and employee generated criteria and then propose a compensation and benefits package that every member of the organization would find fair. If, however, this package were to be vetoed by the CEO of the organization, the implementation of this package would not occur.

In a fully decentralized system, each employee would be asked for input, the suggestions would be compiled into a cohesive package and assessed for feasibility, and implemented once a sustainable agreement was found without the backing of a higher authority. While this may seem time consuming due to the need for negotiation among those providing opinion, ultimately the result of such negotiations allows each member to take ownership, feel valued, and have the opportunity to understand the reasoning for decisions. In this way, discontentment among staff is avoided and the organization has the support of all of its members.

2.2. Narrative

The narrative of an organization is the union of several pieces of human generated experience.

First, it is made of organizational data.
Second, it is made of the value system, mission statement, and goals of the organization as a whole.
Third, it is made of the values and goals of each individual member of an organization, including those that are never voiced (For example: plans for furthering education, competition among members, personal problems, etc.)

To truly understand narrative and its impact on an organization, it can be helpful to think of Ecological systems theory developed by Urie Bronfenbrenner (see Figure 1 & ). While Bronfenbrenner’s theory relates to the development of people, an organization will be treated as an individual within public consciousness. Its development must be treated as any other individual, with the understanding that it too is made of individuals.

Both the narrative of each member and the narrative of the organization as a cohesive whole acting as an individual in the public sphere must be taken into account when control is considered. Errors in representation are always made when a group is unable to speak for themselves. The perception of individuals within a group and the group as a whole will come from how those outside the organization receive the narrative. The narrative of the organization as a whole will also create the perception of its members. To control the narrative is to control how you are seen. A negative perception at any level helps no one, and is often a source of much anger, resentment, and embarrassment among those who do not feel accurately represented. Representation matters.

2.3. Enforcement

Enforcement is the act of compelling observance of or compliance with a law, rule, culture, or obligation. The control of enforcement must be given careful consideration. In a centralized system, there is always a bottom tier that has no power to enforce, and no one has authority of the top tier outside of state and national law. While those without punitive authority are able to report to those higher or provide feedback to each other, they ultimately do not have the power to ensure that every member of their group is abiding by the established rules and culture. More often than not, only those at the highest level of the authoritative hierarchy are able to set rules and devise the means by which these rules are to be enforced. A lack of enforcement means that a rule is not taken seriously, and is therefore not a rule. Too much enforcement can generate fear and distrust of authority figures, which can negatively impact performance in a variety of ways.

The alternative to this hierarchical approach is to encourage as much organizational ownership as possible to the creation and enforcement of rules and organizational culture as possible. In an article published at , Lizz Fields-Pattinson promotes the idea that "when we have a stake in how we’re supposed to approach the world around us, we feel a sense of social belonging and alignment with the people who share that world-view," so it is beneficial to "involve more people in the decisions which affect rules or codes of conduct from the start, that way you encourage a larger number of engaged advocates to back your cause." This is echoed by Market Business News: "People feel motivated to follow through when they feel that they are part of the program."

While it may still be necessary within an organization to have an authority group that is charged with enforcement, there are ways to decentralize this mode of control so that there is no hierarchy. For example, in the beginning stages of the formation of rules and consequences, all member should be invited to share their vision of the standard by which operations are to be run and what should be the consequence for an individual that does not follow the standard. Once a code of conduct and levels of intervention have been established, a review process can occur within set cycles to ensure that new members have an opportunity to weigh in and necessary changes to the system can be established and implemented. To ensure that all members are held accountable, delegates can be chosen for a disciplinary committee on a rotational basis on which all individuals have the opportunity to serve. Team managers can be chosen based on experience and training criteria, but also be subject to peer review by those they manage. In a system such as this, all members have the opportunity to provide and receive feedback, and no one is in a strictly subordinate role.

2.4. Innovation

Innovation refers to the development of something new. This applies to products, but also any idea, method, or procedure at any level within the organization. In general, the control of innovation has everything to do with who is given the authority to try new things and to make suggests. In a typical centralized organization, innovation is reserved for specific departments and the categories of thought are siloed. Consider that human resources, research and development, manufacturing, and marketing often have no need to communicate, yet individuals within every department are affected by the ideas generated by each group. Also consider that individuals may have expertise separate from their job role. For example, a member of the production line may be obtaining a social work degree and therefore generate an idea that could be useful to human resources. If there is no means by which these ideas can easily be shared, they likely will not be. A suggestion box is only useful when the ideas within are actively considered.

3. What does this mean for me?

In a centralized system, primary decisions are made by the person or group at the very top of the organization, such as a board of directors or a CEO. To move away from this model, an organization may begin to allow latitudes to "lower" levels of the organization, but maintain functions such as research, development, and records keeping for the highest levels of the organization. So, even if basic decision making is now shared throughout the organization, the upper levels maintain control of innovation and any long-term changes are not easily accessible to those who have the power of basic decision making.

While blended systems such as these seem to allow freedom, those with voting power can only choose those options they believe are available to them. Consider that daily decisions may be short lived and have little impact on the direction of the company. Without the ability to innovate, the future direction of the company is still controlled by a central group. The suggestions leading to innovation will be generated by research and development which, being controlled by a centralized group rather than open to all, are funneled. Any decisions therefore are controlled by a central group.

The same is true for the control of narrative, especially by way of data and information regarding changes within the organization. Consider an organization’s turn over. If those involved in decision making are gradually replaced by others over time, those new to the organization will only know of what has recently come to pass without the ability to access all records. If the records are maintained by a central group, again there is the concern of funneling. When documentation is restricted, openness is jeopardized, as is timeliness. Further, a single copy of historical records is subject to corruption. Any changes made, whether accidental or intentional, will have no basis of comparison. If, however, every person with power of decision were to have their own copy of all documentation records, access will be automatically granted and immediate, and discrepancies will become apparent between copies.

When all aspects of an organization are fully decentralized, there is no limit to its innovative potential. Rather than suggestions being funneled from a centralized viewpoint. Each member is free to make suggestions relative to their perspective within the organization. Each suggestion may be assessed for utility by all those with power of decision and implemented with expediency. There is no need to wait for approval from a centralized power. Majority support cannot be overturned by a single voice. Once accepted and initiated, it will be up to market trends to decide outcomes. Counter-changes can be made just as quickly if market trends show a need. This flexibility in innovation allows for timely adjustments and increases the likelihood for rapid growth and success.

Likewise, the increased access of information allows for better integrity within the organization. Consider the human dynamic within organizations. While no one wants to think the worst of an organization’s members, mistakes will happen and people can give into temptation. In a centralized system of records keeping, it is up to a single group to catch all errors or intentional fudging. When there is no basis of comparison, it can take time to reconcile places where figures do not make sense. The more transactions occur, the longer it can take. When information is decentralized, however, there is a large basis for comparison and every individual with a copy has the ability to compare with others. Discrepancies are far more noticeable. If a single copy varies from the others, it becomes easier to fix and easier to trace its source. Unless each copy where to be simultaneously corrupted, there would be no way to hide a discrepancy. Since each copy is housed separately, it would be nearly impossible to effect a change across the entirety of records. The contents of the documentation are therefore trustworthy.

It is only when all aspects of an organization are delegated that an organization can truly claim to be decentralized.

Appendix A

Ecological systems theory was developed by Urie Bronfenbrenner. The six systems described in his theory, and outlined in Figure 1 (above) are as follows:

Individual (or Organization): This can represent a member of the organization or the organization itself, depending on the context.

Microsystem: Institutions and groups that most immediately and directly impact the individual's development.

Mesosystem: Consists of interconnections between the microsystems. For example, interactions between different departments within the organization that will impact the individual.

Exosystem: Involves links between social settings that do not involve the individual, yet have an impact on the individual. For example, the experiences of other organizations within the same industry.

Macrosystem: Describes the overarching culture that influences the developing individual, as well as the microsystems and mesosystems embedded in those cultures. Cultural contexts can differ based on geographic location, socioeconomic status, poverty, and ethnicity. Members of a cultural group often share a common identity, heritage, and values. Macrosystems evolve across time and from generation to generation.

Chronosystem (not pictured): Consists of the pattern of environmental events and transitions over the life course of the individual, as well as changing socio-historical circumstances.

Wallet Calls

is_new

Checks whether the wallet has just been created and has not yet had a password set.

Calling set_password will transition the wallet to the locked state.

True if the wallet is new.

is_locked

Checks whether the wallet is locked (is unable to use its private keys).

This state can be changed by calling or

True if the wallet is locked

lock

Locks the wallet immediately.

unlock

Unlocks the wallet.

The wallet remain unlocked until the lock is called or the program exits.

When used in command line, if typed “unlock” without a password followed, the user will be prompted to input a password without echo.

password: the password previously set with

set_password

Sets a new password on the wallet.

The wallet must be either ‘new’ or ‘unlocked’ to execute this command.

When used in command line, if typed “set_password” without a password followed, the user will be prompted to input a password without echo.

password: a new password

dump_private_keys

Dumps all private keys owned by the wallet.

The keys are printed in WIF format. You can import these keys into another wallet using

A map containing the private keys, indexed by their public key

import_key

Imports the private key for an existing account.

The private key must match either an owner key or an active key for the named account.

import_accounts

Imports accounts from a Peerplays 0.x wallet file. Current wallet file must be unlocked to perform the import.

filename: the Peerplays 0.x wallet file to import
password: the password to encrypt the Peerplays 0.x wallet file

A map containing the accounts found and whether imported.

import_account_keys

Imports from a Peerplays 0.x wallet file, find keys that were bound to a given account name on the Peerplays 0.x chain, rebind them to an account name on the 2.0 chain. Current wallet file must be unlocked to perform the import.

filename: the Peerplays 0.x wallet file to import
password: the password to encrypt the Peerplays 0.x wallet file
src_account_name

import_balance

This call will construct transaction(s) that will claim all balances controlled by wif_keys and deposit them into the given account.

account_name_or_id: name or ID of an account that to claim balances to
wif_keys: private WIF keys of balance objects to claim balances from

suggest_brain_key

Suggests a safe brain key to use for creating your account. requires you to specify a ‘brain key’, a long passphrase that provides enough entropy to generate cryptographic keys.

This function will suggest a suitably random string that should be easy to write down (and, with effort, memorize).

A suggested brain_key

get_transaction_id

This method is used to convert a JSON transaction to its transacting ID.

trx: a JSON transaction

The ID (hash) of the transaction.

get_private_key

Get the WIF private key corresponding to a public key. The private key must already be in the wallet.

pubkey: a public key in Base58 format

The WIF private key

load_wallet_file

Loads a specified Graphene wallet.

The current wallet is closed before the new wallet is loaded.

Important: This does not change the filename that will be used for future wallet writes, so this may cause you to overwrite your original wallet unless you also call set_wallet_filename()

wallet_filename: the filename of the wallet JSON file to load. If wallet_filename is empty, it reloads the existing wallet file.

True if the specified wallet is loaded.

normalize_brain_key

Transforms a brain key to reduce the chance of errors when re-entering the key from memory.

This takes a user-supplied brain key and normalizes it into the form used for generating private keys. In particular, this upper-cases all ASCII characters and collapses multiple spaces into one.

s: the brain key as supplied by the user

The brain key in its normalized form.

save_wallet_file

Saves the current wallet to the given filename.

Important: This does not change the wallet filename that will be used for future writes, so think of this function as ‘Save a Copy As…’ instead of ‘Save As…’. Use set_wallet_filename() to make the filename persist.

wallet_filename: the filename of the new wallet JSON file to create or overwrite. If wallet_filename is empty, save to the current filename.

Peerplays Technical Summary

Introducing Peerplays

Peerplays is a decentralized, global crypto platform, built on the most advanced blockchain technology available today. Peerplays brings a new paradigm of fairness, speed, transparency, and security to the global economy.

Peerplays’ decentralization is based on the Delegated Proof of Stake (DPoS) consensus model, meaning that blocks are produced by a group of "Witness" nodes which are elected by stake-weighted token holder voting.

In addition to the Witnesses and the Advisors, a group of blockchain accounts, likewise elected by token holder voting, which vote to specify configurable blockchain parameters, and vote to include or reject proposed new features and other modifications to the consensus protocol.

Peerplays is a smart contracting platform specifically targeted at humanizing crypto economies.

Peerplays is not a Turing complete smart contracting platform, meaning that Peerplays does not support arbitrary, user-defined smart contracts; rather, it provides a well-defined set of officially maintained, built-in contracts. This is in contrast to Turing complete smart contracting platforms like EOS or Ethereum, which provide few to no official contracts, but allow users to define and share contracts without any formally defined quality or correctness verification.

This document is intended to give new Peerplays developers an introduction to the Peerplays architecture and software. Readers are expected to be familiar with C++ software development in general, but not with Peerplays specifically.

This document will walk readers through the code repository structure and how to build the software; describe the individual libraries and executables and their purposes; and examine how the smart contracts work and discuss how to create or modify Peerplays smart contracts.

Graphene

Graphene is the underlying technology behind the Peerplays blockchain. It's an open-source blockchain technology, mainly written in C++. The Graphene source is available in numerous variations, as it has been forked and adapted many times.

There is no other known blockchain like Graphene that can even try to compete in the processing such a high number of transactions this blockchain already can.

Graphene-based coins can do something Bitcoin was never capable of, and will never be. And that is being a real-time value exchange system that will get mass adoption, with great apps built upon it.

A few of the advantages of Graphene are:

Can push over 10,000 transactions per second (TPS), versus Bitcoin, currently at around 7 transactions per second - this could mean Bitcoin payments hanging for 3-4 days!
Best-in-class block production and transaction finality at three seconds compared to Bitcoin at 10 minutes.
Supports payments with zero commission. Users can transfer coins from one account to another absolutely free of charge.

The key Graphene resources can be found here and are a very good starting point for anyone wanting to understand the Peerplays blockchain.

DPOS and GPOS

Peerplays is based on the Delegated Proof of Stake (DPOS) consensus mechanism, where the number of Witnesses are selected, via continuous voting by the PPY token holders, to produce blocks.

Note: The number of block producing (active) Witnesses has to be an odd number.

Only these Witnesses produce the blocks in their respective time slots until the next maintenance interval. After the maintenance interval, the algorithm chooses the next set of Witnesses based on the voting results. Furthermore:

Only token holders can participate in the voting process.
Token holders can vote multiple times, for multiple Witnesses.

Apart from Witnesses, the token holders also elect Advisors who have the privilege of proposing changes to the network parameters. These changes range from something as simple as transaction fees – to the number of elected Witnesses.

Under DPOS the administrative authority rests in the hands of the users, just like a democracy. But unlike Witnesses, the Advisors are not compensated for retaining their positions.

Building on the success of the DPOS consensus mechanism, Peerplays introduced a unique enhancement called Gamified Proof of Stake (GPOS).

The original intent of Peerplays was to operate as a Decentralized Autonomous Cooperative (DAC) where DPOS enabled the voting collective of core token holders to determine who would act as Advisors, Witness, and Proposals within Peerplays. However, the challenges of voter turnout continued to plague Peerplays like other DPOS based blockchains.

GPOS made a protocol change such that PPY token holders now receive a 'participation reward' based on their voting performance and how many PPY they have vested or 'staked'.

This is a significant change from the original DPOS protocol where token holders were rewarded with their share of a 'rake', taken from a percentage of the blockchain fees, and then distributed to token holders relative to their token holdings, regardless of any voting participation.

The importance of voter participation of the PPY token holders is paramount to the security of the blockchain. The introduction of GPOS ensures that token holders will take an active interest in the operation and governance of Peerplays.

Peerplays Repository

The official Peerplays repository can be found at:

This repository uses git submodules, so be sure to fetch the submodules when cloning. This can be done by passing the --recursive flag when cloning:

The most significant subdirectories in the repository are libraries, programs, and tests. The Peerplays implementation is almost entirely defined within various libraries, which are located in the libraries subdirectory.

The programs subdirectory contains small wrappers around these libraries, exposing their functionality as executable binaries.

The tests subdirectory contains various tests to verify that essential blockchain features and functionality are working, and to detect regressions should they occur during development.

We'll now look at each of the three subdirectories in greater detail.

The Peerplays Libraries

Peerplays is implemented in several libraries within the libraries sub directory of the repository. A high level description of each of the libraries is as follows:

app contains the application class, which implements the heart of a Peerplays node
chain contains the bulk of the blockchain implementation, including all Peerplays specific functionality
db contains the database functionality, implementing the in-memory database as well as the persistence layer

Of these libraries, the bulk of development activity occurs within the chain library, and sometimes fc. The other libraries remain reasonably stable, seeing comparatively small updates and modifications.

The Peerplays Programs

Peerplays contains several programs, but only two of these are relevant to modern Peerplays development: witness_node and cli_wallet. In addition, the code within these folders exists just to expose library functionality in an executable, and is rarely updated.

The witness_node program is the only maintained Peerplays node executable. The name witness_node is something of a misnomer, as this executable is really just a full node, but it can provide witness (i.e., block producer) functionality by loading the witness plugin.

Tip: If you wish to sync with the Peerplays blockchain network and maintain a database of the current chain state, this is the program to do it with.

The cli_wallet program implements a command-line wallet for Peerplays. It requires a network connection to a running witness_node to provide chain state information to it. This program provides a basic UI for all Peerplays functionality.

The Peerplays Tests

Peerplays uses the Boost testing framework for its tests. Most of the Peerplays tests use the database_fixture, defined in tests/common/database_fixture.hpp, as the basis of the tests. This file also defines many macros and functions to reduce the boilerplate of test writing.

The bulk of the tests are written in the tests/tests folder, and are run by the chain_test binary. All tests of core functionality should be included in this directory and binary.

Peerplays Smart Contracts

This section provides a high-level overview of the architecture of smart contracts in Peerplays, how they work, and how they are created.

At its essence, a Peerplays smart contract is comprised of three main types of object:

operation
evaluator
object

The Peerplays protocol defines a set of actions a user can take within the blockchain ecosystem, called operation s. All interactions with the blockchain take place through operation s, and in a sense, they are the blockchain’s API.

Each operation has an evaluator, which implements that operation’s functionality within the Peerplays software implementation. Thus an operation is like a function prototype, whereas an evaluator is the function definition.

Finally, all data persistently stored by the blockchain is contained within database object s. Each object defines a group of fields, analogous to columns of a relational database table.

Operations

All operation s charge a fee to execute, and each must specify an account to pay the fee. This account’s ID must be returned by the fee_payer() method on the operation. Each operation must also provide a stateless consistency check which examines the operation’s fields and throws an exception if anything is invalid.

Finally, operation s must provide a calculate_fee() method which examines the operation and calculates the fee to execute it. This method may not reference blockchain state, however, each operation defines a fee_parameters_type struct containing settings for the fee calculation defined at runtime, and an instance of this struct is passed to the calculate_fee() method.

All operation s automatically require the authorization of their fee paying account, but an operation may additionally specify other accounts which must authorize their execution by defining the get_required_active_authorities() and/or get_required_owner_authorities() methods.

Note: If a transaction contains an operation which requires a given account’s authorization, signatures sufficient to satisfy that account’s authority must be provided on the transaction.

Evaluators

Each operation has an evaluator which implements that operation’s modifications to the blockchain database. Each evaluator most provide two methods: do_evaluate() and do_apply().

The evaluate step examines the operation with read-only access to the database, and verifies that the operation can be applied successfully. The apply step then modifies the database.

Each evaluator must also define a type alias, evaluator::operation_type, which aliases the specific operation implemented by that evaluator.

Objects

The Peerplays software implementation utilizes a custom, in-memory relational-style database to track the blockchain state as new blocks and transactions are applied, containing operation s which modify the database.

This database is implemented in the libraries/db folder, and it provides persistence to disk as well as undo functionality allowing the rewinding of changes, such as when a partially-applied transaction fails to execute, or blocks are popped due to a chain reorganization (i.e. when switching forks).

The Peerplays database tracks various object types, each of which defines the columns of a table. The rows of this table represent the individual object instances in the database. Along with each object type is an index type, which, in relational database terms, defines the primary and secondary keys, which can be used to look up object instances.

The primary key is always an object_id type, a unique numerical ID for each object instance known to the blockchain. All objects inherit an id field from their base class which contains this ID. This field is set by the database automatically and does not need to be modified manually.

Summary

Peerplays smart contracts are defined as a set of operation s which are analogous to API calls provided by the contract.

These operation s are implemented by evaluator s, which provide code to verify that the operation can execute successfully, and then to perform the requisite modifications to database object s.

All object s specify an index, which defines keys which can be used to look up an object instance within the database.

Peerplays API(s)

Since Peerplays is a Graphene based blockchain it supports the Graphene API at its core.

For more information on the Graphene API go to:

To make access to the API easier for developers there are two Python libraries that can be used.

python-peerplays (pypeerplays)

This is a communications library which allows interface with the Peerplays blockchain directly and without the need for a cli_wallet. It provides a wallet interface and can construct any kind of transactions and properly sign them for broadcast.

The repository can be found here:

The purpose of pypeerplays is to simplify development of products and services that use the Peerplays blockchain. It comes with:

It’s own (bip32-encrypted) wallet
RPC interface for the Blockchain backend
JSON-based blockchain objects (accounts, blocks, events, etc)
A simple to use yet powerful API

peerplaysjs-lib

This is Javascript API for interacting with the Peerplays Blockchain. This is more commonly used for connecting dApps to the blockchain.

The repository can be found here:

Interfacing With Graphene

The APIs are separated into two categories:

the Blockchain API which is used to query blockchain data (account, assets, trading history, etc.)
the CLI Wallet API which has your private keys loaded and is required when interacting with the blockchain with new transactions.

The set of available calls depends on whether you connect to a full node (witness_node) or the wallet (cli_wallet). Both support RPC-JSON. The full node also supports the websocket protocol with notifications.

Which blockchain network you connect to depends on the configuration of the full node and the wallet.

Tip: If you run a full node, we recommend you connect your wallet to your local full node even though it could be connected to any other public full node as well.

Blockchain API

The blockchain API (as provided by the witness_node application) can be used to obtain any kind of data stored in the blockchain. Besides data stores in the blockchain itself (blocks, transactions, etc. ..), higher level objects (such as accounts, balances, etc. …) can be retrieved through the full node’s database.

It is not required to run a local full node if you want to query a particular blockchain or database, but you can also query any existing public node for information.

Important: The blockchain API doesn't know about private keys, and cannot sign transactions for you. All it does is validate and broadcast transactions to the P2P network.

CLI Wallet API

The cli-wallet api, as provided by the cli_wallet binary, allows you to create and sign transactions and broadcast them.

Asset Calls

list_assets

Lists all assets registered on the blockchain.

To list all assets, pass the empty string "" for the lowerbound to start at the beginning of the list, and iterate as necessary.

lowerbound: the symbol of the first asset to include in the list.
limit: the maximum number of assets to return (max: 100)

The list of asset objects, ordered by symbol.

create_asset

Creates a new user-issued or market-issued asset.

Many options can be changed later using

Note: Right now this function is difficult to use because you must provide raw JSON data structures for the options objects, and those include prices and asset ids.

issuer: the name or id of the account who will pay the fee and become the issuer of the new asset. This can be updated later
symbol: the ticker symbol of the new asset
precision

update_asset

Update the core options on an asset. There are a number of options which all assets in the network use. These options are enumerated in the asset_object::asset_options struct.

This command is used to update these options for an existing asset.

symbol: the name or id of the asset to update
new_issuer: if changing the asset’s issuer, the name or id of the new issuer. null if you wish to remain the issuer of the asset

update_bitasset

Update the options specific to a BitAsset.

BitAssets have some options which are not relevant to other asset types. This operation is used to update those options an an existing BitAsset.

See

symbol: the name or id of the asset to update, which must be a market-issued asset
new_options: the new bitasset_options object, which will entirely replace the existing options.

update_asset_feed_producers

Update the set of feed-producing accounts for a BitAsset.

BitAssets have price feeds selected by taking the median values of recommendations from a set of feed producers. This command is used to specify which accounts may produce feeds for a given BitAsset.

symbol: the name or id of the asset to update
new_feed_producers: a list of account names or ids which are authorized to produce feeds for the asset. this list will completely replace the existing list

publish_asset_feed

Publishes a price feed for the named asset.

Price feed providers use this command to publish their price feeds for market-issued assets. A price feed is used to tune the market for a particular market-issued asset. For each value in the feed, the median across all committee_member feeds for that asset is calculated and the market for the asset is configured with the median of that value.

The feed object in this command contains three prices:

A call price limit
A short price limit,
A settlement price

The call limit price is structured as (collateral asset) / (debt asset) and the short limit price is structured as (asset for sale) / (collateral asset).

Note: The asset IDs are opposite to each other, so if we’re publishing a feed for USD, the call limit price will be CORE/USD and the short limit price will be USD/CORE.

The settlement price may be flipped either direction, as long as it is a ratio between the market-issued asset and its collateral.

publishing_account: the account publishing the price feed
symbol: the name or id of the asset whose feed we’re publishing
feed

issue_asset

Issue new shares of an asset.

to_account: the name or id of the account to receive the new shares
amount: the amount to issue, in nominal units
symbol

get_asset

Returns information about the given asset.

asset_name_or_id: the symbol or id of the asset in question

The information about the asset stored in the block chain.

get_bitasset_data

Returns the BitAsset-specific data for a given asset. Market-issued assets’s behaviour are determined both by their “BitAsset Data” and their basic asset data, as returned by

asset_name_or_id: the symbol or id of the BitAsset in question

The BitAsset-specific data for this asset

fund_asset_fee_pool

Pay into the fee pool for the given asset.

User-issued assets can optionally have a pool of the core asset which is automatically used to pay transaction fees for any transaction using that asset (using the asset’s core exchange rate).

This command allows anyone to deposit the core asset into this fee pool.

from: the name or id of the account sending the core asset
symbol: the name or id of the asset whose fee pool you wish to fund
amount

reserve_asset

Burns an amount of given asset.

This command burns an amount of given asset to reduce the amount in circulation.

Note: You can't burn market-issued assets.

from: the account containing the asset you wish to burn
amount: the amount to burn, in nominal units
symbol

global_settle_asset

Forces a global settling of the given asset (black swan or prediction markets).

In order to use this operation, asset_to_settle must have the global_settle flag set

When this operation is executed all open margin positions are called at the settle price. A pool will be formed containing the collateral got from the margin positions. Users owning an amount of the asset may use to claim collateral instantly at the settle price from the pool.

If this asset is used as backing for other BitAssets, those BitAssets will not be affected.

Note: This operation is used only by the asset issuer.

symbol: the name or id of the asset to globally settle
settle_price: the price at which to settle
broadcast

Account Calls

list_my_accounts

Lists all accounts controlled by this wallet. This returns a list of the full account objects for all accounts whose private keys we possess

A list of account objects

list_accounts

Lists all accounts registered in the blockchain. This returns a list of all account names and their account ids, sorted by account name.

Use the lowerbound and limit parameters to page through the list. To retrieve all accounts, start by setting lowerbound to the empty string "", and then each iteration, pass the last account name returned as the lowerbound for the next list_accounts() call.

lowerbound: the name of the first account to return. If the named account does not exist, the list will start at the account that comes after lowerbound
limit: the maximum number of accounts to return (max: 1000)

A list of accounts mapping account names to account ids.

list_account_balances

List the balances of an account. Each account can have multiple balances, one for each type of asset owned by that account. The returned list will only contain assets for which the account has a non-zero balance.

id: the name or id of the account whose balances you want

A list of the given account’s balances

register_account

Registers a third party’s account on the blockchain.

This function is used to register an account for which you do not own the private keys. When acting as a registrar, an end user will generate their own private keys and send you the public keys. The registrar will use this function to register the account on behalf of the end user.

See also

name: the name of the account, must be unique on the blockchain. Shorter names are more expensive to register; the rules are still in flux, but in general names of more than 8 characters with at least one digit will be cheap.
owner: the owner key for the new account

upgrade_account

Upgrades an account to prime status. This makes the account holder a ‘lifetime member’.

name: the name or id of the account to upgrade
broadcast: true to broadcast the transaction on the network

The signed transaction upgrading the account

create_account_with_brain_key

Creates a new account and registers it on the blockchain.

See also ,

brain_key: the brain key used for generating the account’s private keys
account_name: the name of the account, must be unique on the blockchain. Shorter names are more expensive to register; the rules are still in flux, but in general names of more than 8 characters with at least one digit will be cheap.

transfer

Transfer an amount from one account to another.

from: the name or id of the account sending the funds
to: the name or id of the account receiving the funds
amount

transfer2

This method works just like transfer, except it always broadcasts and returns the transaction ID (hash) along with the signed transaction.

from: the name or id of the account sending the funds
to: the name or id of the account receiving the funds
amount

whitelist_account

Whitelist and blacklist accounts, primarily for transacting in whitelisted assets.

Accounts can freely specify opinions about other accounts, in the form of either whitelisting or blacklisting them. This information is used in chain validation only to determine whether an account is authorized to transact in an asset type which enforces a whitelist, but third parties can use this information for other uses as well, as long as it does not conflict with the use of whitelisted assets.

An asset which enforces a whitelist specifies a list of accounts to maintain its whitelist, and a list of accounts to maintain its blacklist. In order for a given account A to hold and transact in a whitelisted asset S, A must be whitelisted by at least one of S’s whitelist_authorities and blacklisted by none of S’s blacklist_authorities. If A receives a balance of S, and is later removed from the whitelist(s) which allowed it to hold S, or added to any blacklist S specifies as authoritative, A’s balance of S will be frozen until A’s authorization is reinstated.

authorizing_account: the account who is doing the whitelisting
account_to_list: the account being whitelisted
new_listing_status

get_vesting_balances

Get information about a vesting balance object or vesting balance objects owned by an account.

account_name: An account name, account ID, or vesting balance object ID.

A list of vesting balance objects with additional info

withdraw_vesting

Withdraw a vesting balance.

witness_name: The account name of the witness, also accepts account ID or vesting balance ID type.
amount: The amount to withdraw.
asset_symbol

get_account

Returns information about the given account.

account_name_or_id: the name or ID of the account to provide information about

The public account data stored in the blockchain

get_account_id

Lookup the id of a named account.

account_name_or_id: the name or ID of the account to look up

The id of the named account

get_account_history

Returns the most recent operations on the named account.

This returns a list of operation history objects, which describe activity on the account.

name: the name or id of the account
limit: the number of entries to return (starting from the most recent)

A list of operation_history_objects

approve_proposal

Approve or disapprove a proposal.

fee_paying_account: The account paying the fee for the op.
proposal_id: The proposal to modify.
delta

NFT, Marketplace, HRP, and RBAC related Commands/Use Cases

Here we learn some commands and use cases related to NFT, Marketplace, HRP, and RBAC.

1. NFT Metadata Creation

Example NFT metadata create command without permissions,

account01 is the owner account of the metadata
“AVALON NAME” is the name of the NFT types created from the NFT metadata being created
“AVALON SYMBOL” is the symbol of the NFT types created from the NFT metadata being created. The symbol is reserved for future use.
“AVALON BASE URI” is the URI of the NFT types. Eg: avalonmeta.com
account02 is the revenue partner, this can be owner as well. Whenever the minted NFT is sold in the marketplace a split of the selling price goes to the revenue partner. The split can be specified in revenue_split parameter.
100 is the revenue_split on the scale of 10000 being 100 percent. i.e. 100 is 1%
is_transferable specifies if the minted NFTs can be transferred by the owner of the NFT to other accounts
is_sellable specifies if the minted NFTs can be sold in the marketplace.
role_id is the resource permissions specifying the whitelisting accounts among which the NFTs can either be transferred or sold on marketplace.
broadcast either true or false, keeping it true will include the transaction in the upcoming block on the chain.

Example NFT metadata create command with permissions

First create a permission:

Example Permission:

account01 is the owner of the permission being created which can be attached to NFT metadata.
“Avalon Permissions1” is the name of the resource permission being created.
“Permission Metadata” is the metadata, can be a JSON as well.

Example NFT metadata create command with permissions:

1.32.0 This is specified in the metadata create operation to attach permissions to all the NFTs created from this metadata.

NFT creation

NFT is always minted by the owner of the metadata object this NFT is based on. The fees associated with minting this NFT is just the transaction fee + storage fee which are both collected in core PPY token. After the NFT has been minted this can be sold on marketplace in any token of NFT owner’s choice.

Syntax:

Example NFT creation based on the metadata created above:

account01 is the owner of the metadata this NFT is based on
1.30.0 is the metadata ID of the metadata object this NFT is based on ( Currently this works on best guess method by doing get_object 1.30.0, 1.30.1, 1.30.2 …. so on, in future a new cli command will be introduced that can list all the metadata objects by owner account ).
account02 is the owner of the NFT, can be one of the user of the Avalon App.

NFT Safe Transfer from owner to other account

Example command:

Note that NFTs can be transferred only when is_transferableflag is set to true, also if permissions are enabled both from and to accounts have to be whitelisted.

account02 operator or owner account
account02 from account
account03 to account
1.31.0 Id of the NFT

Create Market Listing Offer

Example command:

Note that is_sellable of NFT metadata should be true to make listing of the NFTs created from the metadata.

Only owner of the NFT can create a listing in auction.

["1.31.0","1.31.1"] - List of NFTs to sell or buy
account02 is the owner of the NFTs
{"amount":100,"asset_id":"1.3.0"} minimum bid price expected

Create Bid Offer

Example bid command:

account04 is the bidder
{"amount":10000,"asset_id":"1.3.0"} bid price
1.29.0 Offer listing objected created from create_offer command

Cancel Offer

Example cancel offer command:

account02 is the creator of the listing
1.29.0 is the offer object
true broadcast value mentioned above