Demonstration with Gold Taler

This is an example system with Sensible currency. It uses Gold Taler coins, denominated in the official XAU unit for gold, and shows how they are consistently backed in gold. Although use experience remains the same, well-defined trust between payment systems establishes a gold standard with digital coin paymeents.

First, take a minute to get used to the idea of paying in another currency than your national currency. Gold prices are said to fluctuate, but that's because you normally use your national currency as a point of reference. When you regularly pay in gold, you will develop a feeling for its value in that part of your economic life, and it has its own reward. Over time, you would find that gold has better price stability.

Funding an Account

Consider yourself an online buyer who wants to pay with Gold Taler. We'll see how your gold account can be started, and how you could reverse that if you wanted to close it later on. We'll fund your account and see how you get hold of Gold Taler coins to make purchases with.

You can open an account with a gold payment system, let's say One's Gold, and it will have a zero balance. Either somebody pays you there, or you can use a wire transfer to exchange a national currency at the current gold rate to fund your gold account. It is possible that other users transfer from their balance or you could deposit gold in exchange for a national currency deposit; the latter is done by an Exchange Provider, as in the left half of the picture above:

1. You deposit money in the Wire In account number of the Exchange Provider.

2. Upon arrival of your money, they will swap it for gold at the current rate, or at a previously agreed rate. Their operation probably involves having accounts with more parties than just One's Gold, and they make their profit from variations in gold exchange rates and by cleverly combining purchase and sale operations, but none of this is important to you, you will experience it as a purchase of balance at One's Gold which is fully backed in gold.

3. The Exchange Provider books the right amount of Gold Taler off their Exchange Account and into your Client Account, The units will be XAU, the standardised currency symbol for 1 troy ounce of gold. Or it could be an equivalent unit such as grams or kilos of gold, which has a fixed ratio to the XAU unit.

4. The lower balance in the Exchange Account means that the "owned by" arrow puts less gold in the posession of the Exchange Provider. If you were drawn in this image, there would be another "owned by" to you, and the value of that arrow would increase. Since actual gold backs this administration of ownership, we speak of a transfer of the title of ownership to the gold.

5. The opposite procedure also exists, where things happen in opposite order. You transfer the title of ownership to gold in an Exchange Provider's account, usually in line with a previously agreed-upon order, and in return the Exchange Provider books national currency from their Wire Out account to yours.

Since your account is now funded, you probably want to have a wallet with some coins to spend on products or services. This is shown in the right half of the picture above:

1. You ask to mint coins from your account. To do this, some of the title to gold will move from your account (now shown with an "owned by" arrow) to the Claimable Pool of One's Gold administration. This pool is not in any name, but it can be claimed with coins, like the ones you just had minted.

2. The opposite procedure also exists, where you deposit coins to have their value deposited into your account. It does not matter if these are the same coins or ones you got from someone else; the system cannot tell whose coins you present, only that they were minted on the same system and not yet claimed for unminting; in other words, the value has been deposited in the Claimable Pool and so it can now book that to your account.

Basic Payment

Now that you have Gold Taler coins to spend, let's turn to a basic payment to a merchant who uses the same gold system.

You checkout a couple of items from an online webshop and decide to pay in Gold Taler coins. This means that coins are transferred from your wallet, via the web interface, which works like this:

1. You have a Buyer's Account, and took out Gold Taler coins. You may have done this before. This will have lowered the balance in your Buyer's Account by the value of the Gold Taler coins you took out, which effectively meant that you passed your title of gold into the Claimable Pool for the first one who presents the Gold Taler coins you had minted.

2. You send the right amount of Gold Taler coins for your trade to the merchant, who receives them in his wallet.

3. The merchant claims the Gold Taler coins, which are unminted (and destroyed or their codes rendered useless in the process), which subsequently books the title to the amount of gold into the Seller's Account.

4. Note the "owned by" arrows that indicate that you own gold up to the point that you have Gold Taler minted for it; at that point the gold is claimable to the bearer of the Gold Taler coins. When the claim is made by the merchant, the title to that gold is made his.

5. The underlying system has (at least) the amount of all Accounts plus the Claimable Pool available in actually stored gold. It lies safely in an insured vault, and does not have to move physically. What moves is the title to the gold, and with it, the right to claim ownership. While it is claimable via Gold Taler coins, this still holds and the Claimable Pool will yield it when presented with those coins.

Crossover Payment

The basic payment scenario is useful for payments made inside the same One's Gold system. But this is limited to that community, which is still barred off from the rest of the world. It is possible to use wire transfers denominated in national currencies between gold payment systems, but that incurs exchange rate expenses. As a result, gold cannot yet work as a currency to stand on its own. The goal is to support direct trading in gold, even between payment systems.

