Skip to content

Latest commit

 

History

History
781 lines (621 loc) · 31 KB

ole-099.adoc

File metadata and controls

781 lines (621 loc) · 31 KB

OLE 099

  OLE: 099
  Layer: Consensus
  Title: Unimplemented Features from Original Omni Layer Specification
  Author: The Original Omni Specifiers
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/OmniLayer/Documentation/blob/master/OLEs/ole-099.adoc
  Status: Draft (Withdrawn)
  Type: Informational
  Created: 2012-01-06
  License: http://unlicense.org

1. Introduction

1.1. Abstract

This document contains proposals for features that were described in the Omni Layer Specification v0.6 that have not been implemented and are not currently under development. Some of these proposed features first appeared in the original "The Second Bitcoin Whitepaper" by J.R. Willett.

This OLE is informational only. Once we have team agreement that this document is complete, the status will change from Draft to Withdrawn. If someone wants to propose implementing any of the features in this document, they can and should submit one or more new OLEs for the feature(s) they wish to implement.

The Specification section of this OLE is essentially a copy of the "Future Transactions" section of Omni Layer Specification v0.6.

1.2. Copyright

This OLE is licensed under the Unlicense as was the Omni Specification v0.6.

1.3. Table of Contents

Since this is a historical document, the formatting of this OLE is slightly different. We are providing an in-line, 3-level, table of contents to make it easy to see all the proposed transactions at a glance.

Table of Contents

2. Specification

This OLE is WITHDRAWN and has been published for information purposes only, the transactions described below are not implemented in Omni Core based upon this document. It is possible that some subset of these transactions could be implemented in the future if new OLEs for those features are created, approved, and implemented.

2.1. Creating a List of Addresses

The Omni Protocol allows the creation of a list of addresses which can then be referenced by other transactions. For instance, some tokens may be restricted to only be used by a set of approved addresses, such as addresses of people who have provided identifying documentation in compliance with KYC (know your customer) AML (anti-money-laundering) laws. See the introduction to Smart Properties in the Specification for details on how to restrict a token to a set of addresses.

To create or append a list of addresses, publish the following notification from the address which will maintain the list:

Field Type Example

Transaction version

Transaction version

0

Transaction type

Transaction type

32

Number of addresses

Integer one-byte

4

Address 1

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BEE

Address 2

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BED

Address 3

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BEC

Address 4

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BEB

That transaction effectively starts the list (or appends it), and provides a handle to refer to the list (the address which published this message). Note that this transaction could be massive if a lot of addresses are added, and may require large fees in bitcoins. Additionally, 0.00000001 OMNI (smallest unit of OMNI) are burned for each address added, so the address maintaining the list must have enough OMNI and BTC on hand to cover these fees.

2.2. Removing Addresses from a List

To remove addresses from a list, publish the following notification from the address which maintains the list:

Field Type Example

Transaction version

Transaction version

0

Transaction type

Transaction type

33

Number of addresses

Integer one-byte

2

Address 1

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BEE

Address 2

Bitcoin Address

010966776006953D5567439E5E39F86A0D273BED

Any referenced addresses are removed from the list. Note that as with the previous transaction type, this transaction could be massive if a lot of addresses are removed, and may require large fees in bitcoins. Additionally, 0.00000001 OMNI (smallest unit of OMNI) are burned for each address removed, so the address maintaining the list must have enough OMNI and BTC on hand to cover these fees.

2.3. Transactions to Limit Funds (Theft Prevention)

The Omni Protocol defines some transactions which effectively lock funds from being spent quickly, making theft of a “savings” wallet much more difficult, even if that wallet is online.

2.3.1. Marking an Address as “Savings”

  1. Transaction version = 0

  2. Transaction type = 10

  3. Reversibility period = 2,592,000 (30 days)

Marking an address as savings is PERMANENT and cannot be undone. If an address is marked as savings, the reversibility rules affect not only OMNI, but any Omni Protocol child currency stored at that address.

