Issue decentralized securities using Peershare

The shutdown of BTC Trading Corp and Litecoin Global has caused me to consider if there is a way for businesses to manage publicly held shares in a decentralized fashion. I realized it is possible to leverage Peercoin and proof of stake to accomplish this in an elegant and resilient way using a design I will call Peershare. I’d like to present my preliminary design and have my plan criticized and improved by the community. I am seriously considering doing most or all of the development of Peershare myself. Though I am very busy with prior development commitments, I think Peershare can be a critical enabler that brings depth and sophistication to the crypto economy so that it may be worthy of being prioritized above what I am currently focusing on. I’m hoping a community discussion will clarify whether that is true.

First I will talk about what the solution looks like technically. Next I will explain the advantages it offers over centralized security exchanges such as BTC Trading. I will wrap up by walking through what a couple Peershare use cases might look like.

Technical Specifications of Peershare

The solution will consist of two main components: (1) A new type of blockchain which uses only proof of stake. Multiple instances of it will be used as each one contains a single company’s shares. (2) A substantially altered version of the Peercoin client which will facilitate the transfer of Peershares and the automated distribution of associated dividends in the form of Peercoins.

Peershare does not require any changes to the Peercoin blockchain or protocol (no hard fork).

Peershare blockchains:
To construct the template for company specific instances of a Peershare blockchain a Peercoin fork will be the starting point and then the following changes will be made:

1. Completely eliminate proof of work.
2. Require that each Peershare address in the blockchain contain a Peercoin public address as a property.
3. Make the chain produce 100,000 shares in the genesis block (for an IPO).
4. Because it is anticipated that many of these blockchains will exist on a single client, they need to be small. Transaction volume is expected to be much lower than that for Peercoin, so it would be appropriate to have less frequent and smaller blocks. A block generation target of 60 minutes [Update: may be appropriate with the time interval between blocks halving every two or three years. This would improve confirmation times over the long run while still reducing the cost of storing blockchains over time considering SSD storage pricing are halving every 12 to 18 months.]
5. Each company starting a Peershare blockchain could choose their own parameters and alterations if they felt the defaults were not optimal for their needs.

Combined Peershare and Peercoin client:

1. The user interface will have a drop down list to allow users to select Peercoin or a particular type of Peershare (for example, it might list Peercoin, Crypto-Trade, Basic Mining, Ltc Miner, etc).
2. The Overview, Send coins, Receive coins, Transactions and Address Book which currently exist in the client will relate to the user drop down selection, which will be Peercoin or a specific type of Peershare. When a new Peershare address is created, the client also creates a Peercoin address. The public key is added as a property of the Peershare address while the Peercoin address and private key is added to the client’s wallet in the usual way.
3. Create a popup form accessible from the menu to distribute dividends. A user simply enters the total amount of Peercoins they want distributed as dividends and then selects the Peershare chain they want those delivered to from a drop down list. Behind the user interface a list of all Peercoin addresses contained in the selected Peershare blockchain is constructed along with the amount of dividend each should receive based on the proportion of shares held at each Peershare address. Peercoins are then distributed from the wallet as dividends through the Peercoin blockchain.

Advantages of Peershare over a centralized solution such as BTC Trading Corp

1. Automated dividend distributions require no third parties: Dividends are sent directly to shareholder wallets from the issuer’s wallet using only the Peercoin blockchain. The issuer need only enter the total amount of dividend to be sent. The rest is automated. After placing Peershares in a wallet in the same simple way a user places Peercoins in their wallet, dividends simply appear as Peercoins in the user’s wallet when issued by a company.
2. Somewhat decentralized exchange of Peershares: Exchange of Peershares are decentralized in the same way exchange of Peercoins are. For example, if Vircurex shut down and ceased trading Peercoins, they would continue to be available at BTC-e, Crypto-Trade, Bter, etc., without any disruption. The present scramble we are seeing by issuers using BTC Trading to re-list their securities on another securities exchange would never occur because the issuer provides the key functions of IPO and dividend distribution themselves so shares can be traded on many exchanges or even person to person.
3. Lack of exposure to regulatory interference: GLBSE and BTC Trading appear to have been shut down by pressure from regulators. Peershare eliminates the need for securities exchanges to assume the responsibilities of executing IPOs, distributing dividends, and screening companies before listing. Regulations for companies issuing their own shares are much more limited than regulations for securities exchanges.
4. Privacy: Peershare not does not require any identifying information from shareholders or even issuers. Issuers would not be in a position to require their shareholders to identify themselves if pressed to do so.