This is possible when gold payment systems build trust relations. This is not so much a matter of faith, but of checking each other's contractual obligations and legal construction. Trust basically means that the trusting payment system does not mind that the other system manages some of its gold backing in its system. That allows gold payment systems to have an account with each other, and depend on the backing in those accounts, expressing a title to gold to claim at any time.

An efficient gold-only payments from your chosen One's Gold sytem to a merchant's Two's Gold system works as follows:

1. As before, you have a Buyer's Account and you checked out part of its balance in the form of Gold Taler coins.

2. You pay the merchant via his web interface, by transferring the right amount of Gold Taler coins.

3. The merchant claims the Gold Taler coins with Two's Gold system with the intention to increase its balance on his Seller's Account.

4. There is a trust relation from Two's on One's, and based on that it relays the coins minted by One's to that system, to have them unminted.

5. Unminting the Gold Taler coins removes value from the Claimable Pool, where it was available for precisely this purpose. Unlike before the title to gold does not transfer into the Buyer's Account but into a mutual account held by Two's gold system.

6. Note how this enhances the value administered by Two's Gold. The value in Two's Account is not part of One's Gold balance, but of the merchant's balaance. Since Two's has validated the procedures at One's Gold, it trusts the full backing and correct handling at One's Gold and can use the value as fully backed gold. So, an import process is started that creates the title to gold in Two's Gold system, which transfers into the Seller's Account.

7. This is delegated ownership. One's delegates to Two's which delegates to Seller's Account. Think of it like this: Of the gold that One's has in its vaults, a few bars may belong to Two's, and of those few bars a part is owned via Seller's Account.

8. Note how these operations are all local to the Payment Systems, and that the only things passed between them is the value entrusted by Two's under the management of One's.

This transaction is based on trust by Two's Gold in full backing and proper legal operations by One's Gold. Specifically, Two's Gold introduces currency on the basis of the extra coverage via Two's Account at One's Gold. The opposite is also possible:

This assumes that Two's Gold maintains a One's Account which is "owned by" One's Gold. Instead of introducing more amount entrusted by Two in One, it is also possible to reduce the amount entrusted by One in Two, different only in steps 5 and beyond:

1. As before, you have a Buyer's Account and you checked out part of its balance in the form of Gold Taler coins.

2. You pay the merchant via his web interface, by transferring the right amount of Gold Taler coins.

3. The merchant claims the Gold Taler coins with Two's Gold system with the intention to increase its balance on his Seller's Account.

4. There is a trust relation from Two's on One's, and based on that it relays the coins minted by One's to that system, to have them unminted.

5. Unminting the Gold Taler coins removes value from the Claimable Pool, where it was available for precisely this purpose. Unlike before the title to gold is to be destroyed, to prepare for an upcoming reduction of "owned by" value from One's Account at Two's Gold. This reduces the administered by One's Gold, which mirrors the payment made from Buyer to Seller.

6. Note how this does not change the value administered by Two's Gold, but rather reduces the backing value for One's Gold and assigns it to the Buyer's Account. Since Two's has validated the procedures at One's Gold, it trusts the full backing and correct handling at One's Gold and can use the value as fully backed gold. So, it trusts that One's Gold reduces its managed total.

7. This reduces delegated ownership. Two's delegates less to Two's so it can move the value into Seller's Account. Think of it like this: Of the gold that Two's has in its vaults, a few bars may belonged to One's, and of those few bars is moved into Seller's Account.

8. Note how these operations are all local to the Payment Systems, and that the only things passed between them is the value entrusted by Two's under the management of One's and vice versa. If this "vice versa" were not true, there would be a zero balance in One's Account at Two's Gold, and this procedure would not be possible.

These two operations can be converted into each other with a simple add-on operation, as described below. This also means that they can be combined at will, so it is possible to state that one of two accounts should be zero after every transaction; either One's Account at Two's Gold or Two's Account at One's Gold should be zero. (The reason to say "should" is that a stricter "must" could reduce the degree of concurrency between One's Gold and Two's Gold, which could prove unpractical.)

Changes to Mutual Accounts

It is possible for One's Gold to hold an account with Two's Gold, and vice versa, and rely on it for physical storage of gold. This is only possible when the trust between the systems is bidirectional (or mutual).

The cyclic dependency may lead to blown-up claims of gold stored, but that is easily mitigated. The mutual accounts should be subtracted to find their effective value. One's Gold held with Two's Gold is simply the value on One's Account at Two's Gold minus the value on Two's Account at One's Gold, and vice versa. This enables the administration of mutual backing without overlap; any public claims and audits must consider the difference rather than only the remote account.