When marking an address as savings, the reference payment points to a “guardian” address authorized to reverse fraudulent transactions. The guardian address should preferably be from an unused offline or paper wallet. The sending address is the address to be marked as savings.

When a fraudulent transaction is reversed, any pending funds go to the guardian address, rather than going back to the compromised savings address. Also, any funds which remain in the compromised address also go to the guardian wallet.

2.3.2. Restricted send

Say you send funds out of a savings wallet. Doing so requires using a transaction identical to version 0 of “simple-send”, but with the transaction type of 2:

  1. Transaction version = 0

  2. Transaction type = 2

  3. Currency identifier = 1 for OMNI

  4. Amount to transfer = 100,000,000 (1.00000000 OMNI)

An address marked as savings can only do this “restricted send” transaction type. All other transaction types must be ignored, as they are invalid from a savings address. This transaction type is also used for sending from rate-limited wallets.

Funds sent with “restricted send” cannot be used until the send is complete. For instance, when funds are sent from a savings wallet, they are considered “pending” until the reversibility window is past. During the window, the transfer is not considered complete. The recipient address cannot use the funds in any way, including sending them to someone else, selling them, betting them, etc.

The UI should show the fund transfer as “pending” until the time window for reversing the send is past.

2.3.3. Marking a Savings Address as Compromised

Say you notice that the address you marked as savings has been compromised, and you want to reverse transactions and transfer everything to the guardian address. Doing this takes 4 bytes:

  1. Transaction version = 0

  2. Transaction type = 11 for marking a compromised savings address

This transaction must be sent from the guardian address. The reference payment must be to the compromised savings address. Funds from any pending transactions and any remaining funds will then be transferred to the guardian address, both OMNI and any other Omni Protocol currencies.

Advantages of the Savings/Guardian Model

The savings/guardian model is intended to allow the user to take extreme precautions against accidental loss of the savings address (for instance, by storing lots of backups, including in the cloud), and extreme precautions against theft of the guardian address. Although reasonable precautions should be taken, if your savings address gets hacked, or the key to your guardian address gets lost or destroyed, the coins can still be recovered.

This model also facilitates estate planning. You simply give your heir(s) a paper copy to the private key of your savings address, but you keep the guardian address key to yourself. If you die, your heirs can simply transfer the funds out of your savings (they will have to wait for the reversibility period to pass), but they can’t steal from you while you are alive since you are the only one with the key to the guardian address and can reverse their transaction if they try.

It should be obvious that anyone parsing Omni transactions for payment must check that the payment is not reversible before completing the transaction!

2.3.4. Marking an Address as Rate-Limited

Say you want to enforce a spending limit of 1 OMNI per Month on one of your addresses. Doing this takes 20 bytes:

  1. Transaction version = 0

  2. Transaction type = 12

  3. Currency identifier = 1 for OMNI

  4. Spending Limit = 100,000,000 (1.00000000 OMNI)

  5. Limitation Reset period = 2,592,000 (30 days)

Marking an address as rate-limited only affects the specified currency. Other currencies stored in the address are not rate-limited. The limitation reset period begins once the protected address makes a send. Attempting to send beyond the rate limit results in the maximum send possible under the limit.

When marking an address as rate-limited, the reference payment must point to a “guardian” address authorized to remove the limitation. The guardian address should preferably be from an unused offline or paper wallet. The sending address must be the address to be marked as rate-limited. Note that an address could be marked as savings AND rate limited, with the same or different guardian addresses.

An address marked as savings can only do Restricted Send transactions as described above. All other transaction types must be ignored, as they are invalid from a rate-limited address.

2.3.5. Removing a rate limitation

Removing the rate limitation above takes 8 bytes:

  1. Transaction version = 0

  2. Transaction type = 14

  3. Currency identifier = 1 for OMNI

This transaction must be sent from the guardian address in charge of the rate limitation. The reference payment must be to the rate-limited address. Removing the limit affects only the specified currency, and not any other rate-limited currencies stored at that address.

