Chapter 7 - Payments

This chapter will discuss ledger based workflows which can operate as a points system or payments. The first type of system used is called an Iron Wallet.

Iron Wallets (draft)

Iron wallets are the first phase of rolled out wallets. Future wallets are anticipated to be bronze, silver and gold.

Iron wallets start with a coinbase of 1 million bits.

The first tranche of 100,000 bits is triggered to a named notary (normally a bot) on startup. This first allocation is distributed according to rules decided by the owners.

10,000 bits will normally be allocated to the founders as an initial trade.

Normally a distribution will be based on existing, and ongoing work done over github.

After the first 100k is used, the next 100k should be triggered. It is normal to tweak the rules after each tranche.

A project will also normally have a donation address which bitcoins can be sent to. As the project creates value, the coinbase moves to at least full reserve.

A project will normally have a proof of reserves that can be used in a withdrawal workflow, normally involving a cold wallet.

A project can normally assign payments for common tasks such as commits.

A project can normally assign bounties to issues.

Generally payments are considered first order functions of the web, allowing triggers, hooks, event propagation and smart contracts. JavaScript is the turing complete scripting language. Notaries and oracles can be included using linked data.

Inter wallet trading will allow rich interaction between wallets and projects.

Bits accrued over time will give a proof of contribution and also will normally be assigned ownership of all the funds donated to the project.

Rewards can be given to project members on the public ledger for contributions (aka marking)

Arbitrarily complex workflows can be built on top of the base system.

Github base rewards

Project start:

• Existing commits: 500 bits