Still, it is useful to curtail the trust to the lowest practical level. When payments need to crossover between gold payment systems, then ideally by reducing the degree of trust, rather than increasing it. When both take in payments from each other, than both the imports could pile accrue potentially high overlap of One's Account at Two's Gold with Two's Account with One's Gold. When payments are sequentially processed, then this could be achieved by choosing and even combining the crossover transactions above. In a concurrent system, this may not be fully attainable, but separate compensation measures are possile. These can be mixed in with the claims of Gold Taler coins, and this is how the two kinds of crossover payment procedures relate.

There is no effect from changing the values on these accounts, provided that it is done in the same manner in both of the mutual accounts, so One's Account held with Two's Gold must change by the same amount as Two's Account held at One's Gold. This can go up or down (but never to a negative balance), as shown in this diagram:

1. Any changes in the mutual accounts are drawn from or dropped into the Unallocated Pool of a gold system; this represents the amount of gold that is physically backed but has yet to be allocated to an owner or claim reason.

   As a rule, transactions should not add more than the amount that they need for a transaction. It is possible to first try to reserve the amount from available balance, and resort to mutually adding value only inasfar as needed. In a concurrent system this may be more difficult, and reservations may give rise to lower and upper bounds of the available account balance, which may lead to have buffers in place to the size of in-transit funds.

2. When mutual trust has accrued to a high-enough value that it makes sense to bring down, then the mutual accounts can be brought down in a mutual transaction. This has no impact on the prescribed outputs, since they are founded on the difference between these accounts.

   This should only fail if the subtracted amount cannot be reserved on both systems. This is the case when one of the balances minus reservations on that balance is lower than the requested amount of lowering. This instruction may be integrated with other changes, but that might lead to transaction failure; it may also be separately run, at intervals and perhaps during quiet hours.

3. Alternatively, when there is any need to make reservations on another party's local account, then it may be necessary to increase it to a high-enough level. This is possible when it is compensated on other side, once again with the intent to avoid changes to the (widely reported) difference between the mutual accounts.

4. Note how there can be a trading reason to increase the value in mutual accounts.
   This value may be constrained to realistic patterns or call for manual inspection.
   The lowering of the mutual accounts are more like "garbage collection"; although it has no formal impact, or any reported impact, it is still attractive to avoid the bloat of apparent mutual dependency. Doing this to a level that avoids manual approval for common patterns is probably the most prudent.

Note how the first crossover payment procedure only requires trust of Two's Gold in One's Gold, without necessary reverse trust. Adding one of these mutual-account-change operations would also require such reverse trust, and form the second crossover payment procedure which also requires bidirectional trust. The mutual-account-change operation to add would be the export of the same amount as is being unminted. The difference is that it imports the same amount as it exports, atomically so undetectable, while the second procedure instead shows a direct transfer. The effect is the same, and all is annotated with the same atomic operation, or transaction.

Note how this combination can be made for the whole unminted amount or partially. This enables a gradual mixture of the two procedures for crossover payment. The best implementation is probably one that checks constraints on the overall effect of a multi-leg operation involving both sides. In those, trust in a party would be required to accept that they increase the amount in the trusting party's account with the trusted administration. Plus access rights to remove funds from accounts, of course.

Crossover Account Transfers

Payments via Gold Taler coins offer a general payment mechanism, but they also add some complexity with respect to transfers between a Buyer Account and a Seller Account (also commonly referred to as payer and payee). Having solved the complexity of payments to a trusting party, it is also possible to simplify this to the situation of transferring the title to gold between a Buyer and a Seller without the intermediate Gold Taler state, by simply looking at the overall process impact and defining it as one atomic transaction.

The receiving gold system must of course trust the paying gold system, otherwise any offered assets would have no basis for acceptance. If this trust exists, then the following procedure is possible:

This procedure is a simplification of the transfer via Gold Taler coins:

1. The person with Buyer Access Rights orders a transfer from the Buyer's Account to the Seller's Account.

2. Since the Seller's Account is not part of One's Gold but of Two's Gold, the transferred amount is booked to Two's Account at One's Gold.

3. Two's Gold is hereby given extra backing of gold and so it can import that gold and delegate its title to Seller's Account.

4. The person with Seller Access Rights can now check whether the transfer has arrived.

As with the indirect transfer via Gold Taler coins, there is another procedure that can be used for bidirectional trust between One's Gold and Two's Gold:

This procedure is a simplification of the second procedure for the transfer via Gold Taler coins:

1. The person with Buyer Access Rights orders a transfer from the Buyer's Account to the Seller's Account.

2. Since the Seller's Account is not part of One's Gold but of Two's Gold, but One's gold trusts Two's gold and has sufficient balance in One's Account at Two's Gold, it locally destroys the booked value.