2.4. Data Streams and Betting

The Omni Protocol allows users to publish data onto the bitcoin block-chain, which other users can then bet on.

2.4.1. Registering a Data Stream

(AKA Data Feed)

Say you decide you would like to start publishing the price of Gold in the block chain. Registering your data stream takes a varying number of bytes due to the use of null-terminated strings. This example uses 57 bytes:

  1. Transaction version = 0

  2. Transaction type = 30

  3. Ecosystem = 1 for usable within Omni ecosystem (as opposed to Test ecosystem)

  4. Parent currency identifier = 1 for OMNI (the price of Gold will be published in units of OMNI)

  5. Category = “Commodities\0” (12 bytes)

  6. Sub-Category = “Metals\0” (7 bytes)

  7. Label = “Gold\0” (5 bytes) (if a second “Gold” is registered in this sub-category, it will be shown as “Gold-2”)

  8. Description/Notes = “tinyurl.com/kwejgoig\0” (21 bytes) (Please save space in the block chain by linking to your description!)

The reference payment must be to the bitcoin address which will be publishing the data.

Each data stream gets a 4-byte unique identifier, determined by the order in which they were registered. For instance, if your data stream was the third data stream ever registered, your data stream identifier would be 3. Note that data streams in the Test OMNI ecosystem are completely independent, and have the most significant bit set to distinguish them from normal data streams. However, in sandbox environments using only Test OMNI, these IDs can be displayed without the MSB set, for easier reading.

Since anyone can cheaply register a data stream, and thereby create categories and subcategories, we can assume that there will be a lot of noise. Anyone writing code to display data stream categories should note which data streams are the most actively used, and order categories and subcategories by descending activity, thereby pushing unused categories to the bottom of the list.

If you ever need to change the description/notes for your data stream (for instance, if some poor sport takes down your website), simply re-register it from the same address with the same category, subcategory, and label. When re-registering, you can also change the ticker address by choosing a different address for the reference payment (for instance, if your ticker address gets compromised), or change the display multiplier.

If you wish to cancel your data stream (and all unsettled bets on it), update the datastream to have an empty category, subcategory, and label (null character only for each).

2.4.2. Publishing Data

Say you decide you would like publish that today’s gold price is 15 OMNI per ounce, using the datastream described above. Doing so takes 13 bytes:

  1. Transaction version = 0

  2. Transaction type = 31

  3. Ecosystem = 1 for useable within Omni ecosystem (as opposed to Test ecosystem)

  4. Data = 1,500,000,000 (15.00000000 OMNI per ounce of gold)

2.4.3. Offering a Bet

Say you want to use USDCoins (another hypothetical Omni Protocol currency, each USDCoin being worth one U.S. Dollar) to bet $200 that the gold ticker will not rise above 20 OMNI/Ounce in the next 30 days at 2:1 odds. For the sake of example, we will assume that USDCoins have currency identifier 5. Creating this bet takes 36 bytes:

  1. Transaction version = 0

  2. Transaction type = 40 for creating a bet offer (32-bit unsigned integer, 4 bytes)

  3. Bet Currency identifier = 5 for USDCoin (32-bit unsigned integer, 4 bytes)

  4. Data Stream identifier = 3 for the Gold ticker, per our data stream example (32-bit unsigned integer, 4 bytes)

  5. Bet Type = 35 for “Will not exceed on or before” (See table below) (16-bit unsigned integer, 2 bytes)

  6. Bet threshold (Non-CFDs only) = 200,000 (0.00200000 BTC, which equates to a ticker value of 20 per our data stream example) OR Leverage (CFDs only) = 65536 (1x leverage) (32-bit unsigned integer, 4 bytes)

  7. Settlement Date = January 1st, 2215 00:00:00 UTC (8 bytes)

  8. Amount of wager = 20,000,000,000 (200.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)

  9. Amount of counter-wager = 10,000,000,000 (100.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)

