UMA Whitepaper
UMA Whitepaper
Contract Platform
DRAFT
December 3, 2018
Abstract
We present a decentralized protocol to enable the creation, mainte-
nance, and settlement of financial contracts for any underlying asset. We
propose novel systems for maintaining collateral and confirming off-chain
information to enable market participants to trade with confidence and
transparency. We show that trustless financial contracts remove all bar-
riers to access for every financial market, creating a single global market-
place where any individual, smart contract, or decentralized autonomous
organization can buy or sell any form of financial risk.1
Contents
1 Introduction 3
1.1 Brief History of Financial Contracts . . . . . . . . . . . . . . . . 3
1.2 Synthetic Asset Overview . . . . . . . . . . . . . . . . . . . . . . 4
2 Motivation 5
2.1 Barriers Removed by UMA Contracts . . . . . . . . . . . . . . . 6
2.1.1 Unrestricted Access to All Financial Markets . . . . . . . 6
2.1.2 DAO and Smart Contract Access to Financial Markets . . 6
2.1.3 Unrestricted Access to Short Selling . . . . . . . . . . . . 7
2.1.4 Unrestricted Access to Leverage . . . . . . . . . . . . . . 8
2.1.5 Unrestricted Access to Customized, Bespoke Risk . . . . . 8
1 This white paper references “TRS: A Decentralized Protocol for Trustless Financial
1
2.2 Other Benefits of UMA Contracts . . . . . . . . . . . . . . . . . . 9
2.2.1 Tokenization of Financial Risk . . . . . . . . . . . . . . . 9
2.2.2 Engineered Price Stability . . . . . . . . . . . . . . . . . . 9
2.2.3 Simplification of Institutional Custody Requirements for
Cryptocurrencies . . . . . . . . . . . . . . . . . . . . . . . 10
4 Implementation Mechanisms 20
4.1 Trustless Tokenization . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Future Work 23
6.1 Trade Negotiation Protocol . . . . . . . . . . . . . . . . . . . . . 23
6.2 Margin Netting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 Future Proofing: Currency and Blockchain Agnostic Approach . 25
7 Conclusion 25
2
1 Introduction
The concept of programmable money has always been a core focus of blockchain
research: Vitalik Buterin spoke of “providing users with more powerful ways
of managing and entering into contracts using their money” in the original
Ethereum white paper [1]. The UMA Protocol seeks to extend these efforts
with a specification for trustless, decentralized financial contracts. We show
that trustless financial contracts remove all barriers to access for every financial
market, enabling a single global marketplace where any individual can buy or
sell any form of financial risk. We further show that the UMA Protocol gives
smart contracts and decentralized autonomous organizations (DAOs) the same
access to all forms of financial risk, opening up dramatic new applications for
decentralized financial products.
3
market makers agree to take the other side of the taker’s trade as principal,
meaning that the maker may not have a preexisting position in the risk the
taker is looking to buy or sell. By acting as principal, the maker assumes the
responsibility to hedge or warehouse the economic risk of the trade; this differs
from exchange traded derivatives where natural buyers and sellers of the same
risk meet.
OTC derivatives benefit from immense flexibility—they can be written for
literally anything—and their usefulness led to the rapid growth of the OTC
derivative market in the 1990s and 2000s. It is estimated that over $540 trillion
[2] in OTC financial derivatives are currently outstanding, making the OTC
derivatives market the largest financial market in the world by an order of
magnitude.
This flexibility comes at a cost: counterparty risk. Without a central clear-
ing house, each market participant must trust that the other party will honor
their contracts—even during violent swings in the underlying asset. When a
counterparty fails (as Lehman Brothers and Bear Stearns did during the finan-
cial crisis of 2008), trust may fail and significant systemic risk is introduced into
the market.
4
Figure 1: Total return swap (TRS) flow
2 Motivation
Open financial markets require fair access for all market participants. The UMA
Protocol promotes fair and open markets by removing all barriers to access for
every financial market, allowing any individual, entity or DAO to access any
type of financial risk, without any centralization or single point of failure.
The ability to buy and own (or borrow and sell short) a specific asset has tra-
ditionally been the biggest hurdle to accessing a desired financial risk. Deriva-
tives solve this by replacing the need to custody assets with a contract that
references the price of those underlying assets. This introduces a second hur-
dle: the ability to trust that the counterparty of your derivative agreement will
honor the terms of the contract.
Trust, otherwise known as counterparty risk, is the Achilles’ heel of finan-
cial derivatives today. Because of the risks involved, financial derivatives have
only been made accessible to a small number of sophisticated institutional in-
vestors who rely on traditional due diligence and costly legal process to “trust”
each other. It has never been economical or practical to offer the benefits of
derivatives to anyone besides the largest institutional participants.
We show that UMA contracts use only margin, economic incentives, and the
transparency of the blockchain to allow any counterparty to gain synthetic asset
exposure. In doing so, UMA contracts fully eliminate all barriers to accessing
financial markets, creating a single global marketplace. The benefits of this
universally accessible, open marketplace are hard to understate.
5
2.1 Barriers Removed by UMA Contracts
2.1.1 Unrestricted Access to All Financial Markets
Traditionally, individuals and businesses can only buy and sell financial risks
that are supported by their local government and infrastructure. Regulations
and custody requirements can make it extremely difficult (or impossible) for
an individual or entity to buy anything not explicitly supported by their local
financial system. Sophisticated institutional investors have been able to sidestep
these access challenges using tools like OTC derivatives that remove the need to
physically own or custody assets; these tools, of course, have not been available
to the rest of the market.
UMA contracts bring this benefit to all market participants. They enable
anyone to buy or sell exposure on any financial asset—market participants are
limited only by what market makers are willing to price. Individuals in coun-
tries with weak financial infrastructures are no longer restricted to the limited
investment options accessible in that jurisdiction. No walls exist—any person
or entity with capital can access any risk, creating a single unified and truly
global financial market.
Many people around the world cannot access even the most liquid stock
markets. Due to limitations or inefficiencies in local financial infrastruc-
tures, it is extremely difficult for most individuals in the developing world
to invest in foreign assets like the US stock market. With an UMA con-
tract, the foreign investor can enter into a total return swap that pays the
same economics as directly investing in the US stock market, bypassing the
limitations of that investor’s local financial system.
It seems inevitable that smart contracts and programmable money will create
many new financial innovations; these contracts will need to invest, hedge, and
trade in financial markets.
For a smart contract to access a financial market, it needs to be able to
access that market on-chain. This presents a problem: how do you credibly
reference a traditional, real-world asset on the blockchain? Some approaches
like TrustToken [4] use on-chain tokens to represent assets held in an off-chain
legal structure; this approach is subject to a single point of failure and potential
off-chain legal challenges.
UMA contracts represent another, potentially much more flexible solution:
the smart contract simply becomes one of the counterparties of the derivative
6
agreement. Since the derivative references the underlying asset without needing
to own or custody the asset, this conveniently sidesteps the problem of credibly
representing the asset on-chain.
This allows any smart contract to access any type of financial risk, with
potentially dramatic implications: ideas like decentralized private pension plans,
decentralized insurance and annuity products, and DAO governed hedge funds
or endowments all become possible.
The first “mutual” companies were built to help groups of laborers and arti-
sans pool their collective mortality risk, providing economic aid for families
of the deceased. A collective insurance product can be built using the UMA
Protocol, enabling any group of individuals to pay into a pool that pays a
fixed payment based on their tenure upon their death (either measured by
off-chain oracle or the participant’s failure to sign periodic challenges with
their private credentials). This pool itself can invest into a diversified pool
of assets (of both crypto and other traditional assets) using UMA contracts
to access this risk.
There has been explosive growth in both the number and value of crypto
assets. But this market is almost entirely one-way: it is nearly impossible
7
to bet that prices will decrease. The few options that do allow you to
short assets are centralized solutions that require trust in an exchange or
traditional legal agreement. New decentralized solutions like dYdX [5] are
promising but still require a short seller to find an existing asset owner
who will agree to lend their position. An UMA contract would provide an
easy, simple way to bet against a basket of altcoins: a taker simply enters
into a derivative contract with any market maker willing to take the other
side. Market makers can hedge their long exposure by entering into other
contracts with market participants who want to buy that risk.
8
to individuals as the costs for doing so have been prohibitive. UMA contracts
change this and make it possible to offer anyone a financial contract that exactly
fits their personal financial circumstances, in any market, globally.
Because UMA contracts are governed by smart contracts whose terms are de-
fined by the contract counterparties, these smart contracts can use tokens to
represent the risk exposure of each counterparty. If these tokens are fungible
and conform to a standard, such as ERC-20, they are easily traded and trans-
ferred on exchanges. This expands the tokens’ visibility, allowing individuals to
gain access to financial risk without directly interfacing with an UMA contract.
This is particularly important for investors with less capital, who need not
commit to the notional of an UMA contract due to the tokens’ divisibility.
Decentralized financial products, such as DAO hedge funds or other parties as
mentioned in subsubsection 2.1.2, can also tokenize their exposure. This allows
the entity’s smart contract to do the work of maintaining the exposure via an
UMA contract, while the entity’s investors need only trade the tokens in their
own wallets.
9
underlying asset. Because UMA contracts allow counterparties to define all
of the economics of their exposure, counterparties are able to define financial
contracts allowing for synthetic exposure regardless of the change in FX rate
between the margin currency and the underlying asset’s currency.
10
3.1 Contract Architecture
The UMA contract contains 5 core components:
Each UMA contract has two margin subaccounts: margintaker , and marginmaker .
The maker and taker margin accounts exist as subaccounts inside the con-
tract and can be only be accessed by the maker and taker respectively, as well
as by the contract. The maker and taker are free to add or withdraw funds from
11
their margin accounts at any time; they are only required to keep an appropri-
ate balance in those accounts to meet the agreed upon margin requirements to
avoid any potential early termination or default penalties.
Every time the contract is run and the economics terms (NPV) are recalcu-
lated, the contract moves the appropriate balance between the margin subac-
counts so that the current NPV of the contract (which will be owed to either
the maker or taker) is moved into the maker or taker’s margin subaccount.
The economic terms of the agreement are immutably recorded in the code of the
smart contract. This code references one or more price feed oracles that return
the current price of the underlying reference asset; the challenge of securing the
oracle price feed is discussed in more detail later in a separate white paper.
As an example, assume the taker wants to receive the total return of $10mm
worth of gold for one year at the current price of 1 oz of gold = $1100. Since
fiat assets cannot be transferred on the blockchain, the taker would like for all
the calculated terms to be in USD, but paid in ETH. Assume a maker agrees
to this in exchange for being paid 5% on $10mm for the length of contract.
(This would approximate the maker’s cost of borrowing the funds needed to
hedge their sale of gold with a small profit margin.) The economic terms of this
agreement would be:
Taker Receives = (pricecurrent /priceoriginal − 1) ∗ notional
(1)
= (goldprice /$1100 − 1) ∗ $10mm
If positive, the NPV is owed to the taker; if negative, it goes to the maker.
Because the NPV is calculated in USD, the maker or taker will have to pay
an amount of ETH equivalent to the NPV amount in USD (dividing the NPV
value by the ETHUSD rate).
The termination terms of the agreement are also recorded in the code of the
smart contract. These terms are purposefully designed to be flexible and up
to the mutual agreement of the counterparties. In most circumstances, the
termination terms would include:
12
• The expiry date of the contract, after which the contract would terminate
• The settlement procedure for expired contracts
• Required margin balances for both the maker and taker
• The default procedure if the required margin balances are not met
At the initial creation of the contract, both the maker and taker are required
to contribute, at a minimum, the required margin balance to their respective
13
margin accounts. Counterparties have an incentive to contribute more than this
minimum required balance since the contract will terminate under the default
procedure if the NPV of the contract causes either party’s margin balance to
drop below this minimum. As a further incentive to maintain sufficient margin,
counterparties can agree to a default penalty to be paid on top of the NPV to
any party that defaults. Although the contract cannot force a counterparty to
pay a default penalty in excess of the balance in their margin account, if the
required margin balance is set sufficiently above the default penalty amount
counterparties can be reasonably sure they will get paid this penalty out of
whatever funds remain in that margin account.
The margining terms of the contract are extremely flexible by design. Coun-
terparties would change these terms to match the projected volatility of under-
lying reference asset—more volatile contracts would require more margin. It is
also be possible to dynamically adjust the margin requirements by querying an
oracle for the historic or implied volatility of the underlying asset.
Early termination is an optional feature of the contract. If both parties agree
at the creation of the contract, the termination logic could include a mechanism
for either counterparty to request an early termination which may optionally
include an early termination fee.
14
their contracts, creating an advantage over less sophisticated counterparties who
may “forget” to remargin. Since anyone can call the remargin() function, this
can be solved by third party keepers that agree to monitor a less sophisticated
counterparty’s contracts for a small fee. Redundancy can further be introduced
into this system by using multiple margin custodians.
Assume Alice, a taker, wants to receive on the total return of $10mm of gold for
1 year vs paying a fixed interest rate. Based on the current volatility of gold,
Alice decides to set the minimum margin requirements at 5%, and sets a default
penalty of 3%. Note that although the notional exposure, margin requirements,
and default penalty are expressed in USD, all margin is paid and stored in ETH
equivalent to those USD amounts. Assume initial level of 1 oz of gold = 1100
and initial price of 1 ETH = $100.
Alice initializes an open contract and deposits 10k ETH (currently worth
$1mm).
Alice sends this open contract to two known market makers, Bob and Char-
lie. Both Bob and Charlie decide to “make a market” on this contract, and
both authorize the smart contract to withdraw 15,000 ETH (worth $1.5mm)
from their accounts and deposit into the contract’s maker margin account if
they win the trade (this more than satisfies the required margin of $500k).
Bob responds saying he will (i) pay the total return to Alice vs receiving
15
5%, or (ii) he will receive the total return from Alice vs paying 4.75%. Charlie
quotes a market of (i) paying the total return vs receiving 5.2% or (ii) receiving
the total return vs paying 4.9%. Both Bob and Charlie tell the smart contract
that they will hold their markets for 5 seconds (the wire time).
Since Alice wants to receive the total return of gold, she accepts Bob’s offer
to pay her the total return vs receiving 5%. (Alice would rather pay a fixed
rate of 5% to Bob than 5.2% to Charlie). The smart contract informs Bob he
is “done” on the trade and transfers the 15,000 ETH Bob already authorized
into his margin account within the smart contract. The contract also cancels
the margin withdraw authorization Charlie gave. The trade is confirmed and
the complete contract details are recorded on the blockchain.
Alice and Bob have now agreed to a contract where their promises to pay
each other are backed by ETH margin deposits in the smart contract.
The next day, gold rallies to 1 oz gold = 1, 199 while the price of ETH
16
remains unchanged. Off-chain, both Alice and Bob monitor and recalculate the
NPV of the contract and margin requirements. Since gold rallied 9% (from 1,100
to 1,199) and since one day of interest has passed (worth $1370), both Alice and
Bob calculate an NPV of $900,000 - $1,370 = $898,630 in Alice’s favor. Bob
knows that if the contract’s remargin() function is called on-chain, the smart
contract will move 8986.30 ETH (worth $898,630) from his margin subaccount
to Alice’s margin subaccount. As a result, his margin balance of $1.5mm will
be depleted by $898,630 and he will be dangerously close to dropping below the
minimum margin requirement (and risk paying the default penalty of $300k).
He therefore deposits an additional 10,000 ETH (worth $1mm) into his margin
account inside the smart contract.
Meanwhile, Alice decides that is it worth paying the gas to remargin the con-
tract on-chain. She calls the remargin() function and pays the necessary gas.
The remargin() function calls calcNPV() which queries the designated gold
price oracle and determines that the current NPV of the contract is $898,630
in Alice’s favor. The contract then moves 8986.30 ETH (worth $898,630) from
Bob’s margin account into Alice’s margin account. Alice’s margin account has
now changed from 10,000 ETH (at the start of the contract) to 18,986.30 ETH,
and Bob’s margin account has now changed from 25,000 ETH (after Bob de-
posited an additional 10,000 ETH) to 16,013.70 ETH (after 8986.30 ETH were
moved into Alice’s subaccount when remargin() was called on-chain).
As a last step, the smart contract checks that each of Alice and Bob’s margin
accounts have enough margin to meet the margin requirements. Alice and Bob
are able to observe this entire process since the margin balances of the contract
are publicly available. Alice sees that her margin account now contains 18,986.30
ETH (worth $1.899mm), leaving her over-collateralized by 13,986.30 ETH (or
$1.398mm) based on the $500k required margin amount. Alice could with-
draw this 13,986.30 ETH if she so chooses. Bob’s margin account now contains
16,013.70 ETH (worth $1.601mm), leaving him over-collateralized by 11,013.70
ETH (or $1.101mm) based on the $500k required margin amount. Since both
Alice and Bob’s margin account balances are above the margin requirement, the
17
contract remains valid.
The next day, while the price of gold remains unchanged, ETHUSD has
weakened from an initial price of 1 ETH = $100 to a price of 1 ETH = $80.
Bob sees that were Alice to call remargin(), he would still be owed $1370
of interest, but that the smart contract would query the oracle and see that
the value of ETH in USD terms had decreased. As a result, the oracle would
move 17.12 ETH (now worth $1370 = 17.12ETH × $80 ETHUSD) from Alice’s
account to Bob’s account, rather than 13.70 ETH. Note that in this contract,
even though the values of each of the payments, margin accounts, and margin
requirements are denominated in USD, the currency that is transferred to reflect
these changes is ETH. The amount of ETH that is transferred is calculated at
the time of transfer based upon the price of ETH in USD at the time.
The process continues with Alice and Bob continuously monitoring the NPV
of the contract as well as the margin balances. Since Alice is not a professional
market maker, she may also decide to hire a third party margin custodian or
keeper to monitor and remargin her contract according to certain parameters.
After one year, gold has rallied to 1 oz gold = $1320 and ETH has weakened
to 1 ETH = $80. On the day of termination, Alice calls remargin() a final
time. The final NPV is calculated as a total return of $2mm (the appreciation
of $10mm worth of gold from $1100 to $1320) less a fixed interest cost of $500k
(the 5% interest on $10mm), leaving a total of $1.5mm owed to Alice. This
amount corresponds to 18,750 ETH at a rate of 1ETH = $80. Assuming Alice
and Bob have maintained their margin requirements over the lifetime of the
contract, the cumulative margin movements between their accounts over the
year effected by the remargin() function result in a net increase of 18,750 ETH
in Alice’s account and a net decrease of 18,750 ETH in Bob’s account. The
terminate() function then returns any remaining margin in Alice and Bob’s
margin accounts to their respective public wallet addresses.
18
3.4 Example of Lifecycle with Default
Assume that the finalized contract between Alice and Bob as in Table 3 is
entered. The next day, gold rallies to 1 oz gold = $1221 while the price of
ETH remains unchanged at 1 ETH = $100. Off-chain, both Alice and Bob see
that if the contract’s remargin() function is called on-chain, the USD value
to be moved from Bob’s margin account to Alice’s is $1,100,000 - $1,370 =
$1,098,630, and so the smart contract will move 10,986.30 ETH from Bob’s
margin account into Alice’s. This would leave a remaining margin balance in
Bob’s margin account of 4,013.70 ETH (worth $401,370), which is below the
margin requirement of $500,000.
Bob sees this, and notes that while he would be in default if the contract
were to be remargined, if ETH were to rally from 1ETH = $100 to 1ETH = $125
and the price of gold were to remain unchanged, his 4,013.70 ETH would be
worth $500k and he would not be in default if the contract were remargined.
He chooses to wait, hoping that the value of ETH/USD will change before the
contract is remargined.
Alice, however, wishes to remargin the contract so that she can withdraw
some of the resulting excess margin in her account. After she calls the remargin()
function, the smart contract moves the corresponding ETH from Bob’s margin
account into Alice’s.
After moving the margin, the smart contract runs the terminate() function
to confirm that the margin balances still meet margin requirements and handle
default. Seeing that Bob’s margin balance is below the margin requirements,
the smart contract pays the default penalty of 3,000 ETH (worth $300k) from
Bob to Alice and returns the remaining margin balances to Alice and Bob’s
respective public addresses, closing the contract.
In hindsight, Bob would have been better off depositing an additional ˜1,000
ETH into his margin account to meet the margin requirement than paying the
3,000 ETH default penalty for not having met the margin requirement.
19
Figure 7: Default penalty is paid and contract is closed
4 Implementation Mechanisms
The UMA Protocol as demonstrated in the bilateral swap example enables coun-
terparties to trade with leverage, but may not be the desired way of interacting
with counterparties for many individuals. UMA contracts can be used as a mech-
anism by which counterparties can become makers or takers of risk for many
different kinds of individuals. To meet the needs of these diverse individuals,
we expect counterparties to develop a variety of use cases, or implementation
mechanisms for UMA contracts.
20
These features are generally desirable to smaller or less sophisticated in-
vestors, who need not be concerned with depositing additional margin, default-
ing, or checking the calendar to see if the exposure is maturing. They also have
the peace of mind of knowing at all times what their maximum loss is. This is
achieved by removing the leverage from Alice’s position, as she has to deposit
the full amount of her exposure ($10mm worth of ETH) and will never owe Bob
any additional margin. As a result, Alice’s margin account balance will always
be ≥ 0, so the margin account can be tokenized. In return for depositing $10mm
worth of ETH, Alice receives tokens representing a claim on the value of her de-
posit. As shown in Figure 8, this trustless tokenization is an extension of the
original bilateral swap example as described in subsubsection 3.3.1 and shown
in Figure 3, where Alice’s margin account is fully collateralized and the value of
the margin in the account is converted into tokens. This diagram assumes that
1 ETH = $100 and that Bob initially deposits a 15% margin.
Ownership in these tokens can be further fractionalized, and Alice can dis-
tribute ownership via the existing infrastructure to support trading and custody
of ERC-20 tokens. Suppose, for example, that Alice knows many other individ-
uals in her community who also want to gain long exposure to gold, but who
cannot buy physical gold or traditional financial products that reflect the price
of gold. Alice may know that Bob is an experienced swap trader who already has
dedicated resources to watching the market and maintaining margin positions,
and who is comfortable trading gold products in the fiat world as well. Alice
may enter an agreement with Bob where Alice is responsible for sourcing inter-
est from investors for this token, Bob is responsible for providing the long gold
exposure, and they enter an UMA contract representing the long gold exposure.
Bob may not want to hold the long gold exposure himself, and may offset this
risk in the fiat world with gold futures or gold swaps in the traditional financial
market (the cloud in Figure 8). For this service, Bob may charge an annualized
fee of 5%, but pay Alice a portion of that fee, say 1%. If Alice and Bob work
well together, they may even formalize this partnership and begin operating as
one entity.
21
5 Potential Issues and Risks
22
transactions falls far short of what is achievable with centralized exchanges. The
UMA Protocol sidesteps this by putting the responsibility for monitoring and
remargining contracts in the hands of the counterparties, where off-chain mon-
itoring costs are minimal. Oracles only need to be called on-chain when either
counterparty decides to run the contract’s remargin() function on-chain.
6 Future Work
23
1. The taker initializes a UMA smart contract with the terms of the agree-
ment they are looking to enter (specifying the expiry date, notional, eco-
nomic formula, termination terms, and other required terms). The taker
does not specify which direction they want to go (i.e. long or short the
underlying asset).
2. The taker transfers the minimum margin required into the empty contract.
3. The taker selects one or more market makers and sends them the incom-
plete contract.
4. Makers respond with two-way quotes on the contract (they do not know
the direction of the trade). Makers also authorize the smart contract to
withdraw that minimum margin required if the trade is confirmed. The
quotes and margin authorizations expire after a short amount of time,
known as the wire time.
5. The taker selects the quote that is most favorable for the direction they
want to go and confirms the trade with that maker before the wire time
expires. After confirming the trade the maker owns the risk and decides
if, how, and when to hedge.
6. The smart contract withdraws the authorized margin from the winning
maker and deauthorizes any margin authorizations from losing quotes.
All details are immutably recorded on the blockchain.
24
6.3 Future Proofing: Currency and Blockchain Agnostic
Approach
Althought the UMA Protocol is currently implemented using the Ethereum
blockchain with Ether (ETH) as a common currency for all margin transfers
and settlement payments, the specification is designed to be blockchain and
currency agnostic. The protocol is easily portable to other blockchains, and
it is our expectation that market participants will identify the blockchain most
compatible with best practices, standards, and incentive mechanisms. This sup-
ports our vision of a single, unified global marketplace, supported by a common,
unified, protocol.
7 Conclusion
The UMA Protocol is a decentralized specification to enable the trustless trans-
fer of financial risk for any underlying asset to any individual around the world.
The protocol uses novel systems and economic incentivies to transparently and
efficiently maintain collateral and accurately settle transactions while giving
users complete control over the terms of their economic exposure. Combined,
these properties enable and empower individuals to transfer financial risk, re-
gardless of geographic location.
References
[1] Ethereum: A Next-Generation Smart Contract and Decentralized Appli-
cation Platform
https://github.com/ethereum/wiki/wiki/White-Paper
[2] OTC derivatives statistics at end-June 2017
https://www.bis.org/publ/otc hy1711.htm
[3] A. Bomfim, Understanding Credit Derivatives and Related Instruments.
UK: Elsevier, 2004, ch. 7.
[4] TrustToken project website.
https://www.trusttoken.com
25
[7] V. Buterin, SchellingCoin: A Minimal-Trust Universal Data Feed, 2014.
https://blog.ethereum.org
/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/
[8] F. Zhang et al, Town Crier: An Authenticated Data Feed for Smart Con-
tracts, 2016.
https://eprint.iacr.org/2016/168.pdf
[9] TLSnotary - a mechanism for independently audited https sessions, 2014.
https://tlsnotary.org/TLSNotary.pdf
[10] R. Brodetski, Introducing Oracul: Decentralized Oracle Data Feed Solu-
tion for Ethereum, 2017.
https://medium.com/@roman.brodetski/introducing-oracul-decentralized-
oracle-data-feed-solution-for-ethereum-5cab1ca8bb64
[11] Securities Industry and Financial Markets Association Website.
https://www.sifma.org/about/
26