November 25, 2015
Many industries evolve their own unique contract terms and clauses. To the extent that they can be described in algorithmic terms, they can be programmed into smart contracts and approved by the Guild for use in the network. Once a contract type has been approved, transactions using it can be created, and arbitrated accordingly.
For example, lets take a simple fee for service model. This is a contract type that almost all Guilds would allow. A fee for service contract might be required to have a documented issue matching a particular format, a public key for the issue reporter, Bitcoins deposited in escrow, and requirements for satisfactory completion. This is a very fancy way of saying: make a github bug report or feature request and pay up front. In return, the completion and quality of the work are guaranteed by the guild, or you get your money back.
For the developer looking at taking this fee for service contract, they know exactly what work needs to be done, the amount of pay (in escrow already), and that any dispute will be settled by peer review.
Other contracts may involve recurring payments being made to developers. These can similarly be monitored and arbitrated by the network. For instance, if the contract has a clause dictating quarterly revenue sharing, the network can look for a transaction each quarter that matches the expected format and amount. By making the payment on-network, the payer is ensured proper documentation and recognition of the payment in case of arbitration. By receiving the payment on the network, the payee also receives benefits such as arbitration and public rebuke in case of default.
If there is a very complex dispute, a guild-approved or contractually dictated accounting firm could be used to review the books and make a detailed recommendation, which could be paid for by the disputants or out of Guild funds.