Since this bet is not a CFD (described later) “bet threshold” is used rather than “leverage”.

By offering $200 against $100, the desired 2:1 odds are implied. Since one address might want to have multiple similar wagers, it is not possible to change a bet (you must cancel and then broadcast a new bet). To cancel your bet, rebroadcast it with all the same data except set the amount of wager to zero.

Table of Bet Types

0

Will equal on

32

Will equal on or before

1

Will not equal on

33

Will not equal on or before

2

Will exceed on

34

Will exceed on or before

3

Will not exceed on

35

Will not exceed on or before

4

Will be below on

36

Will be below on or before

5

Will not be below on

37

Will not be below on or before

6

Bullish Contract for Difference

7

Bearish Contract for Difference

A “Contract for Difference” (CFD) allows a bettor to temporarily gain bullish or bearish exposure to a price movement, in direct proportion to that movement. A bettor who creates a bullish CFD on Gold with 1x leverage (65536) will receive 10% of the counter-wager funds if Gold rises 10% during the period of the bet. If instead Gold falls 10%, the bettor loses 10% of his own money at stake. As with normal bets, 0.5% of the total pot goes to the creator of the data stream before winnings are determined.

CFD bets store “leverage” in place of the data used by “bet threshold” in other bet types. If a bettor prefers that a 10% price movement means a 20% gain or loss, they may select 2x leverage (65536*2=131072). Similarly, a 10% price movement could mean a 5% gain or loss using 0.5x leverage (65536*0.5 = 32768). Just as with normal bets, a CFD bettor can “sweeten the deal” by offering better odds (a lower counter-wager amount). High-leverage bets or big price movements could result in a winnings calculation higher than the amount at stake, in which case the winner simply gets the entire pot.

2.4.4. Accepting a Bet

Say you see a bet which you would like to accept. Simply publish the inverse bet with matching odds and the same end date, and the Omni Protocol will match them automatically (that is, everyone parsing Omni data will mark both bets as accepted). Here is what a bet matching our last example would look like:

  1. Transaction version = 0

  2. Transaction type = 40 for creating a bet offer (32-bit unsigned integer, 4 bytes)

  3. Bet Currency identifier = 5 for USDCoin (32-bit unsigned integer, 4 bytes)

  4. Data Stream identifier = 3 for the Gold ticker, per our data stream example (32-bit unsigned integer, 4 bytes)

  5. Bet Type = 34 for “Will exceed on or before” (See table above) (16-bit unsigned integer, 2 bytes)

  6. Bet threshold (Non-CFDs only) = 200,000 (0.00200000 BTC, which equates to a ticker value of 20 per our data stream example) OR Leverage (CFDs only) = 65536 (1x leverage) (32-bit unsigned integer, 4 bytes)

  7. Settlement Date = January 1st, 2215 00:00:00 UTC (8 bytes)

  8. Amount of wager = 5,000,000,000 (50.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)

  9. Amount of counter-wager = 10,000,000,000 (100.00000000 USDCoins) (64-bit unsigned integer, 8 bytes)

Note that this bet will be matched against only half of the previous example, because while the odds match (2:1 vs. 1:2), the amount of this bet is for less. This bet is only for $50, so would only win $100 if they win, as opposed to the full $200. Once the bets are matched, the first bet still has $100 available for someone else to bet $50 against.

Once GoldCoins reach a value of 20 or the bet deadline passes, the bet winner gets 99.5% of the money at stake. The other 0.5% goes to the creator of the data stream. When using currencies other than OMNI, a small fee will be deducted (see the "Fees" section of the Specification).

2.5. Distributed E-Commerce

The Omni Protocol allows for the buying and selling of physical goods in a sort of distributed classified ads system, with purchase money held in escrow by the protocol. Some might call this a “distributed e-bay”, while the cynical might call it a “distributed silk road”. Due to the potential for black-market uses of this feature, we encourage our users to know and follow the laws of their respective jurisdictions.