3. Two's Gold sees that One's Gold reduced its reliance on gold backing by the transfer amount, which allows the removal of that amount from One's Account at Two's Gold. This amount is transferred into the Seller's Account.

4. The person with Seller Access Rights can now check whether the transfer has arrived.

As before, the two procedures can be combined at will by mixing the first form with a mutual-account-reduction of anywhere between 0% and 100% of the amount, so as to construct a desired way to claim the desired acount balance to meet the transaction amount.

Scaling Up and Down

To run a Gold Ownership Adminstration with full backing in physical gold, some amount of gold must be stored. This is usually done safely in a vault with insurance to recover from theft, should it ever occur. Such vaults can take in new bars or coins or other forms of the physical metal, and store them on pallets. They can also ship it elsewhere.

This has an impact on the administration:

1. When gold arrives at the vault, the administration can back more value. The gold is added to an Unallocated Pool which is not owned by any account, nor is it in the Claimable Pool. This is the working capital for the administration, and it is the only value that may appear on its balance.

2. When too much value accrues in the Unallocated Pool, it is possible to sell gold, but only after lowering the value in the Unallocated Pool.

3. At each moment in time, a Gold Ownership Administration must have enough gold in its vaults for the total of the Unallocated Pool, the Claimable Pool and all its Accounts. In systems with more intermediate accounts, these also have to be fully backed.

4. The Unallocated Pool can be used to pay to the Accounts of other parties, and payments may be received from it (such as for fees). No transaction between other Accounts may ever pass through the Unallocated Pool, because the Unallocated Pool would make that value appear on the balance of the payment system itself, removing the protection against bankruptcy of the payment system.

5. When a customer deposits physical gold, then the target account is not the Unallocated Pool but the customer's account. The same applies in the opposite direction when a customer wants to have physical gold delivered on the basis of his account. It is important to bypass the Unallocated Pool in these cases, once more to avert counter-party risk in case of bankruptcy of the administration office.

6. The total amount of physical coverage is not only determined by the vault-stored gold on one's own pallets. Additional coverage may be had from mutual accounts with other systems. The mutual accounts that these other systems have with us must however be subtracted.

7. The physical storage can only be increased in relation to other trusted gold systems. This can go both ways; the other system may increase or decrease the vault backing, and we need procedures to ensure full backing. This never comes up with individual user's accounts, because user accounts only lean on the gold backing but themselves never offer to add to their payment system's gold backing.

Another flow allows the transport of gold between payment systems:

1. Two's has so much value accrued in Two's Account at One's adminsitration, that it decides to purchase a bar of gold from One's.

2. Two's takes out Gold Taler coins from One's. It may additionally add Gold Taler coins from others that One's trusts. For that, more such mutual accounts with others would be needed. Two's may also choose to temporarily reserve some of its own physical gold to mint Gold Taler coins if One's trusts those. The total amount is denominated in XAU and must match the weight of the gold bar (plus any fees).

3. Two's now requests an export of gold from One's system. This triggers a shipping instruction in the vault. Upon arrival of the gold at Two's, an arrival notification allows adding the value via Two's import to its Unallocated Pool.

4. Note that the coins amount to the same value as the bar, and lower the value in Two's Account at One's and possibly others, and/or the value in Two's Unallocated Pool, to the same XAU amount as the gold bar weight. The amount is replenished into Two's Unallocated Pool when the gold bar arrives.

5. Note that One's receives claims to gold in the same XAU value as the weight of the gold bar. This enables it to release that part from its vault. Note how the value arrives through Claimable Pools in the various systems for minted Gold Taler coins for the transaction, and the claims on these all end up increasing One's claims on vaults managed by others, or lowering the need for One's own gold to fulfil its full backing obligation for a lower Two's Account.

6. Physical transport of gold can be a hefty procedure, but it can also be a relatively light one. Gold payment systems often employ multiple vault operators to store their gold, and an overlap is likely enough. This creates an opportunity to move a gold bar internally or even just in terms of administration.

A shiny new Gold Standard

This system implements the old idea of a gold standard, where all value is fully backed by gold, to assure price stability and long-term retention of purchasing power. This system has long been the foundation for daily trading among people. It is not a suitable currency for economic systems that depend on perpetual growth (such as investment).

New about this particular gold system is that it offers digital currency, suitable for efficient online payments. The underlying trading mechanisms enable maximum efficiency even when crossing over between gold systems, as long as trust exists in the factual storage of gold by other payment systems. This trust relies on procedures and legal structures, along with audits of the full backing property.

Gold represents value, and both its storage and transfer of ownership are subject to financial regulation. A bank license is usually not required, because the value is fully backed. Filing as a financial institution is a more likely requirement, with related auditing and reporting, and focus on participation in crime fighting operations.