Peertron - A site for development patronage

The Problem to Solve

As sigmike has pointed out, there is much room for improvement when it comes to funding opensource projects. Peertron is my solution to this problem. It provides a safe and sure way to allow patrons of opensource work to contribute to their creation, without losing control over their power of the funds.

The Solution: Peertron

In Peertron, there are (will be) three different roles: Patrons, Beneficiaries, and Commissioners. Roles are assigned on a project-to-project basis, and are not “account types.” Patrons donate funds to a project; there can be more than one Patron per project, and any other role can also be a Patron in addition to their current roles. Commissioners are the moderations of the project funds; they create the project, monitor tickets, and issue payments. Beneficiaries are the works: programmers, designers, writers, translators, etc; that collect the money in exchange for their services.

Funding Accounts and Control of Funds

How funding account keys work: Peertron holds one key to every funds, to make sure funds never go stale on the server, and can be sent with just the signing of another person on control of the funds to release. Useful for refunds from projects that have seen no work, or paying out on Tickets that have been closed, but a second Commissioner is no where to be found.

There are two funding accounts that be be used in a project, each employing a M-of-N address: Public, and Private. In Public accounts, the Commissioners have full control of any funds, and each get one key to the fund as needed. Patrons are trusting the Commissioners to make the right calls, and manage their money for them. In order for funds to be released from a Public accounts, a Commissioner must create an Invoice from a Ticket that has been closed. The Invoice must then be signed by 2-of-3 keys of Commissioners to be processed immediately, or can be sent after a period of time (72 hours?) using the Peertron key in addition to the Commissioner who created the Invoice (and thus already signed). In Private accounts, the Patron who created the account, as well as Peertron, hold one key for every Commissioner on the project, and Invoices must be signed by M-of-N where M is 1/3 N + 1, meaning the Patron + one Commissioner must sign off on the transaction. If the Patron is also a Commissioner, and issues the Invoice, Peertron will provide the addition key to send the payment without and additional Commissioners. If after and extend period of time (7 days?) the Patron who controls the Private account does not either veto or sign the Invoice, Peerton will provide the additional key to release the funds.

The M-of-N Ignorance Problem

M-of-N address are not (as of right now) easy to accomplish without knowledge of the RPC daemon. To fix that, all user keys will be held on Peertron as BIP38 keys, and all signing and private key work will happen on the front end (never held or known to the Peertron server). Making signing a M-of-N transaction as easy as remembering a BIP38 passphrase.


Peertron will be tightly integrated with GitHub and GitLab using their respective API’s. This will allow Commissioners to create Tickets and Invoices from the Peertron site that appears on their repositories, and return their status upon completion. Meaning when a GitHub or GitLab issue create with tags that represent them as Invoices or Tickets are closed, that is immediately reflected on the Peertron site, and visa-vera. Allowing for better transparency and money tracking.

In Closing

This doesn’t solve every problem encounter with opensource funding of projects, however, I do believe it solves a few. Are there other problems I haven’t given thought to? I’d like to know your opinion on it.

Sounds good and interesting to me, but I do wonder how this relates to Or doesn’t it?
Multisig or similar is on my list of highly desired features anyway.

Peer4Commit does a great job as it is, I’m just not a fan of how it handles funds. Peertron won’t be compatible, or based off Peer4Commit, so I doubt you will see it being replaced by Peertron. In all reality, I don’t expect anyone to use it, I’m just trying to pad my portfolio.

I agree with the current fund handling. It is basically centralised and cannot be trusted unless you trust Sigmike 8)
So I’m all for improvements and it would be a pity when your innovations cannot be used by the community. Whether you would replace Peer4commit or not doesn’t really matter. When there is a better Peercoin product than peer4commit I would be happy to advocate migrations. Ideally I would see Peer4commit upgraded, but realise that is not always practical.
BTW would it be multicurrency? e.g. Peercoin, NuBits and Bitcoin?

Looking forward to your Peertron site and more than happy to discuss ideas and concepts or even test.

That’s the idea. I came up with the basic premise while working on CryptoNodes and Lighthouse.

CryptoNodes can handle any binary based off the Bitcoind client, and only needs to be given the binary location, name of the coin, and its symbol to start working. It handles RPC security, calles, and monitoring the processes health on it’s own. CryptoNodes is just here to help unify calls to blockchains.

Lighthouse is intended to be a Network/Block Explorer, that is capable of processing signed transactions, some block chain analysis, and process callbacks when specific addresses are mentioned.

Peertron would be built off the two projects I’m working on right now. I have another idea in mind for a HTML5 based off the same frameworks, but we will see.

Right now, I’m just trying to get my thoughts in order, so I’m in a good position to make sure everything comes together smoothly.