2.5.1. Listing Something for Sale

Say you want to sell a Bible for 0.001 OMNI. Creating a sell offer will use a variable number of bytes due to the use of null-terminated strings:

  1. Transaction version = 0

  2. [Transaction type] = 60 for sale listing (16-bit unsigned integer, 2 bytes)

  3. Currency identifier of price = 1 for OMNI (32-bit unsigned integer, 4 bytes)

  4. Desired price = 100,000 (0.00100000 OMNI) (64-bit unsigned integer, 8 bytes)

  5. Item category = “Contraband\0” (11 bytes)

  6. Item subcategory = “Forbidden Books\0” (16 bytes)

  7. Item title = “Bible, NASB\0” (12 bytes)

  8. Description/Notes = “tinyurl.com/kwejgoig\0” (21 bytes) (Please save space in the block chain by linking to your description!)

Every sale offer published by a given address gets a 32-bit “Listing ID” number assigned, which increments for each item offered for sale from that address. We’ll assume this is the first item offered for sale from this address (Listing ID=0).

To delist an unsold item, publish the exact same message, but with a price of zero. Sellers should make sure they provide some method of contacting them (for instance, on the listing webpage), so they have a communication channel to help resolve disputes with buyers.

2.5.2. Initiating a Purchase

Say you see the Bible listed above and wish to purchase it. However, you have no reputation as a buyer, so you want to offer a 10% higher purchase price than what the seller is asking. You want your purchase offer to expire in 3 days, which is 259200 seconds. Starting the purchase process takes 20 bytes. The optional comment field adds additional bytes:

  1. Transaction version = 0 (2 bytes)

  2. [Transaction type] = 61 for Initiate purchase from listing (16-bit unsigned integer, 2 bytes)

  3. Listing ID = 0 (the ID for the listing above) (32-bit unsigned integer, 4 bytes)

  4. Offer Valid For = 259200 seconds - 3 days (4 bytes)

  5. Offered price = 110,000 (0.00110000 OMNI) (64-bit unsigned integer, 8 bytes)

  6. Comment = “I really want this book!\0” (25 bytes)

The reference address points to the address which listed the Bible for sale with the currency identifier set to 1 (OMNI). The seller now has 3 days to accept this buyer’s before the offer expires. The buyer’s money is now locked in escrow until their offer expires or the purchase is complete.

The purchaser may also offer less than the suggested price. This may be viable for an established buyer and/or a stale listing.

The comment field can be used by the prospective buyer to communicate with the seller either a message, link to a public key, link to a shipping address, email address, plea to accept the lower price, or the answer to a question the seller included with their sale offer.

2.5.3. Accepting a Buyer

If you see an offer that you like, you can initiate a transaction to accept the offer. For any offers that you do not wish to accept because the buyer offers a bad price, has a bad reputation, or has no reputation, then you simply do not accept that specific transaction

The message to accept the offer takes X bytes:

  1. Transaction version = 0

  2. Transaction type = 62 for Accept buyer offer (32-bit unsigned integer, 4 bytes)

  3. Which buyer = 2 (3rd offer received) (16-bit unsigned integer, 2 bytes)

Once a buyer has been accepted, the seller may ship the Bible. When using currencies other than OMNI, a small fee will be deducted (see the "Fees" section of the Specification).

2.5.4. Leaving Feedback

Once a buyer has been accepted, they may release funds held in escrow (or destroy those funds) and leave feedback. To do so takes a variable number of bytes due to the use of a null-terminated string:

  1. Transaction version = 0

  2. [Transaction type] = 63 for Release Funds and Leave Feedback (16-bit unsigned integer, 2 bytes)

  3. Listing ID = 0 (the ID for the listing above) (32-bit unsigned integer, 4 bytes)

  4. Tip percentage = 5 (Offered price + (Offered price * (Tip percentage / 100))) (8-bit unsigned integer, 1 byte)

  5. Text feedback = “tinyurl.com/kwejgoig\0” (21 bytes) (Please save space in the block chain by linking to your feedback!)

