This is a work in progress.

In the basic protocol, nodes each set the expiry time for their own promises, and regulate that expiry independently of each other. This means that it is possible for a transaction to be half-committed if some intermediaries decide their promises have expired while others accept the commit. Commit registries are a way for nodes to ensure this doesn't happen, but the tradeoff is that they give up power over promise expiry to a third party (or several third parties collectively).

The idea is summarized in this mailing list thread:

Using registries can make transactions less risky for intermediaries, and therefore should make it cheaper for them to participate. So fees should be specified according to the risk level of the transaction. If all nodes trust and use the same registry (or set of registries), then risk is lowest. The complications arise when not all nodes trust the same registry.

Promise Registry Requirement Levels

A promise can specify one of the following registry requirement levels:

  • BARE - no registry timestamps recognized
  • SECURED - registry timestamps accepted for late redemption
  • ATOMIC - registry timestamps required for redemption
  • PROXY - registry timestamps required for redemption, but no late redemption possible (promisor does not trust registry, but earlier nodes require it)

Risk Levels

The transaction mode for an intermediary is the combination of registry requirement levels on incoming and outgoing promises, and in turn determines the risk level for that intermediary.

  1. Atomic - commit must arrive pre-timestamped for certain redemption of held promise
  2. Secured - commit can be timestamped by third party for late redemption of held promise
  3. Gateway - commit must be timestamped by third party before promise expiry, may arrive untimestamped
  4. Bare/unsecured - commit must be presented before promise expiry

Risk levels by transaction mode:

 Outgoing Promise

* These modes are riskier for no good reason and would never be used.


Nodes advertise their fees for participating at each risk level, and then the payer finds the cheapest viable path and dictates registry requirement levels on intermediary promises.

Protocol Extension


  • Commit registry - a service that acts as an authority to establish whether a transaction is committed or not.




    enum AtomicityMode = {
        BARE = 0;
        GATEWAY = 1;
        SECURED = 2;
        ATOMIC = 3;


message Registry {
    required bytes registry_key_id = 1;
    required PublicKey public_key = 2;
    required string url = 3;
	required string registry_protocol_version = 4;

TODO: Have separate identity and communication keys like for nodes?

TODO: Define separate registry protocol.

TODO: Update description below.

commit_archive_url is a URL of the form "", so that when "%s" is substituted with a canonical form transaction ID such as "5e025939-6ab8-4563-87b2-7e90f87a84f8", it returns a commit token for that transaction, timestamped and signed by by identity_key. Nodes publishing a commit_archive_url should also publish their host, so commit messages can be submitted to them directly.

Registry List

message RegistryList {
    required bytes registry_list_key_id = 1;
    repeated bytes registry_key_ids = 2;

When multiple nodes (eg, on the same server) use the same list of registries, they can indicate that they use a particular list for efficiency, rather than individually publishing and updating their controllers.

message RegistryFeeSet { // Add below Atomicity Fee Set.

    required bytes registry_fee_set_key_id = 1;
    message RegistryFee {
		required bytes registry_key_id = 1;
		optional string in_promise_rate = 2 [default = "1"];
		optional string in_promise_flat_fee = 3 [default = "0"];
		optional string out_promise_rate = 4 [default = "1"];
		optional string out_promise_flat_fee = 5 [default = "0"];            
	repeated RegistryFee registry_fees = 2;



 	optional bytes registry_fee_set_key_id = 11;

Payment Init:

  - registry_key_ids?  (Had for a bit, not sure why.)


    repeated bytes registry_key_ids = 9;

message TimestampedCommit {

    required Commit commit_message = 1;
    message TimestampedSignature {
        required double timestamp = 1;
        required Signature signature = 2;
    repeated TimestampedSignature = 2;

} ... or something like that.