Hypothetical use case: Example of IPO

CryptoSafe is a brand-new start up that intends to develop a hardware wallet for crypto-currencies. They decide to use Peershare to raise funds through an IPO and later distribute dividends to shareholders.

CryptoSafe acquires the open source Peershare code and create a new genesis block. The genesis block contains 100,000 shares of CryptoSafe. They secure the network by minting Proof of Stake blocks which will add approximately 1% to the total number of shares each year. They secure an agreement with Crypto-Trade and Cryptsy to facilitate exchange of CryptoSafe shares. They keep 60,000 shares as an owner’s stake and continue to secure the network with it. They transfer 20,000 shares to their Cryptsy account and 20,000 shares to their Crypto-Trade account. An IPO is put into motion by placing sell orders for these 40,000 shares at the IPO price, which is 20 Peercoins per share. Individuals may become shareholders by buying CryptoSafe shares at one of these exchanges and then withdrawing the shares from the exchange using their Peershare wallet. When all 40,000 shares are purchased, CryptoSafe will have 800,000 PPC to fund development of their hardware wallet.

Six months later CryptoSafe delivers their first product and receives their first revenue, which is the equivalent of 20,000 PPC. Fulfilling their promise to shareholders, the CFO opens the Dividend Distribution form from the Peershare client menu, then enters 20,000 PPC as the amount to distribute and selects CryptoSafe as the Peershare to distribute to. After confirmation, the client initiates Peercoin transactions to deliver a little less than 0.20 PPC for each of the approximately 100,500 CryptoSafe shares by examining the CryptoSafe blockchain. If a CryptoSafe address held 100 shares, then approximately 20 PPC would be sent to the Peercoin public address embedded as a property of that CryptoSafe address. The exact amount sent per share would be: (20,000 PPC - transaction fees) / total number of CryptoSafe shares.

Hypothetical use case – Example of delisting from a centralized security exchange

Best Miner is currently listed on a centralized security exchange such as BTC Trading and would like to delist and take advantage of Peershare instead.

First, Best Miner raises a motion to make the switch. It is approved. Next, they change a single number in the Peershare blockchain source code to make the genesis block produce the number of shares they have actually issued instead of the default number of shares. They start the blockchain and secure it using a server on hand. They arrange to have Best Miner Peershares traded at a couple of exchanges. Shareholders download the Peershare client configured to use Best Miner (which only requires a .conf setting) and each shareholder sends Best Miner their public Peershare address. Trading at the centralized exchange is halted. Shares are transferred to the Peershare addresses supplied. Trading continues at exchanges such as Crypto-Trade and Cryptsy.

Discussion

One of the issues to be managed is the cost of transaction fees incurred for dividend distributions. It is possible that fees could exceed dividends or take an unacceptably large proportion of them. Companies issuing Peershare will likely choose longer intervals for dividend distribution. Shareholders will learn aggregate all their shares into a single address to minimize transaction fees, which will be subtracted from the dividend sent by the software. Other methods for minimizing transaction cost for dividend distribution could evolve in the market outside the scope of the system. For instance, it is conceivable that an exchange could pass dividends along to their account holders off blockchain while inexpensively receiving the dividend themselves via the blockchain by keeping the shares of exchange account holders lumped together on a single address. There is also a good chance that the Peercoin transaction fee of 0.01 per KB could be reduced in the future.

Finally, I would like to invite comment and critical evaluation of this plan. In particular I welcome input from Sunny King, super3, hsk81.