The reference address points to the address which listed the Bible for sale. Funds which are not released are permanently destroyed. Specifying more than 100% signifies an additional tip beyond the funds held in escrow. Funds are released automatically after 60 days if the buyer never leaves feedback. In addition to the text feedback, each transaction gets “1 star” to “5 stars” based on the following criteria:

  • 1 Star: All funds destroyed (very unhappy customer)

  • 2 Stars: Some funds destroyed

  • 3 Stars: No funds destroyed, no tip

  • 4 Stars: Tip < 10%

  • 5 Stars: Tip >= 10%

In order to avoid people gaming the reputation system, some coins must be destroyed with every purchase. The percentage of coins destroyed goes down with each new purchase. The percentage is calculated as (value of this purchase) / (2 * value of all purchases, including this one). Note that this formula causes 50% of the coins from the first purchase to be destroyed.

2.6. Escrow-Backed User Currencies (experimental proposed feature)

The most important and also the most controversial feature (at least the escrow backed part) of the Omni Protocol is the built-in support for users to create their own currencies out of existing OMNI. For the purposes of demonstrating how user currencies will work, we will use an example currency called “GoldCoins”, which are intended to track the value of one ounce of gold, and which may be stored, transferred, bought, and sold similarly to OMNI.

2.6.1. Stability Concept

So how do we drive the value of these GoldCoins to their target value, when demand for them may surge and decline? The price of GoldCoins is decided by the balance of supply and demand. Since we can’t control the demand for GoldCoins, we must control the supply. The key to accomplishing this is to use an escrow fund which holds OMNI, as shown below:

Omni Protocol Layers

The escrow fund operates like a battery on the power grid, charging when there is excess energy then discharging where there isn’t enough. When there are too few GoldCoins (GoldCoin price is too high), the escrow fund releases new GoldCoins, and the escrow-battery “charges” by holding OMNI in escrow. When there are too many GoldCoins (GoldCoin price is too low), the escrow fund purchases some of the excess GoldCoins, thereby “discharging” the escrow-battery as it releases the stored OMNI.

2.6.2. New Currency Creation

Say you want to create the GoldCoin currency described above, using the Gold data stream we defined. Doing so will use a varying number of bytes, due to the use of a null-terminated string. This example uses 38 bytes:

  1. Transaction version = 0

  2. Transaction type = 100 for creating a new child currency (32-bit unsigned integer, 4 bytes)

  3. Data Stream identifier = 3 for the Gold ticker, per our data stream example (32-bit unsigned integer, 4 bytes)

  4. Escrow fund delay = 4 for 4 days (see below) (8-bit unsigned integer, 1 byte)

  5. Escrow fund aggression factor = 1,000,000 for 1% (See below) (32-bit unsigned integer, 4 bytes)

  6. Currency Name = “GoldCoin\0” (9 bytes)

  7. Escrow Fund Initial Size = 100,000,000,000 for 1,000 OMNI (64-bit unsigned integer, 8 bytes, causes 1,000 OMNI to be debited from the currency creator and credited to the escrow fund. This number should not exceed the amount owned by the creator, but if it does, assume they are crediting all their OMNI to the escrow fund)

  8. Escrow Fund Minimum Size = 99,000,000 for 99% (32-bit unsigned integer, 4 bytes, if the escrow fund value is ever less than 99% of all GoldCoins, the currency is dissolved and the escrow fund is distributed to GoldCoin holders who would take a 1% loss)

  9. Sale/Transfer Penalty = 100,000 for 0.1% (32-bit unsigned integer, 4 bytes, any time GoldCoins are sold or transferred, 0.1% are destroyed, which improves the health of the escrow fund)

As with properties, currencies are awarded currency identifiers in the order in which they are created. OMNI is currency identifier 1 (bitcoin is 0), and Test OMNI have currency identifier 2, so if GoldCoin is the first Omni Protocol currency, it will get a currency identifier of 3.

