Coalition governance is a mechanism built into the protocol that allows coalition members to collectively make decisions on important matters regarding the coalition’s operations. All coalition governance matters comprise the coalition terms, which is a binding legal agreement concerning the behaviour of the coalition members, coalition host, and other parties such as application vendors.
The coalition terms is a hierarchically-organised document, which contains a combination of technical clauses defining the behaviour of the components in the coalition architecture, as well as legal clauses guiding the organisational relationships. Typical coalition terms will contain the following sections:
  1. 1.
    Technical criteria defining the minimum level of technical capabilities that a coalition member must exhibit in order to participate in coalition transactions. This includes such matters as service level objectives (e.g. Corda node availability), software constraints and configuration (e.g. which Corda notary service to use) and so on.
  2. 2.
    Coalition admission rules such as a minimum amount of 180Tokens that must be staked at the protocol layer to join the coalition.
  3. 3.
    Coalition governance rules, such as quorum requirements, and whether individual votes must be revealed.
  4. 4.
    Fee payment rules and allocation formulas defining what payment instrument is used within the coalition (e.g. fiat currencies, digital assets, cryptocurrencies), and how fees paid as part of network transactions are apportioned among the coalition members, application vendors, coalition itself, and the protocol layer.
  5. 5.
    Token allocation formulas defining how 180 Tokens flow between coalition members as a result of value-creating network transactions.
  6. 6.
    List of CoApps admitted to the coalition and parameters that prescribe the way the CoApp is working within the coalition. This is specific to the functioning of the CoApp, and may include such parameters as transaction fees, data retention rules, and allowed encryption algorithms.


Coalition terms are recorded on the Corda ledger in the form of contract states managed by the protocol CorDapp. Individual clauses are represented as separate state objects, and are hierarchically-organised. Each clause has a unique reference number, and all revisions of the clause will share the same reference number.
The governance mechanism ensures there cannot be two unspent states representing different versions of the same clause in the coalition network at the same time. This is ensured by the protocol CorDapp that requires that any governance transaction issuing a new version of the clause state consumes the previous version of the clause state.
Clauses that can be automatically enforced by the coalition infrastructure (specifically, the protocol CorDapp) or by CoApps (specifically, by the CoApp brokers and aggregators) are recorded as machine-readable states modelled as a labelled tree of typed scalar values (roughly equivalent to what is possible to represent in JSON). This data model caters for a broad range of scenarios, allowing on one hand the capture of simple parameters in the form of key-value pairs, and, on the other hand, the representation of complex nested formulas for fee allocation. In the latter case, mathematical operations of a formula are represented as the labels of the tree nodes (e.g. “+”, “=”, “for each”, “no one”), while leaves either contain constant values or refering to known variables that are used in a calculation. Clauses that could not be automatically enforced are recorded in a textual form.
States that represent clauses relevant to a protocol transaction must be included in the transaction by reference. This, together with the fact that there cannot be two unspent states representing different versions of the same clause in the coalition network at the same time (see above), ensures that no protocol transaction using outdated terms will ever take place. If a transaction attempts to reference an old version of a clause state, a notary service operating within the Corda network will reject such a transaction because the state corresponding to the old version of the clause will already be spent.
The following diagram illustrates this principle:

Diagram Notes

Transaction 1 is valid and takes place when both clauses are still in version 1 represented by unspent states. Subsequently, a governance action evolves clause 2 to version 2, by issuing a new state object and consuming the previous one. Transaction 2 is identical to transaction 1, but cannot be validated because it references a consumed version of the clause 2 state. Transaction 3 addresses this and references the updated clause state of version 2. If another governance action evolves clause 1 to version 2, then again transaction 4, which is identical to 3, cannot be validated and transaction 4 needs to be created referencing version 2 of both clause states. Note that previous versions of the clause states remain in the ledger, so that historical transactions can be validated in the context of relevant clause versions, which is necessary if a transaction chain needs to be shared with a new member.


From the protocol standpoint, coalition governance is a series of governance motions that take place between the members of the coalition. The governance motion itself is a long-running process coordinated by the coalition host and containing distinct phases, each of which is mapped to a protocol transaction of a particular type. Governance motions are initiated in order to introduce new or change existing clauses of the coalition terms. Successfully completed governance motions result in putting new versions of the clauses in play, while unsuccessful motions do not result in any changes to the coalition terms.
The following table outlines the phases of a governance motion action and related protocol transactions:
Motion Phase
Protocol Transactions
Proposal: Any member and/or the coalition host can raise a proposal for changing clauses of the coalition terms
Propose governance motionaction: Includes the details of the proposed changes and may contain other supplementary details such as a rationale and voting deadline
All coalition members and the host are notified of a proposed motion
Voting: All members must lodge their votes, which are counted in proportion to the holdings of c180 Tokens among the coalition members, subject to a cap.
Lodge votes: Members make their voting decisions known to the host. Individual votes are recorded on the ledger as states, and members can use various privacy-preserving techniques to obfuscate their identities (e.g. Corda anonymous parties)
Amend governance action: At any stage, a member who made a proposal can issue a new version or retract it. Votes lodged against a previous version will become invalid.
The coalition host has a record of all voting decisions.
Closure: Upon reaching the voting submission deadline, votes are counted and, depending on the result, the motion either succeeds or fails.
Count votes: The host initiates a transaction that consumes all vote states on the ledger, and notifies members of the outcome.
Completion: In case of a successful motion at a predetermined point in future (implementation time) the host initiates a transaction that forces the new term’s clauses to come into effect
Members become aware of the overall vote breakdown. They may also become aware of how individual members voted unless privacy-preservation is allowed by the coalition terms, and used by members.
In case of a successful action, the proposed amendments to the term’s clauses come into effect at a predetermined point in future.
There could be more than one outstanding governance motion at any given moment. The governance mechanism allows motions that cover different sets of clauses to progress independently. However, if there are two motions with overlapping clauses going through the voting phase simultaneously, the integrity mechanisms for clause states described above will only allow one motion to complete, and the other would need to be amended.
Coalition terms may guide the details of execution for governance actions. For example, there may be a quorum rule for voting to be considered valid, and there may be different quorum rules for different clauses.

Coalition Governance CoApp

The protocol provides a special-purpose Coalition Governance CoApp allowing coalition members to exercise their governance rights with regard to the coalition. The CoApp provides coalition members the following functionality:
  1. 1.
    Access to the current state of coalition terms, presenting both machine-readable and plaintext clauses in a way that could be reviewed by a human
  2. 2.
    Access to historical versions of coalition terms as well as the full history of changes made through successful historic governance actions
  3. 3.
    Access to the list of outstanding governance actions as well as a human-readable version of the to-be coalition terms that would ensue if the action is successful
  4. 4.
    Ability to vote on any outstanding governance actions

Protocol Governance

Protocol-level governance is performed through a public mechanism using proposal voting system, where votes are accounted for in proportion to the holdings of 180Tokens on the public Ethereum network held by entities in addresses they control directly, as well as their holdings of c180 Tokens in circulation on the coalition network. 180Protocol will utilize a suitable framework like Aragon or Moloch DAO to effect the protocol level governance using the 180Token.