If you are interested in using Peershare as an issuer please say so in this thread, or contact me by PM or Bitmessage me at BM-2D9MHYUoyS9DcRDrYHn4ESDxwNz4MkWb6F. When it is ready to implement I will be happy to offer assistance to Peershare issuers to make sure everything goes smoothly.

interesting concept, still need to read it a couple of times,

if it works, this could be the main use for ppcoin, and exceed the transaction volume of ppcoin (for a while), don’t know if that really matters

Peershare could become the main use for Peercoin, at least short to medium term. It’s hard to know whether the Peershare blockchains would exceed the transaction volume of Peercoin. It depends on whether people trade Peershares or receive dividends on Peershares more often. Peershare trades occur on a Peershare blockchain, but all dividend disbursements create transactions on the Peercoin blockchain.

This is genius. Not only it solves current stock trade problems, but also creates big possibilities for PPCoin… Please, just please don’t stop working on that.

Love this idea!

Sounds very interesting

Interesting idea. After reading it a couple of times, can you tell me in simple words why does PeerShare need PeerCoin? It seems any cryptocoin will serve the need (distrubuting dividend).
In your first example if the company has to mine on its specific blockchain in order to secure the network, will the newly generated blocks dilute existing share holders’ stakes?
If there are a lot of trading of PeerShare (within an exchange or among individuals) wouldn’t the block rate have to be high enough to accomodate the need to clear trading transactions?

While it is certainly possible to implement Peershare using Litecoin or Bitcoin as the chain to distribute dividends, it is much cheaper to use Peercoin. One of the key limitations of Peershare will be transaction costs to distribute dividends. Right now the suggested Bitcoin transaction fee is $0.06 (0.0005 BTC), the Litecoin fee is $0.02 (0.01 LTC) and the Peercoin fee is $0.002 (0.01 PPC). While Bitcoin and Litecoin fees are not presently enforced by miners, I believe they will be as the 1MB block size limit is approached.

Long term, the transaction costs of all three of these networks is likely to change significantly to reflect the cost of maintaining the network. The cost to maintain Peercoin is much smaller than for proof of work coins – I would say as proof of work is phased out it will become something on the order of 1% of the cost to secure the Bitcoin or Litecoin network. Therefore, we can safely predict that Peercoin transaction fees will be by far the lowest long term.

Basically if all sharesholders were mining, then the proportion of shares owned by each would not change, though the total number of shares would increase by 1% a year. Minting proof of stake blocks does not transfer wealth the way proof of work blocks do. In practice, some shareholders will not mine and they will basically be paying a 1% per year fee to those who do for the service of securing the network.

It should be noted that each Peershare issuer can choose whatever size block reward they think is appropriate. It could be 0%. In this scenario, the shareholders (most likely just the issuing company) would mine for free just to maintain the value of their shares. Companies tolerate lots of expenses to indirectly maintain their share value, so this would likely work. However, it would not be nearly as robust as giving all shareholders a direct incentive to secure the network.

Yes, block generation needs to be frequent enough to clear all transactions. There is a trade off between blockchain size and speedy confirmations. If a person holds Peershares from a dozen different companies, they will need to maintain twelve blockchains to hold their shares without counter party risk, so blockchain size needs to be kept to a minimum. To make sure transactions clear, the block size limit could be kept higher. A block size limit of 1MB and an extreme block rate of 24 hours would still permit approximately 4,000 transactions per day. It is unlikely any Peershare will have more transactions than that anytime soon. Also, where Peershare ownership will tend to be more concentrated than Peercoin ownership (many companies will maintain a majority stake), hard forks to produce blocks more frequently to accommodate more transactions are practical.

Can we say PeerShares are PPC forks issued by a company to ditribute shares that can be traded in decentralized ways, and can deliver dividend?

If you observing what happened to mcxFEE at mcxnow you may think otherwise. Many people buy shares to speculate. The exchanges can clear transaction internally. But to withdraw or to trade between individual share owners confirmaiton time matters.