The currency held in escrow is the parent currency of the data stream. In this example it is OMNI, but it could also be any Omni Protocol currency. For instance, GoldCoins could later be held in escrow to support a currency whose data stream uses GoldCoins as a parent currency.

The escrow fund delay of 4 days means that the price of GoldCoins must be too high (or too low) for 4 days in a row before the escrow fund will take any action.

The escrow fund aggression factor determines how aggressively the escrow fund corrects the price of GoldCoins when their price diverges from their target. An escrow fund with aggression factor of 0 will never take any action. If the aggression factor is 100%, the escrow fund will take the maximum possible action (buying every GoldCoin for sale above the target price, or selling new GoldCoins to every buyer below the target price).

In the case of a 1% aggression factor, the escrow fund’s first action will be to fix 1% of the error. If the error the next day is still in the same direction, the escrow fund will fix 2% of the error, then 3% the next day, and so on until it reaches 100% or the error changes direction. Once the error changes its direction, the escrow fund has done its job and it starts counting again from zero.

The fields Escrow Fund Initial Size, Escrow Fund Minimum Size, and Sale/Transfer Penalty were added in response to the “bytemaster/d’aniel attack”, which becomes possible once malicious actors are able to short these currencies. The attack only works on currencies with underfunded escrows, and consists of a malicious actor creating a competing GoldCoin with a healthy escrow fund, which the market would presumably prefer over the GoldCoin with the unhealthy escrow fund. The malicious actor could then profit by shorting the unhealthy GoldCoin until people panicked and fled for the healthy version. More information about unhealthy escrow funds can be found in the next section.

2.6.3. Unhealthy Escrow Funds

What if the price of OMNI falls 95%, and the value of the escrow fund is now only 5% of the target value of all GoldCoins? Using the battery analogy, this escrow fund now has less “charge” and is therefore less capable of intervening to correct prices.

If the currency creator had set the minimum escrow size to 100% the escrow fund would never get into this situation because it would simply dissolve and pay out to currency stakeholders as soon as the escrow fund value dropped to parity, with zero or minimal losses. For currencies which are set up to allow continued operation once unhealthy, the protocol responds by adjusting the aggression factor accordingly. In the example of GoldCoins backed by only 5% given above, the 1% aggression factor would be multiplied by 5% to get 0.05%, meaning that the adjustments will be of much smaller magnitude, and it will take a lot longer to get to 100% aggression.

Note that escrow funds holding funds worth more than their currency do not get more aggressive. That is, if the GoldCoins escrow fund is worth twice the value of all GoldCoins in existence, the aggression factor is still 1%.

2.6.4. Maintaining Escrow Fund Health

Given a reasonably stable OMNI, escrow funds should generally grow healthier over time. Our GoldCoin escrow fund, when it does act, is buying GoldCoins when they are cheap, and selling them when they are expensive. Thus it will generally tend to make a profit, and the OMNI held by the escrow fund will grow. The larger the escrow fund, the lower the chance of the currency failing to maintain its value. Additionally, the currency creator can optionally supply initial escrow funds if desired, and the currency can be tuned to destroy some GoldCoins with every sale or transfer, further increasing escrow fund health.

When an escrow fund is unhealthy, lowering the aggression factor makes the escrow fund take more profitable trades, which increases the likelihood of recovery. For instance, if it is buying excess GoldCoins, the cheapest 0.05% can be purchased at a better average price than the cheapest 1% on the market.

Escrow funds should generally be tuned to act slowly. This will allow arbitrage traders to do the heavy lifting, as the knowledge that the escrow fund will eventually get the price back to the target makes for a self-fulfilling prophecy when traders act on that knowledge. If the escrow fund acts too quickly, it loses money when the bitcoin version of a security leads the real-world version, as would happen if someone was engaging in insider trading anonymously using the bitcoin version.