Recent Changes - Search:
Protocol /

AccountCreation

I've been wondering whether a special protocol for creating and managing Ripple shared accounts is necessary. Businesses commonly manage shared accounts by each keeping their own copy of the account data and modifying it separately when payments are made. Ripple is at the core a transaction system and ought to be agnostic to the accounting method. If both parties wish to keep track of the account for themselves, then they can do so. If there are other ways of making account entries other than via Ripple, it is not up to Ripple to handle.

Each party sets a credit limit for themselves and for the other party, and authorizes transactions based on those limits. The end result is that the lower number for either limit becomes the defacto limit for Ripple transactions. If the parties want to expose those limits, their interpretation of the current balance, or other pieces of account data to each other, that can be left up to the accounting system itself.

To ripplify an account with party B on party A's accounting system, A's accounting system would register the account with A's Ripple transaction server, which would then notify B's transaction server, which would ask B to give a corresponding account ID, if one exists, on his accounting system. If A and B happen to share an accounting system, each transaction server would query the same accounting system independently to ensure that the other transaction server wasn't cheating. If A and B also shared the same transaction server, then obviously the accounting system would only need to be queried once.

The old write-up (for posterity)

The Ripple transaction server design allows for integration with different accounting systems. To integrate with accounting systems, the Ripple transaction server provides the following API hooks:

  • register account
  • register exchange offer between accounts (connect accounts for routing purposes)
  • various methods for carrying out path queries and payments

In return, to integrate with the Ripple transaction server, the accounting system must expose the following capabilities through an API:

  • exchange query (how much credit is available on account B in exchange for X on account A?)
  • pre-authorize a transaction (freeze credit on account)
  • authorize (commit) the transaction

The following examples illustrate a few modes of registering accounts on the Ripple network.

Generic Ripple shared accounts

This is a basic type of account with balance and credit limits. Its main distinguishing feature is that the account data is shared between two hosts, neither of which have to trust the other to be honest with the account-keeping. See Ripple Shared Account Protocol.

Example: A user on Ripple host A wishes to create a Ripple shared account with a user on Ripple host B. Both Ripple hosts must support Ripple shared accounts by running a Ripple accounts server.

  1. The Ripple account server on host A communicates the proposed account details to host B, which obtains approval from the user on host B, and affirms the newly created shared account.
  2. The Ripple account servers on both hosts register the new account with their respective Ripple transaction servers.
  3. The Ripple transaction servers confirm the account to each other, and start using the account in Ripple transactions, with both hosts doing their own account-keeping.

Custom accounts system operated by a currency issuer

An electronic accounting system at a bank, credit union, or private currency issuer can be integrated into the Ripple network.

Example: A user on Ripple host B wishes to create an account with a private currency issuer, who operates Ripple host A for that purpose.

  1. The user on host B opens an account in the private currency issuer's custom accounts system in the usual way (this has nothing to do with Ripple). The user indicates that he wants the account linked to his Ripple ID on host B.
  2. The accounts system registers the account with its Ripple transaction server.
  3. The transaction server on host A requests authorization with host B to use the account for Ripple transactions. Host B confirms this with the user, and reports this confirmation back to host A. The transaction servers start using the account in Ripple transactions, with host A doing the account-keeping.

Custom accounts system operated by someone other than a currency issuer

These types of accounting systems include peer lending and social IOU tracking systems. This category includes all systems where accounts are kept between users of the system, and not with one single entity like a bank. These accounts may have different features from generic Ripple shared accounts.

Example: Alice on Ripple host A wishes to have an account with Bob on Ripple host B kept by IOU tracking system C.

  1. Alice and Bob create the account on IOU tracking system C, and indicate that they'd like the account linked to their Ripple hosts A and B.
  2. The IOU-tracking accounts system registers the account with its Ripple transaction server.
  3. The transaction server at C sends two slightly different variations of the account for approval at host A and B. To host A, it represents the account as being between Alice@hostA and Bob@hostC. To host B, it represents the account as being between Bob@hostB and Alice@hostC. That way, host A and host B will both use host C as an account-keeping go-between for Ripple transactions on the account. Neither host A nor host B maintains balance, credit limit, or other account data.