This could give us the edge we need in the alt market.

While struggling with the tension between having small blockchains and fast confirmations, it occurred to me that the problem with blockchains taking too much disk space is a transient problem because blockchain growth is essentially linear (for a given volume of transactions) while available disk space growth is exponential. With the cost of SSD storage halving every 12 to 18 months, the time interval between blocks could be halved every three years. This would allow for the cost of storing blockchains to continue to decline while also providing faster confirmations over time.

I have updated the original post to reflect this change.

I welcome comment on this change.

Well once thin client becomes standard in cryptocoin wallets, the size of the blockchain will become irrelevant to most users any way because they don’t have a local copy of the blockchain. Wait. Maybe for POS coins it is different?

is it not possible to transfer the dividends internally? so it would not cost tx fee?
and i was wondering, is it possible to automate the pay-out of dividends to the new owner, when shares have been transmitted from A to B? something like transferring complete addresses? maybe it can be done, if you use the IPO blockchain addresses for the dividends, and the ppcoin blockchain for ownership… , i dont know if this is really good solution, but it would be great if it could be automated somehow

Very good work Jordan!

From technical design point of view, I can try to provide some comments to simplify it:

1. Peershare could talk to PPC wallet for managing PPC balances and transactions without directly managing them. It would greatly simplify Peershare client as it then does not need to directly connect to PPC network and access PPC block chain. This means a PPC wallet should be running in server (Qt) or daemon mode. When Peershare wants to create a PPC address it could do so via the dumpprivkey and importprivkey facility to sync between the two clients.

2. To run a PPC fork without proof-of-work probably needs some work, the first step is to create genesis block in such a way to work around the 30-day limit. This involves using a timestamp say 90 days older in the genesis block and create at least many thousands of outputs in the genesis block in order to facilitate the initial proof-of-stake generation.

[quote=“Sunny King, post:14, topic:382”]From technical design point of view, I can try to provide some comments to simplify it:

1. Peershare could talk to PPC wallet for managing PPC balances and transactions without directly managing them. It would greatly simplify Peershare client as it then does not need to directly connect to PPC network and access PPC block chain. This means a PPC wallet should be running in server (Qt) or daemon mode. When Peershare wants to create a PPC address it could do so via the dumpprivkey and importprivkey facility to sync between the two clients.[/quote]

I’m glad to see Sunny valuing simplification. I have seen a lot of development projects fail because too many features were attempted at once. I’m definitely in favor of delivering an absolute minimum set of functionality at first, and leaving the option to add more features in subsequent releases.

In line with the value of simplification, I think Sunny’s suggestion of leaving the Peercoin client untouched and separating the Peershare client is a great one. Even though the design is slightly less user friendly, it should speed development considerably. As I was considering this change, I realized it would be practical to simplify the client design even further by making the Peershare client specific to a single Peershare blockchain initially. Once again, this is not as user friendly as a client that can manage multiple Peershare blockchains, but it will save quite a bit of development time and bring the initial release of Peershare forward in time. Support for multiple Peershare blockchains in a single client will be a high priority for a second release. A combined Peercoin and Peershare client could later be be built into a third or subsequent release.

This is pure gold from someone with much more familiarity with the architecture of the Peercoin blockchain than I currently have. This sort of suggestion will save me quite a bit of time. As I move forward I will post more details about my plan and approach to development. I hope Sunny and others with relevant expertise will jump in with suggestions like this about the best way to proceed to implement specific features.

I’m not sure that this is an improvement over coloured coins, which is currently in development. Have you looked at coloured coins and compared your ‘Peershare’ to it to asses pros + cons? It would be a waste of time to develop an inferior version of something that is already being developed.

I am a fan of coloured coins, Peercoin could be the first to adopt the coloured coins system once they are developed which would give it an huge advantage.

I have looked at coloured coins and considered how Peershare compares to them. Very briefly, Peershare is simpler than coloured coin (meaning it has a better chance of being successfully implemented), offers more features specifically useful to companies issuing shares and can be expected to have lower transaction fees. Importantly, the blockchain and protocol is solely controlled by shareholders of a single company allowing the protocol to be responsive to their specific needs, whereas coloured coin holders will be subject to the interests of Bitcoin miners.

Here’s a more detailed comparison:

1. Peershare provides a way to easily and automatically distribute dividends directly to shareholders. So far as I have seen, no coloured coin design proposes implementation of similar functionality (though coloured coin architecture would permit such an implementation). Because Peershare focuses its scope to company issued shares, it is able to meet the needs of this use case much better.
2. Coloured coins are not as divisible as Peershares given that Bitcoin imposes a minimum size of 5430 satoshis.
3. Transaction fees on coloured coins are much higher than what is likely for Peershares – dividends distributions are currently about 5% of the cost (on the Peercoin network) while actual Peershare transaction cost would vary but would likely be even less than the low Peercoin transaction fee.
4. Bitcoin miners have different interests that may be at odds with interests of holders of specific types of coloured coin holders. For example, a 5430 satoshi minimum Bitcoin transaction size was imposed this spring. It is possible that additional changes would be implemented in the future that could adversely effect coloured coins. Peershare is architected so that the shareholders hold the fate of the network – it exists for them exclusively. They can alter transaction fees, control minimum transaction size and even issue new shares according to their collective interests using hard forks. Part of the reason for coloured coins using the Bitcoin blockchain was the assertion that a separate blockchain for each type of asset could not be secured. This is true for proof of work chains, but not proof of stake chains. The coloured coin design has not been updated to take advantage of the recent emergence of proof of stake.
5. Blockchain bloat will be minimized as a different blockchain is used to track Peershare ownership.
6. Peershare is simpler with a more narrow scope than coloured coins. Coloured coins have been talked about for quite some time but no usable implementation has emerged yet. Hopefully Peershare with a more focused and simple design will be brought into reality more rapidly.

I wanted to thank everyone who has participated in refining and questioning the design of Peershare so far, particularly Sunny. Based on the feedback received, I have concluded that Peershare is worth spending my time developing and I will begin doing so in earnest in two weeks, after attending to some prior commitments.

In preparation for diving into development I have broken the project up into eight different phases, each of which will produce a finished product that can be tested and meets the specifications defined below. Deliverables for the first two phases will not contain a feature set that will allow Peershare to be used by a company to issue shares receiving dividends. This real world use will become practical with the release of the third phase. Phases four through eight will provide valuable enhancements to a working set of core functionality.

Phase One:
• Create a fork of Peercoin 0.3 on GitHub
• Alter it to completely remove proof of work.
• The new blockchain should create 100,000 shares more or less immediately, although this may not be in the genesis block as I have read that genesis block outputs cannot be spent.
• After the creation of the initial 100,000 shares, additional shares will be created as proof of stake block rewards such that the supply of shares will increase by 1% annually.
• The initial target interval for blocks will be 60 minutes to keep the blockchain small.

Phase Two:
• Require that each Peershare address in the blockchain contain a Peercoin public address as a property.
• Peercoin must be running in daemon mode in order to create a new Peershare address.
• When Peershare creates a new address, a new Peercoin address is also created and the address is added to the Peercoin wallet using the importprivkey.

Phase Three:
• Create a popup form accessible from the menu to distribute dividends. A user simply enters the total amount of Peercoins they want distributed as dividends, their Peercoin wallet password and then confirms the action.
• Behind the user interface a list of all Peercoin addresses contained in the Peershare blockchain is constructed along with the amount of dividend each should receive based on the proportion of shares held at each Peershare address. The Peercoin transaction fee is deducted from the amount to be sent to each Peercoin address. Peercoins are then distributed from the wallet as dividends through the Peercoin blockchain.
• Peercoin must be running in daemon mode in order to distribute dividends.

Phase Four:
• Merge Peercoin 0.4 changes into Peershare. This can be done any time after the Peercoin 0.4 release is stabilized. It may occur before the third phase is complete.

Phase Five:
• Permit a single Peershare client to support multiple types of Peershares.
• The user interface will have a drop down list to allow users to select a particular type of Peershare (for example, it might list Crypto-Trade, Peta-Mine, Asic Miner, etc).
• The Overview, Send coins, Receive coins, Transactions and Address Book which currently exist in the client will relate to the user drop down selection, which will be a specific type of Peershare.
• The client will manage a separate wallet.dat file, separate .conf, etc. for each type of Peershare.
• Master configuration settings would specify which types of Peershare will be included

Phase Six:
• Integrate the Peershare and Peercoin clients.
• Peercoin can be handled within the Peershare client much as any specific type of Peershare would be – having its own blockchain, .conf, wallet.dat file, etc.

Phase Seven:
• The block target interval should be halved approximately every two and a half years. The change should occur gradually and not be stepped.
• As blocks are created more frequently, the share supply must continue to rise at a rate of 1% annually, meaning the reward for each block will fall. The cost of computing resources is expected to halve in a smaller time interval, such that the cost of maintaining the blockchain will go down over time while also delivering better performance in the form of more frequent blocks. Another effect will be to allow a larger volume of transactions. While additional transactions may not be needed in most Peershare implementations, additional transaction capacity will be needed in Peercoin (as well as Bitcoin and Litecoin). There has been discussion of increasing block size to accomplish this, but I believe that producing more frequent blocks is a better way to increase transaction capacity. In this way Peershare will implement a blockchain that allows for increased transaction volume over time, which could be adopted by Peercoin, Bitcoin and Litecoin to increase their transaction capacity at a later date.

Phase Eight:
• Allow for motions to be advanced for a special (relatively high) transaction fee. Motions are technically simply a block of text stored in the blockchain.
• Motions can be voted up or down by each shareholder and each vote will be stored in the blockchain as a special type of transaction.
• A user interface must be added to the Peershare client to display motions and allow the shareholder to vote yes or no.

Phases one and two could be developed in parallel by two different developers. If you are interested in developing one of the first two phases yourself in the next month, let me know. I would love to have your help. Similarly, phase four can be completed separately at any time after the Peercoin 0.4 release is stabilised. If you are interested in merging Peercoin 0.4 changes into Peershare, please let me know, even though that phase cannot be started yet.

Finally, I’d like to invite comment on the development plan and clarify that the plan is flexible and will almost certainly undergo significant alteration as additional information comes to light.

How does it work with existing security? Say friedcat decides to use this service to have all AM shares be traded.

Here is a relevant hypothetical use case buried deep in the original post:

[quote=“Jordan Lee, post:1, topic:382”]Hypothetical use case – Example of delisting from a centralized security exchange

Best Miner is currently listed on a centralized security exchange such as BTC Trading and would like to delist and take advantage of Peershare instead.

First, Best Miner raises a motion to make the switch. It is approved. Next, they change a single number in the Peershare blockchain source code to make the genesis block produce the number of shares they have actually issued instead of the default number of shares. They start the blockchain and secure it using a server on hand. They arrange to have Best Miner Peershares traded at a couple of exchanges. Shareholders download the Peershare client configured to use Best Miner (which only requires a .conf setting) and each shareholder sends Best Miner their public Peershare address. Trading at the centralized exchange is halted. Shares are transferred to the Peershare addresses supplied. Trading continues at exchanges such as Crypto-Trade and Cryptsy.[/quote]

I believe that Asic Miner shares are not presently listed on a centralized exchange except as pass throughs, so it would be even easier than in the example use case above because Peershare issuance wouldn’t have to be coordinated with a halt of trading on a centralized issuing exchange. Also, though it would help with liquidity to arrange to have Asic Miner shares traded at an exchange such as Crypto-Trade or Cryptsy just as though it were another altcoin, it’s not necessary in this case because it is currently only traded through pass throughs and direct exchange. Peershare would make direct exchange easier (AM would not need to facilitate a trade) and pass throughs would work the same, with the added benefit of automated dividend distribution (to the pass though issuer).