margincall
liquidates a position for given position\_id
position\_id (type int64)
the id of the position to liquidate.
When position\_id does not exist.
When for given position\_id ltv\_ratio > critical\_ltv ratio - it can’t liquidate a good position.
When there are no positions to liquidate. (No entries in ltvratios table with ltv\_ratio below critical for current price).
| `cleos push action eosdtcntract margincall '{"position_id": "30"}' -p user` | |margincalpos
liquidates multiple positions by sorting the ltvratios table in order of ascending ltv\_ratio.
N/A
margincalldeffer
an internal method that gets called when the oracle service calls our contract with a rates update. If there are positions to be liquidated, deferred margin calls will be created and positions will be liquidated in the next blockchain transaction.
N/A
deposit
deposit EOS to the eosdtlevrage contract, specifying desired leverage L and safety margin (SM)
leverage(L)
safety\_margin(SM)
When missing signature of caller.
When L 1/(1- 1/(critical\_ltv + safety\_margin).
When SM= critical\_ltv.
When there is not enough liquidity on DEX on any of the loop iterations.
| `cleos push action eosdtcntract margincall '{"leverage": "2",”safety_margin”,”0.3”}' -p user` | # Delta hedging using EOSDT A trader is often interested in acquiring a put option on his or her portfolio. This provides protection against market declines while preserving the potential for a gain if the market does well. One way to do it is to create a synthetic put option on the portfolio by maintaining a position in the underlying asset (or portfolio) so that the delta of the position equals the delta of the required put option. In traditional financial markets, there are two reasons why it may be more attractive for the portfolio holder to create the required put option synthetically than to buy it on the market. First, options markets do not always have the liquidity to absorb the trades required by large fund managers. Second, fund managers often require strike prices and exercise dates that are different from those available in exchange-traded options markets. In the realm of blockchain there aren’t any mature options or futures markets that currently allow for hedging strategies, so the only way to hedge one’s portfolio is to actually trade it against a “risk-free” asset, by hedging into it at times of market decline and hedging out of it when markets grow. This is where the synthetic option approach outlined above comes into play. Here’s how the Equilibrium-based system tackles user portfolio hedging with help from EOSDT: 1. Users stake their portfolios to a separate hedging contract. 2. This contract listens to price changes from the oracle and reacts to them if necessary. 3. Users specify their hedge period and desired drawdown. 4. The system monitors the portfolio value: * As the value of the original portfolio declines, the delta of the put option becomes more negative and the proportion of the original portfolio sold must be increased. * As the value of the original portfolio increases, the delta of the put option becomes less negative and the proportion of the original portfolio sold must be decreased. ## **Example:** A portfolio is worth $50,000. To protect against market downturns, the portfolio owner requires a six-month put option on the portfolio with a strike price of $45,000. The risk-free interest rate is 1% and the volatility of the portfolio is 25% per annum. We’re given all the data to create the required option synthetically: Calculate: `d = ln(S_0/K) + (R + sigma^2/2)*T / [sigma * sqrt(T)]` where: * `S_0` - initial value of the portfolio = $50,000 * `K` - strike price = $45,000 * `R` - risk free interest rate = 1% (this is a current cost of EOSDT generation in Equilibrium) * `Sigma` - annualized portfolio volatility = 25%. * `T` - hedging period, T = 0.5 years (6 month). `d = ln(50/45) + (0.01 + 0.25^2/2)*0.5 / [0.25 * sqrt(0.5)] ~ 0.7127` And the delta of the required option is: `delta = N(d) - 1`, where `N(d)` is the standard normal cumulative distribution function for a specified value `delta = N(0.7127) - 1 = - 0.2380` This delta value shows that 23.8% of the portfolio should be sold initially and invested in EOSDT to match the delta of the required option. The amount of the portfolio sold must be monitored frequently. For example, if the value of the portfolio reduces to $47,000 after one day, the delta of the required option changes to -0.3584 and further 12.04% of the original portfolio should be sold and invested in EOSDT. If the value of the portfolio increases to $53,000, the delta of the required option changes to -0.1486 and 8.94% of the original portfolio should be repurchased. # EOSDT lending and borrowing pool Basic design and development of financial applications calls for there to be mechanisms like money markets and the ability to lend or borrow stablecoins at some “risk-free” interest rate. The efficiency and liquidity of these decentralized money markets may then be used to build various derivative instruments on top of existing infrastructure. For example, contracts like futures and forwards derive their prices from the “no arbitrage” argument, so their on-chain existence and viability directly depends on the assumption that market participants can borrow money at the same risk-free interest rate as they can lend money. The Equilibrium framework has a separate protocol in place that establishes money markets on the EOS blockchain. These money markets are pools of assets with algorithmically derived interest rates based on the supply and demand of an asset. Asset lenders and borrowers interact directly with the protocol, earning (and paying) a floating interest rate without having to negotiate terms like maturity, interest rate, or collateral with a peer or other third party. Equilibrium currently operates an EOSDT pool where users may lend or borrow EOSDT stablecoins. The smart contract is available for public use, and any user or organization may use it to provide on-chain liquidity in their token of choice. ## **Key points** 1. The eosdtlbpools smart contract is an EOSDT pool where lenders and borrowers can interact with each other. Lenders post EOSDT, borrowers post collateral and are able to borrow EOSDT. 2. Interest rates are calculated using continuous compounding and reinit() logic, similar to the main positions contract: accrued interest rates are recalculated whenever there’s some interaction with the smartcontract. 3. Interest rates are determined by the supply and demand of the underlying asset. When demand to borrow an asset grows (or when supply is removed) interest rates increase to incentivize additional liquidity. 4. Interest rates are floating, so every time the supply/demand changes, each loan will be subject to a new interest rate. 5. Borrowers pay interest on their loan from the collateral securing the loan. 6. Borrowers may supply several collateral tokens to borrow EOSDT, each with its specific LTV ratio. Initially Equilibrium supports following tokens for collateral EOS, CHEX, DAPP, PEOS, NUT. New collateral tokens may be added via governance. 7. Lenders earn an implicit interest rate based on actual borrowing utilization. 8. Borrowing interest rate model: `r = r0 + total borrowed / (total borrowed + total supply) * rX` * `r0` - base interest rate when there are no borrowers. r0 equals to Equilibrium fee + Admin fee. * `Total borrowed` - total amount of EOSDT that has been borrowed from the fund so far. * `Total supply` - total amount of EOSDT available for borrowing (this number doesn’t change when users borrow, and only changes when lenders deposit or withdraw money). * `rX` - slope, which defines the terminal interest rate when all of the supply has been borrowed. * `r0`, `rX` are available to be set and changed via Equilibrium governance. ## **Primary use-cases** ### Lending Individuals with long-term investments in EOS and tokens can use the Equilibrium money market as a source of additional returns on their investment. For example, a user who owns EOS can give their tokens to the eosdtlbpools contract and earn interest (in EOS) without having to manage the asset, fulfill loan requests, or take speculative risks. ### Borrowing Traders looking to short a token can borrow it, send it to an exchange, and sell the token. This series of action sees traders profit from declines in overvalued tokens. DApps may borrow tokens for use in the EOS ecosystem, like using the governance functions of Equilibrium’s NUT token, or subscribing to Liquid Apps DSP with DAPP tokens. # Trading {% content-ref url="/pages/-Lu2iJIiMXQnc89qashb" %} [Exchange contract and EOSDT liquidity](/tools-and-products/trading/exchange-contract-and-eosdt-liquidity) {% endcontent-ref %} # Exchange contract and EOSDT liquidity An integral part of the Equilibrium stablecoin system is the incentivization of external agents called guardians. We’ve already covered on-chain guardian contracts in detail here. These external actors require liquidity in order to quickly obtain collateral from the liquidator smart contract and sell it at a profit. So we’ve developed an on-chain liquidity contract to offer them this opportunity. The equiexchange contract is really simple under the hood. It currently supports two trading pairs: EOS/EOSDT and NUT/EOS. These trading pairs are always quoted in reference to the current price from the rates contract. Interactions with the exchange contract are very simple: there are two transfers, buy and sell. Both require a pair\_id and quantity. That's it! Here are the buy and sell examples: `Buy: $ ./cleos transfer testtesttest equiexchange "3.000000000 EOSDT" '{"pair_id":1}'`\ `Sell: $ ./cleos transfer testtesttest equiexchange "1.0000 EOS" '{"pair_id":1}'` Guardians can integrate this functionality into their code to buy out liquidated collateral and sell it to the exchange in a single transaction. We aim to eventually make the equiexchange contract into a fully-functional on-chain decentralized exchange. It won’t be the kind of DEX you’ve seen in EOS so far, but will be one with a simple and understandable API to support lending, borrowing, margining, and smart order-types. ## **On-chain EOSDT liquidity** EOSDT is currently available for trade on the following EOS-based services: * [**Newdex**](https://newdex.io/trade/eosio.token-eos-eosdt) * [**Findex**](https://findex.pro/trade/eosdtsttoken_EOSDT-eosio.token_EOS) * [**YOLO**](https://yoloswap.com/swap/eos-eosdt) * [**Bancor**](https://www.bancor.network/token/EOSDT) Users can trade EOSDT against EOS on any of the DEXes or connectors specified above. There are interesting arbitrage opportunities here, especially if one considers arbitraging Bancor or Yolo against Newdex, or against our equiexchange contract. Both Bancor and Yolo provide a form of algorithmic liquidity. Bancor follows a concave utility-like function, and the price inside its connector depends on actual connector balances. YOLO offers an exponential liquidity based on the amount of EOS supplied to it. Both connectors have their operational specifics, but arbitraging them is pretty simple: as soon as you see that EOS/EOSDT price deviates either in Bancor or in Yolo enough to cover your trading fees and spreads on Newdex, you make a trade. # Integrations and Payments {% content-ref url="/pages/-Lu2iJIk6zkI05hnofRP" %} [Referral program and widget](/tools-and-products/integrations-and-payments/referral-program-and-widget) {% endcontent-ref %} # Referral program and widget This is an additional piece of logic on eosdtcntract that allows for integrating EOSDT generation into your own web application or dApp — 50% of all NUT-based fees will be paid by stablecoin users. Users must pay an admin fee in Equilibrium’s NUT in order to close an EOSDT position, and the referral program simply splits this fee in half — 50% of NUT tokens get burned, 50% goes to the referral partner. Those who want to participate need to register on EOSDT’s smart contracts in order to make sure they can get paid. This only requires a separate NUT transfer to our smart contracts, granting partners a referral ID. *\*\**There are new settings related to the referral program: | **parameter** | **type** | **description** | | -------------------- | ------------ | ----------------------------------------------------------------------------------- | | referral\_min\_stake | asset *\*\** | The minimum NUT stake required to register as a referral. This is 2 NUT by default. | | referral\_ratio | float | The ratio of admin fees that go to referrals as a reward. By default this is 50%. | **\*\*New table** ctrreferrals\*\*: This table lists all the referrals with their respective staked amounts of NUT. | **parameter** | **type** | **description** | | -------------- | -------- | --------------------- | | referral\_id | int | referral id | | referral | name | referral account name | | staked\_amount | asset | amount of NUT staked | New table **positionrefs**:\ This table connects positions with referrals so the system knows when and where to pay the fees. | **parameter** | **type** | **description** | | ------------- | -------- | -------------------------- | | referral\_id | int | referral id | | position\_id | int | Id of the related position | *\*\**New actions related to referral program: {% tabs %} {% tab title="referraladd" %} **Action** deposit NUT to the **eosdtcntract**, specifying referral in memo. **Parameters** NUT amount\ memo: referral **Rejections** When input < referral\_min\_stake *\*\**When missing the referral’s signature **Example** ``` cleos transfer ‘{“from”:“testtesttest",“to”:“eosdtcntract”,“quantity”:“2.000000000 NUT”,“memo”:“referral"}’ ``` {% endtab %} {% tab title="referraldel" %} **Action** withdraw NUT from the smart contract and delete the referral account name from the table. **Parameters** referral\_id **Rejections** When missing the referral’s signature for a given referral\_id *\*\**When the referral doesn’t exist in the referrals table (can’t find referral by id) **Example** ``` cleos push action eosdtcntract referraldel '{"referral_id": "2"}' -p user ``` {% endtab %} {% tab title="posandrefadd" %} **Action** Create an empty position entity and set the caller to be the owner. **Parameters** referral\_id **Rejections** When missing referral\_id *\*\**When the referral doesn’t exist in the referrals table (can’t find referral by id) **Example** ``` cleos push action eosdtcntract posandrefadd '{"referral_id": "2"}' -p user ``` {% endtab %} {% endtabs %} For frontend integrations you can use our widget, which has configurable color schemes (Check [here](https://partner.eosdt.com/en)). The widget comes in different forms and may be installed via npm, CDN, or IFrame. Check the [widget repo](https://github.com/equilibrium-eosdt/widget) for additional details. # EOSDT JS A JavaScript library to execute EOSDT contracts methods. ## Usage Install the module using NPM: ```bash $ npm install @eosdt/eosdt-js ``` Use service module `Connector` to initiate one of four functional modules (`Positions`, `Governance`, `Liquidator` or `Balances`). `Connector` uses EOS node address and an array of private keys. Transactions would be signed with given keys and sent to blockchain through given node. ```javascript const { EosdtConnector } = require("@eosdt/eosdt-js") const nodeAddress = "http://node-address.example.com:80" const connector = new EosdtConnector(nodeAddress, ["private-key-1", "private-key-2"]) const positions = connector.getPositions() const governance = connector.getGovernance() const liquidator = connector.getLiquidator() const balances = connector.getBalances() ``` ## Modules ### Connector Creates a connector object, used to initiate functional modules and invoke their methods. ### Positions Module to manage EOSDT positions. Methods: * `create` - creates new position, using specified amount of EOS as collateral and issuing specified amount of EOSDT to creator. If `eosAmount` arg is equal to zero, creates an empty position. * `createWithReferral` - same as `create`, but also sets a referral on position. * `close` - used to close a position in event of a global shutdown. * `del` - deletes position that has 0 debt. * `give` - transfers position ownership to another account. * `addCollateral` - sends EOS to position to increase it's collateralization. * `deleteCollateral` - returns specified part of used collateral to user if LTV stays above critical. * `generateDebt` - issues additional EOSDT for position if this does not bring LTV below critical. * `burnbackDebt` - repays specified amount of EOSDT decreasing debt. * `marginCall` - called on a position with critical LTV, to perform a margin call. * `getContractEosAmount` - returns eosdtcntract EOS balance * `getRates` - returns table of current system token prices (rates). * `getPositionById` - returns a position object, selecting it by id. * `getAllUserPositions` - returns an array of all positions for specified user (up to 100 positions). * `getParameters` - returns Positions contract parameters. * `getSettings` - return Positions contract settings. * `addReferral` - creates new referral, staking given amount of NUT. Rejects when amount is less then `referral_min_stake` in positions contract settings. * `deleteReferral` - removes referral and unstakes that referral's NUT. * `getReferralById` - returns a referral object. * `getReferralByName` - returns a referral object. * `getAllReferrals` - returns table of existing referrals. * `getPositionReferral` - returns referral of a given position (`undefined` if none exists). * `getPositionReferralsTable` - returns an array of positions ids and those positions referrals. * `getAllReferralPositionsIds` - returns an array of positions with given referral id. ### Governance Governance methods help manage the system: create proposals to change system parameters, vote on them and stake NUT tokens for voting. Methods: * `propose` - creates a proposal. * `expire` - expires an active proposal. * `applyChanges` - apply proposed changes (at least 51% of all issued NUT tokens must vote, at least 55% of votes must be positive). * `cleanProposal` - remove specified amount of votes from an expired proposal. If 0 votes left, removes proposal. * `stake` - sends NUT tokens to contract, staking them and allowing to vote on proposals. * `unstake` - unstakes NUT tokens, returning them to user and lowering amount of available votes. * `vote` - vote for or against a proposal. Vote `1` as "yes", `0` or any other number as "no". * `unvote` - removes all user votes from a proposal. * `voteForBlockProducers` - voting with staked NUTs for specified block producers. * `stakeAndVoteForBlockProducers` - stakes NUT and votes for BPs in one transaction. * `getVoterInfo` - returns amount of NUTs staked by account in EOSDT Governance contract and their unstake date. * `getVoterInfosTable` - returns the whole table of information on accounts that staked NUT * `getVotes` - returns an array with all votes (up to 1000). * `getProposals` - returns an array with all proposals (up to 1000). * `getBpVotes` - returns array of block producers names and amount of NUT votes for them. * `getProxyInfo` - returns voter info for `eosdtbpproxy`. * `getSettings` - returns governance contract settings. ### Bp manager Governance account methods for block producers to manage their voting positions: register, change reward amount, deposit EOS, unregister. * `getBpPosition` - returns information about registered block producer. * `getAllBpPositions` - returns an array of objects, that contain information about registered block producers. * `registerBlockProducer` - registers a block producer in BP voting reward program. * `changeBlockProducerReward` - changes amount of EOS reward payed out by block producer. * `unRegisterBlockProducer` - make block producer position inactive. * `depositEos` - deposit EOS to block producer position. ### Liquidator Methods to get Liquidator contract parameters and exchange EOS and EOSDT in case of global shutdown. * `marginCallAndBuyoutEos` - performes margin call on a position and transfers specified amount of EOSDT to buyout freed EOS. * `transferEos` - sends EOS to Liquidator contract. It is used to buyout surplus debt with discount. * `transferEosdt` - sends EOSDT to liquidator contract. It is used to cancel bad debt and buyout liquidator EOS with discount. * `transferNut` - sends NUT tokens to liquidator contract. It is used to buyout EOS intended to be bought for NUT tokens (parameter "nut\_collat\_balance"). * `getSurplusDebt` - returns amount of system surplus debt. * `getBadDebt` - returns amount of system bad debt. * `getEosBalance` - returns amount of EOS on liquidator contract balance. * `getParameters` - returns all liquidator contract parameters. ### Balances Module to get account's balances of EOSDT, EOS and NUT. Methods: * `getNut` - returns NUT balance of account * `getEosdt` - returns EOSDT balance of account * `getEos` - returns EOS balance of account ## Examples You can find working example scripts in module directory `examples`. ### Connecting to blockchain This code block is required for any other example to work. ```javascript const { EosdtConnector } = require("@eosdt/eosdt-js") // Change node address here. This one will connect you to Jungle testnet node const nodeAddress = "http://jungle2.cryptolions.io:80" // Change or add private keys used to sign transactions here. This one is from Jungle // testnet account "exampleaccnt" const privateKeys = ["5JEVy6QujTsFzxWtBbQrG53vkszRybabE4wSyA2Tg1uZFEeVPks"] const accountName = "exampleaccnt" const connector = new EosdtConnector(nodeAddress, privateKeys) // This code logs current block number and lets us know that connection // has been established. const currentBlockNumber = (await connector.rpc.get_info()).head_block_num console.log(`Connected to blockchain, current block number is: ${currentBlockNumber}`) // Getting objects with all methods const positions = connector.getPositions() const governance = connector.getGovernance() const liquidator = connector.getLiquidator() const balances = connector.getBalances() ``` ### Position operations Creating position, adding collateral, issuing addintional debt then returning it, returning collateral from postion and closing it. ```javascript // Creating a position to issue 2 EOSDT for 1.5 EOS collateral // ATTENTION: this will throw if a user already has a position await positions.create(accountName, 1.5, 2) // Getting last user position const allUserPositions = await positions.getAllUserPositions(accountName) const lastUserPosition = allUserPositions[allUserPositions.length - 1] const positionId = lastUserPosition.position_id console.log("Position created:", lastUserPosition) // Adding 1.6 EOS collateral to position await positions.addCollateral(accountName, 1.6, positionId) let updatedPosition = await positions.getPositionById(positionId) console.log("Position collateral increased: ", updatedPosition) // Issuing addintional 2.15 EOSDT of debt await positions.generateDebt(accountName, 2.15, positionId) updatedPosition = await positions.getPositionById(positionId) console.log("Position outstanding and governance debts increased: ", updatedPosition) // Returning 6 EOSDT to Positions contract. All excessive tokens will be returned to // user. Appropriate amount of NUT tokens will be withdrawn from user balance. User // required to have NUT tokens to burn debt. await positions.burnbackDebt(accountName, 6, positionId) updatedPosition = await positions.getPositionById(positionId) console.log("Position debt decreased: ", updatedPosition) // Returning 1.35 EOS of collateral to user (partial collateral return). If there is // debt still left, user cannot return more collateral than required for position // to have LTV above critical await positions.deleteCollateral(accountName, 1.35, positionId) updatedPosition = await positions.getPositionById(positionId) console.log("Position collateral decreased: ", updatedPosition) // Deleting position and returning all collateral to user. Would only work, if // position has zero debts. await positions.del(accountName, positionId) updatedPosition = await positions.getPositionById(positionId) console.log("Position deleted, excess EOS returned to user, position must now be undefined: ", updatedPosition) ``` ### Proposals management Creating, expiring and applying a proposal. ```javascript const proposalJson = `{"eosdtcntract.critical_ltv":1.4,"eosdtcntract.stability_fee":0.086,"reserved":"Update production contracts to v2.1"}` const expirationDate = "2019-06-30T23:59:59" // Creating a proposal for users to vote await governance.propose("test proposal", "Test proposal title", proposalJson, expirationDate, accountName) // Logging all proposals console.log(`Proposal created: \n`, await governance.getProposals()) // Expiring a proposal and stooping voting on it. Expiration date changes to // time of this method execution. await governance.expire("test proposal", accountName) console.log(`Proposal expired: \n`, await governance.getProposals()) // If your proposal is expired, has 55% "yes" votes and 51% of all NUT tokens // voted - you can apply changes from this proposal to system await governance.applyChanges("test proposal", accountName) ``` ### Voting Staking NUT tokens to vote for and against proposals. ```javascript // Transfering 2 NUT tokens to use them in voting. Tokens can be unstaked and // transferred back after 3 days wait period (votes, using these tokens must be // cancelled first) await governance.stake(accountName, 2) // Voting whith 2 NUT tokens for proposal with name "test proposal". Vote "1" for // proposal and any other number to vote against it. You vote with all staked tokens await governance.vote("test proposal", 1, accountName) console.log(`Voted successfully, all votes: \n`, await governance.getVotes()) // Cancelling vote for proposal with name "test proposal" await governance.unvote("test proposal", accountName) console.log(`Voted cancelled, all votes: \n`, await governance.getVotes()) // Unstaking NUT tokens to get them back on user's balance await governance.unstake(2, accountName) ``` ### Balances operations Gettings balances of EOS, EOSDT or NUT ```javascript // Getting amount of EOS available on user's balance await balances.getEos(accountName) ``` # Fees and flows Since the launch of Equilibrium’s EOSDT stablecoin project earlier this year, the framework has naturally grown around it. The fees and fee logic have grown as well, and have become too cumbersome to understand. This article will structure all the fees and fund flows that currently exist inside the Equilibrium framework.\ The main takeaway is that all fees within the Equilibrium framework are one way or another related to the NUT utility token, because this is where NUT derives its value. Apart from fees, there are other flows of funds in the system related to EOS’s DPoS architecture. We will break down all these flows here with numerical examples. {% tabs %} {% tab title="Equilibrium fee" %} **Description** Position holders may be incentivized to sell or expand their EOSDT holdings with the Equilibrium fee. The framework applies the Equilibrium fee every time a user takes an action and calculates this fee based on an annual percentage rate, defined by Equilibrium’s governance smart contract. At the launch of the framework, the Equilibrium fee will be set to 0% APR. If there’s an excess market supply of EOSDT, governance may decide to raise the applicable fee to induce position holders to sell off their “expensive” positions, lowering the supply of stablecoins. If there’s excess demand for EOSDT, governance may lower the interest rate to induce users to enter more “cheap” positions, increasing the total supply. This is reminiscent of how central banks adjust short-term interest rates to control the economy’s supply of money. **Where to look?** [**eosdtcntract.ctrsettings.stability\_fee**](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) {% endtab %} {% tab title="Admin fee" %} **Description** This fee is set to 1% per year by default, payable in NUT tokens. This fee is due when users wind down their EOSDT positions, and it’s proportional to the amount of EOSDT being repaid. Equilibrium partners may collect 50% of this fee through a referral program. The actual percentage depends on the [referral\_ratio](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) parameter. **Where to look?** [**eosdtcntract.ctrsettings.governance\_fee**](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) {% endtab %} {% endtabs %} There are three main mechanisms so far that benefit both collateral holders and NUT token holders inside Equilibrium. Let’s briefly touch on the mechanics of each one of these revenue streams, and then consider numerical examples which would further clarify things. ## **Penalty from liquidating undercollateralized positions.** When any position becomes undercollateralized (the value of its collateral falls below 130% of its generated EOSDT value) it is subject to liquidation and will be stripped of a [liquidation\_penalty](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) fee. It's worth considering a numerical example now. Let’s assume I have a position with 100 EOSDT generated, the EOS price is $5 USD, and I have pledged 26 EOS in total. The Collateralization Ratio for my position will be: CR = EOS collateral \* EOS price / EOSDT generated = 5 \* 26 / 100 = 1.3 = 130% — so it is subject to liquidation. When liquidated, I will pay: EOSDT generated \* (1 + liquidation\_penalty) / EOS price = 23 EOS. I will be left with my 100 EOSDT and 3 extra EOS sitting on my empty position. In the meantime, the liquidator contract will have the following state: bad\_debt = 100 EOSDT\ eos\_balance = 23 EOS\ nut\_collat\_balance = 0 EOS Now any willing user can come to the liquidator contract, bring EOSDT to “burn” bad\_debt, and receive EOS from eos\_balance in return. This is called a collateral auction. To incentivize people to participate in this auction, there is a [eosdtcntract.ctrsettings.liquidator\_dicount](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) of 3% off current [prices on the rates contract](https://bloks.io/account/eosdtorclize?loadContract=true\&tab=Tables\&account=eosdtorclize\&scope=eosdtorclize\&limit=100\&table=orarates). Let’s assume I’m one of these willing users: I bring in 100 EOSDT and get back:\ EOSDT\_in / (EOS price \* (1 - liquidator\_discount) = 100 / (5 \* (1 - 0.03)) = 20.6186 EOS. After I buy out all the bad\_debt from the liquidator contract, it will have the following state: bad\_debt = 0 EOSDT\ eos\_balance = 2.3814 EOS\ nut\_collat\_balance = 0 EOS Now the system has no “bad\_debt”, so eos\_balance can be distributed among collateral holders and NUT token holders. The proportion is governed by the [nut\_auct\_ratio](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100\&table=ctrsettings) parameter. 2.3814 \* (1 - nut\_collat\_balance) = 2.0956 EOS will be transferred to the positions contract and distributed among collateral holders, and the liquidator contract will have the following state: bad\_debt = 0 EOSDT\ eos\_balance = 0.2858 EOS\ nut\_collat\_balance = 0.2858 EOS Notice that system updated nut\_collat\_balance. This happened because bad\_debt went to zero, the system returned part of the profit back to its position holders, and is now ready to distribute profits to NUT holders. Now any willing user may come to liquidator contract and bring in NUT tokens to buy out this excess EOS. To incentivize people to participate in this auction, there is a [eosdtcntract.ctrsettings.nut\_dicount](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) of 6% off current [prices on the rates contract](https://bloks.io/account/eosdtorclize?loadContract=true\&tab=Tables\&account=eosdtorclize\&scope=eosdtorclize\&limit=100\&table=orarates) for this excess EOS. Let’s assume I’m one of these willing users. I should bring nut\_collat\_balance \* EOS/NUT price \* (1 - nut\_discount) = 0.2858 \* 0.2 \* (1 - 0.06) = 0.0537 NUT (we’re assuming EOS/NUT price is 0.2) to buy all of this EOS. I have obtained 0.2858 EOS and the liquidator contract has 0.0537 NUT. 10% of this NUT will be burned, and the remaining 90% will be transferred to the [governance contract](https://bloks.io/account/eosdtgovernc). The 10% and 90% weights are liquidator contract settings: [eosdtliqdatr.liqsettings.burn\_rate](https://bloks.io/account/eosdtliqdatr?loadContract=true\&tab=Tables\&account=eosdtliqdatr\&scope=eosdtliqdatr\&limit=100\&table=liqsettings) and [eosdtliqdatr.liqsettings.gov\_return\_rate](https://bloks.io/account/eosdtliqdatr?loadContract=true\&tab=Tables\&account=eosdtliqdatr\&scope=eosdtliqdatr\&limit=100\&table=liqsettings) One additional thing is worth mentioning here: if liquidation took place and there are no users willing to participate in a collateral auction on the liquidator contract, then it may happen that EOS price continues to fall. At some point there won’t be enough EOS to cover all the “bad debt” on the liquidator contract. In this case the system will be punishing all the collateral holders by taking a fraction of the total collateral to cover the shortage. If we return to our earlier example with 23 EOS and 100 EOSDT bad\_debt sitting on the liquidator contract, this will happen when EOS price falls from 5 USD to 100/23 = 4.3478 USD and below. Astute readers may conclude that the break-even drop in EOS price depends on **liquidation\_penalty** and **liquidator\_discount** parameters. Here’s the table that calculates the break-even percentage drops for EOS price.\ Current parameter settings are marked in green. “Prohibitive” settings are marked in red.\ The system allows for \~10% drop before we start tapping into everyone’s collateral. Given EOS’s price volatility of around 8% a day, a drop of this magnitude is expected to occur in at least 4 hours in more than 99% of cases. Given that the EOS rate is updated every minute by an oracle contract and we’re expecting to increase this to every 15 seconds, we’ll eventually have a high margin of safety here. .png?generation=1574787235605330\&alt=media) ## **REX profit** The EOSDT contract stakes all of the user collateral collectively to REX and earns profit in the form of REX price appreciation. Currently, eosdtcntract is the [biggest REX lender](https://eosauthority.com/rex/statistics?network=eos). Profit from REX is calculated and taken out every [eosdtcntract.ctrsettings.stake\_period ](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100) A fraction of this profit, controlled by the [profit\_factor](https://bloks.io/account/eosdtcntract?loadContract=true\&tab=Tables\&account=eosdtcntract\&scope=eosdtcntract\&limit=100\&table=ctrsettings) parameter, goes to the liquidator contract and updates the nut\_collat\_balance (given that there is no bad\_debt there). The rest is returned straight to the positions contract and collateral holders. For example, if REX earned 300 EOS profit over the past 5 days, then: Collateral holders will collectively receive: 300 \* (1 - profit\_factor) = 264 EOS Liquidator will have the following state given the absence of bad debt: bad\_debt = 0 EOSDT\ eos\_balance = 36 EOS\ nut\_collat\_balance = 36 EOS Next in the liquidation case (just as above), users buy out excess EOS from the liquidator contract for NUT. This NUT is then partially burned and partially transferred to the governance contract for the benefit of all NUT holders. ## **BP voting rewards** Equilibrium offers its users a nice revenue stream in the form of rewards that block producers agree to pay for in exchange for receiving the collective vote of the entire system collateral. The entire logic works the following way: 1. Block producers register with our smart contract by transfering EOS to the governance smart contract directly from the block producer’s account. After setup, the block producer should appear in the [govbpparams](https://bloks.io/account/eosdtgovernc?loadContract=true\&tab=Tables\&account=eosdtgovernc\&scope=eosdtgovernc\&limit=100\&action=bpregister\&table=govbpparams) table. BP must then transfer EOS to the eosdtgovernc contract with memo `{"bp_deposit:bp_account_name"}`. 2. BPs pay variable rewards which depend on equilibrium's proxy voting power: Standby BPs pay 85% of [min\_reward](https://bloks.io/account/eosdtgovernc?loadContract=true\&tab=Tables\&account=eosdtgovernc\&scope=eosdtgovernc\&limit=100\&table=govparams) parameter, which is roughly 5.5 EOS per day currently. Producing or top 21 BPs also pay their share of block rewards which is controlled by eosio.system [votpay\_factor ](https://bloks.io/account/eosio?loadContract=true\&tab=Tables\&account=eosio\&scope=eosio\&limit=100\&table=global4)and [inflation\_pay\_factor ](https://bloks.io/account/eosio?loadContract=true\&tab=Tables\&account=eosio\&scope=eosio\&limit=100\&table=global4)parametes and amounts to the 4/3 times the min\_reward which amounts to roughly 7.33 EOS/day for a producing BP. 3. If a block producer isn’t registered with the Equilibrium governance contract, it won’t be considered a candidate for **eosdtbpproxy** proxy voting. 4. NUT holders vote for registered BPs. Since each BP agrees to pay a different daily reward in EOS, NUT holders have an incentive to vote for those BPs who offer greater daily rewards. 5. Actual proxy voting happens in real time: when a NUT holder casts a vote for a BP, the proxy revotes for the top 30 BPs by NUT count. There is also a separate CRON service to ensure the proxy votes for BPs at some regular interval. 6. If it happens that by the time the proxy needs to vote for BPs and there are no active reward-paying BPs on the contract, the proxy will vote for the top 1 BP by NUT count. Rewards are calculated and collected each time the proxy revotes for a list of BPs. Rewards are payable in EOS and distributed among collateral holders and NUT holders according to the same logic as the above REX and liquidation rewards. This distribution is governed by the [reward\_weight](https://bloks.io/account/eosdtgovernc?loadContract=true\&tab=Tables\&account=eosdtgovernc\&scope=eosdtgovernc\&limit=100\&table=govsettings) parameter. # Test framework Testing smart contracts in the Equilibrium framework is a complicated, tedious process that goes as follows: apart from the contract development team, the QA team writes a node.js application that fully implements the entire business logic of the smart contracts. In other words, we emulate our contracts outside the blockchain. Importantly, we do not emulate their individual parts, but rather the entire overall structure. Then each operation of the test script is executed on the blockchain and in the local application, and we check that both systems act identically and appropriately. This way we minimize the chance of missing complex bugs. The high complexity of the system and cost of errors led us to this approach. In general, QA in Equilibrium uses deep regression randomized testing dependent on the blackbox strategy: * **Replay of the system in a local node.js application**. This greatly complicates and slows down testing, but lets us achieve higher quality for the output code. The parallel development of two systems, which should give the same result under the same conditions, lets us see all the possible difficulties and problems in the design of the system at very early stages of testing. * **The black box strategy**. We intentionally restrict the QA team from contact with the contract code. Without knowing the internal structure of the system, they can’t transfer design errors to the local node.js application. Therefore only ABI and technical specifications are used when mimicking contracts locally. * **Deep regression** is achieved by reconciling all the parameters of the local node.js application with the values from the tables of our contracts in the blockchain. After each action on the contract, a method is called to check that all the local application’s and blockchain contracts’ parameters have the same values. Even indirectly related parameters get checked. So we eliminate the most unpredictable and unlikely mistakes. ## Technical details Initial testing is carried out on local testers' machines. To do this, a local blockchain node is deployed and test versions of all system contracts are downloaded. Any initial blockchain state required for the test scenario is set. QA specialists manage the time parameter in this blockchain, which lets us correctly test the functionality that is sensitive to the movement of time (e.g. fees accrual). Secondary testing is carried out in the Jungle testnet, where contracts achieve the form in which they will be uploaded to the EOS mainnet. It is no longer possible to change the current time there and freely manage contract parameters. Therefore this stage of testing is used to verify the production version of contracts as well as the correctness of migrations and calculations. The main test scenarios are checked under conditions almost identical to the mainnet. ## About test scripts All test scenarios are a set of sequential actions in the blockchain and local node.js application that affect all the main functions. What makes our testing stand out is that there are no deterministic values in the scripts. All values for the tests are generated randomly and the action is considered to be completed correctly only if the operation with a random value yields the same results both in the local application and in the blockchain. This means we bring the test conditions as close as possible to the production conditions, and find problems caused by specific values transferred to our contracts. In addition to testing the correct operation of the actions, all invalid calls are also checked. With their help, we make sure that any incorrect conditions or input parameters will cause the contract to fail execution with an error. # Research {% content-ref url="/pages/-LuccIAU5\_C2mBk-BHa7" %} [Quantitative Introduction to the Equilibrium (Smart) Contract](/research/research-1/quantitative-intro) {% endcontent-ref %} {% content-ref url="/pages/-LuccIAVEMOfd7USENeB" %} [The Bancor Protocol: the Tip of the Iceberg](/research/research-1/the-bancor-protocol-the-tip-of-the-iceberg) {% endcontent-ref %} {% content-ref url="/pages/-LuccIAW5zJTv2nbT5MF" %} [Equilibrium Infrastructure: Collateral Adjustment Mechanisms](/research/research-1/equilibrium-infrastructure-collateral-adjustment-mechanisms) {% endcontent-ref %} # Quantitative Introduction to the Equilibrium (Smart) Contract  Equilibrium lets an EOS holder generate EOSDT stablecoins (USD pegged), if EOS tokens that are worth at least 170% of the EOSDT value are posted as collateral. As explained in our [previous articles](https://blog.eosdt.com/equilibrium-infrastructure-roles-and-voting-mechanisms/), EOS and the [EOSIO](https://eos.io/) infrastructure use the democratic DPoS protocol. One of the protocol’s features lets EOS holders vote to elect 21 Block Producers (BPs). However, the EOS must be [staked](https://www.eoscanada.com/en/what-does-staking-and-unstaking-eos-tokens-mean) to grant their holder the right to vote, and can only be unstaked after three days. Although votes have key financial and strategic considerations, **freezing a portion of the Equilibrium collateral for three consecutive days increases Equilibrium’s insolvency risk**. In a previous [article](https://medium.com/equilibrium-eosdt/the-threshold-for-staked-eos-collateral-a-robust-framework-4dce569173cb), we presented a first model that estimates the probability of an extreme loss on the collateral value over three days. The model can be used to determine a reasonably safe staking ratio. But this model has strong limitations. For instance, although we mentioned that the collateral ratio (CR) would have a natural support level that is significantly higher than the 170% critical CR, the model disregarded this behavior and considered the collateral on a standalone basis. ## Rational Position Owners As rational agents, the Equilibrium participants have an objective to generate the best return for a given level of risk. In particular, by posting EOS as collateral and issuing EOSDT, Position Owners keep their exposure on EOS, and create liquidity they can use to invest in different opportunities: they can even leverage their EOS position further. Among other return and risk considerations: * **The liquidity** **created has a cost.** This cost is paid through *\*\**Equilibrium’s admin and equilibrium fees. These fees are accrued, and paid on EOSDT redemption. * **The risk inherent to the total EOS Positions is “exchanged” for a low-risk EOSDT total position.** The Position Owner has the option (no obligation) to redeem his EOSDT. If the collateral value crashes below the value of the issued EOSDT, he can walk away. * **The risk** **of forced liquidation comes with a 20% liquidation fee.** Risk averse Position Owners would post more collateral, above the 170% minimum required, to avoid forced liquidation. **Equilibrium is governed by several variables that are designed for the Position Owners, as a group, to create liquidity in the safest possible manner.** ## The Position Owners Group: Asset & Liability Management (ALM) **The Position Owners group is comparable to a company** where the EOS pooled collateral constitutes their main asset, and the total EOSDT generated constitutes their main liability. EOSDT is valued at US dollar parity ($1 US dollar = 1 EOSDT) as long as the company is going concern. The EOSDT collateral management is similar to an ALM problem waiting to be solved! In particular, cash flow and balance sheet solvencies are better protected by having enough liquid assets at hand. In a severe EOS market downturn, the company should protect its solvency by selling (liquidating) assets, and use the sale proceeds to buy back its liabilities. Similarly, Equilibrium would sell the EOS held in the under-collateralized accounts, to buy back and burn the relevant EOSDT. In other words, Equilibrium would **deleverage its balance sheet**. ## The Equilibrium (Smart) Contract:A Down-and-Out Perpetual American Call Option The balance sheet analogy is an application of [Merton](http://www.people.hbs.edu/rmerton/Pricing%20of%20corporate%20debt.pdf)’s structural credit risk model. In a few words, a company’s liabilities are usually less volatile than its assets. Hence, the model assumes that the company’s liabilities are the strike of a call option on the company’s assets. The cash-settled call option with a strike ***L***, and underlying ***A*** has the following cash flows: 1. At inception (**t**=0): the option buyer pays a premium **p** to buy the call option 2. At maturity (**t**=**T**): 1. if **A**>**L** (assets above liabilities), the buyer can exercise the option to receive **A**-**L** 2. otherwise the option expires **worthless** Obviously, the flows in Equilibrium are more complex than a simple call option. To analyze the Equilibrium framework and understand all the mechanics involved, we should strip away the complexity and consider intermediate steps. **In this article, let’s start with a version of the Equilibrium contract that has no margin call.** In this version the Position Owner cannot post more collateral. If the collateral ratio drops below the critical level, the Position Owner will still incur the liquidation fee. Let’s go over the option’s specifics: **1/** there is no concept of fixed maturity (yet) in Equilibrium. in financial terms: ***the option is*** ***perpetual***. **2/** The Position Owner can decide to redeem his position at any time. In financial terms: ***the option is american.*** **3/** A position is closed if it is either: * redeemed by the Position Owner. In financial terms: ***the option is exercised***. * or automatically terminated as soon as the collateralization ratio drops below the critical level. In financial terms: ***the option is knocked-out***. **4/** Insolvency corresponds to the collateral value falling below the generated EOSDT value accrued at the relevant rates (e.g. the equilibrium fee). In Equilibrium, this accrued EOSDT is called *the current position debt* **\*\*(\_**CPD***t). It is time-varying. In financial terms:*** the option has a time-varying strike**\_**.\*\* **5/** Instant termination (the knock-out) corresponds to the collateral value falling at or below 170% of the current position debt. It is also time-varying. In financial terms: ***the option has a time-varying barrier level*****.** **6/** The option has an initial cost. In financial terms, it is ***the option’s premium*** Below is a description of the contract’s premium and payout profile for the Position Owner: 1. At inception (**t**=0): the Position Owner posts collateral valued at $$C\_0$$ and generate a value $$CPD\_0$$ of EOSDT. The premium paid is $$p = C\_0 - CPD\_0\ge70 % \* CPD\_0$$ 2. At termination date (**t**=**𝛕**), there is either: 1. **exercise**: if the collateral value increases, the Position Owners can redeem their EOSDT and make a profit. The payout is **C𝛕 - CPD𝛕** 2. **worthless termination**: if the collateral value reduced by the liquidation fee (**C**/120%) drops below the level of the current position debt **CPD𝛕**, the Position Owners should walk away with the EOSDT generated (or the equivalent dollars they bought against it). The payout is **nil**. 3. **safe termination**: if the collateral value drops below 170% of the сurrent position debt, but the collateral reduced by the liquidation fee is still above the current position debt, then the Position Owner can still recover **C𝛕**/(1+20%) against repayment of the current position debt. The payout is **C𝛕**/(1+20%) - **CPD𝛕** ## The Equilibrium (Smart) Contract: A Version In Continuous Time (Cheaters Edition) Price continuity is a theoretical concept. Oraclize (now Provable) provides real-time information about the collateral market so Equilibrium knows when a liquidation should be triggered. But there is still discreteness and probably latency in the quotes provided. Oraclize is like a referee in a soccer game. The referee will glance at the football goal every now and then. He would only know how far from the goal line the ball is if he looks in the right direction. Maybe he didn’t notice that the ball had already crossed the goal line. Worse (or better, depending on your team), maybe the ball did cross the goal line but was pushed back by the goalkeeper, and the referee missed it all! Let’s call this game the *distracted referee* *game*. In this context, the continuous time model is like video footage in football. The question is not whether it’s better or worse. It’s just (slightly?) different. The best part is: if we assume prices are continuous, the payout profile is much simpler! Indeed, the *worthless termination* **event cannot happen, and the intermediate *****safe termination*** event is terminal ! In fact, the termination date 𝛕 is the first time when the *safe termination* **\*\* event** almost **occurs. In other words, 𝛕 is the first time when the collateral ratio** almost **reaches 170% of the current position debt: the Position Owner must (**and can! **as there is no price gap) redeem his position to avoid the liquidation fee, and his option payout is 170%\*\_**CPD***𝛕 -*** CPD\*\**𝛕. In this scenario, the referee can see the ball almost crossing the goal line: he can blow the whistle just before and end the game! OK, in this example, the game looks frustratingly unfair: the referee is the Position Owner and the Position Owner is obviously a cheater: can he just stop the game whenever a catastrophic outcome is looming?! Honestly?! Let’s call this game the \_unfair referee game.* How do we bring fairness to this game? It turns out the game can still be fair if the Position Owner pays a substantial (Equilibrium) fee to play. In this article, the balance between the Equilibrium fee and the contract’s value is indeed our main concern. The liquidation fee and critical collateral level merely define floor levels for the Position Owner payout: there is absolutely no interest for the Position Owner to let the collateral value move below these floors. First Remark: in practice, as we’ve already hinted, the expiration date (***t***=𝛕) is within a discrete set of observations (e.g. every time prices are fetched from Provable - every five minutes or better). Following a serious collateral price drop between two observations, the event *\*\** could happen with a small but non-nil probability. Second Remark: Although in practice, the strike of the american option is also monitored in a discrete manner, the Position Owner can still walk away with his EOSDT such that his maximum loss is limited to the premium ***p***. The discreet monitoring of the strike is a risk for Equilibrium. Third Remark: The *unfair referee game* can also be considered in the alternative case of the referee who blows the whistle **just after** the ball crosses the goal line. In which case the referee is Equilibrium, penalizing the Position Owner instantly, and protecting the balance sheet from further loss in the collateral value: we would assume that the collateral is sold instantly without frictions. In a frictionless world of continuous prices, events **2** and **3** can't coexist. Graph\[1] represents various payout profiles: * In **red** if we exclude event **3** , the contract is a perpetual american call option struck at **CPD**t with a down & out barrier at 120% CPDt and a down & in one-touch option (protection) paying 20%\***CPD**t. * In **green** if we exclude event **2** , the contract looks like a perpetual american call option struck at **CPD**t. with a down & out barrier at 170% **CPD**t and a down and in one-touch option (protection) paying 70%\***CPD**t. * In **blue** is the payout profile. It is a closer version of the Equilibrium contract. Let’s call it Eq-0. It is all the potential final payouts of the contract in discrete time. Eq-0 terminates as soon as the collateral ratio drops below 170%. As we can see from Graph \[1], **in a frictionless and continuous prices world,** **both the red and green contracts, hold no risk below respectively the 170% and 120% levels**.  Despite what the graph might suggest, the red and green payout profiles are not necessarily valid upper bounds for Eq-0. The red and green payout profiles live in a continuous time world, whereas Eq-0 lives in discrete time. Between two monitoring dates, in a *distracted referee game*, the collateral value can consecutively drop below the 170% barrier **and** recover straight away. In this scenario the Eq-0 contract might still be alive, but the green contract would have been terminated. [Xia and Zhou](http://www.math.nus.edu.sg/~matdm/ma5245/semi/1.pdf) propose an analytic closed-form solution to price a perpetual american call in the *stock loan case*. The collateral model (a Geometric Brownian Motion) doesn’t capture the [levels of risk seen for the EOS collateral](https://blog.eosdt.com/equilibrium-infrastructure-collateral-adjustment-mechanisms/), but it is the first step towards a more effective model. To formalize the model, let’s define: * ***Ɣ*** as the equilibrium fee * (λ-1) as the protection: in our continuous model framework, it represents either an excess collateral (70%: green curve) or *\*\*\_a liquidation fee (20%: red curve). In both cases, both \_unfair game(s)*, the Position Owner would exercise right before the dropping collateral ratio touches respectively the 170% or the 120% levels. In that sense, both games have a protection against further losses. * 𝛕q the first time when the collateral value almost touches the λ\*CPD0 level We are looking for the optimal stopping time 𝛕 before 𝛕q that maximizes the contract’s expected value: $$sup\_τE((C\_τ−CPD\_0∗e^{γτ})1\_{τ < τ\_q} +(λ−1)∗CPD\_0∗e^{γτ}1{τ=τ\_q})$$ For the red payout profile: λ = 120% For the green payout profile: λ = 170% **Each of these simplified payout profiles can give us insight on the Equilibrium structure mechanisms.** ## For Equilibrium: A First Estimate Of The Minimum Required Collateral Ratio For simplicity and to explain the framework’s mechanics, let’s focus first on the no penalty, and no critical ratio case (λ = 100%). The λ > 100% case seems to be a good candidate for an [Ekstrom](http://www2.math.uu.se/~henrik/artiklar/HW4.pdf)-like model that we analyze briefly at a later stage. In the GBM world, Xia and Zhou would tell us that **an Equilibrium structure with an Equilibrium fee** ***Ɣ*****, a generated EOSDT value at CPD0 and a collateral value C0, can be offered to Position Owners if the following two constraints are satisfied**: * **the Equilibrium fee** ***Ɣ*** **should be higher than half the squared volatility** ***σ2*** **of the collateral.** * **the excess collateral should be high enough such that:** $$\frac{C\_0−CPD\_0}{C0}⩾\frac{σ^2}{2γ}$$ In the Equilibrium case, at inception, we have $$\frac{C\_0−CPD\_0}{C\_0}=\frac{70%∗CPD\_0}{170%∗CPD\_0}≈41%$$ Hence, the constraint becomes $$γ⩾121%∗σ^2$$ The second constraint is more restrictive. Using only EOS as collateral, the Equilibrium fee that would satisfy the second constraint can quickly reach very high levels. For this reason alone, this simple structure and model are not adapted for Equilibrium. **For a volatility around 20%, and an Equilibrium fee around 3%, the required collateral ratio would be above 320%!** The 3D *\*\**plot \[2] below shows how high the required ratio or the Equilibrium fee can get. In the Equilibrium context of a required collateral ratio above 170%: * For a volatility level around 20%, an Equilibrium fee above 4.5% would be warranted. * For a volatility level around 25%, an Equilibrium fee above 7% would be warranted. As mentioned before, the cost for the Position Owner in an *unfair referee game* should be much higher than in an alternative *distracted referee game.* This is where the full Equilibrium structure (the *fair game*) starts to make sense: * The liquidation fee will bring balance and decrease the cost for the Position Owner. * The discrete monitoring will compromise the protection and should also decrease the cost for the Position Owner. Despite its imperfections, Xia and Zhou’s model gives the reader the rationale for the presence in Equilibrium of the **liquidation fee** and **discrete time monitoring with margin calls**. .png?generation=1574787238238617\&alt=media) ## For The Position Owner: A First Estimate Of The Maximum Collateral Ratio In the λ > 100% case, [**an adaptation of the Ekstrom version of the Xia and Zhou model**](https://www.overleaf.com/6423158944spvkqxysccmh) **gives the minimum (optimal) exercise level for a given critical collateralization level (ƛ)**. The optimal exercise level should be at or above the highest root of a polynomial in $$\frac{1}{λ}y+\frac{2γ}{σ^2−2γ}−\frac{σ^2}{σ^2−2γ}y^{1−\frac{2γ}{σ^2}}=0$$ **At λ=170%, the model provides the Position Owner with a cap level for the collateral to be held in the account.** Above this cap level**, the Position Owner should optimally:** * **retrieve a portion of his collateral**. The retrieved EOS can be staked or sold to diversify his risk. * **or generate more EOSDT (more liquidity)** that he can also use to diversify his risk. The model quantifies either the collateral to retrieve, or the additional EOSDT to generate. .png?generation=1574787238300479\&alt=media) The models presented show inflated values for the Equilibrium fee as the cost a Position Owner should pay to play an *unfair referee game* is high. In future articles, we’ll need to integrate all the missing features of Equilibrium (discreteness, margin calls) to generate more reasonable estimates. Furthermore, the Black-Scholes model used here might not be adapted to model the EOS dynamics. Further analysis of intraday data (e.g. 5min to match the expected collateral monitoring frequency) would help us determine the model’s suitability. *With this article and many to come, we are taking serious steps to educate the Equilibrium community, to instill confidence in the framework’s mechanisms, and to ultimately benefit the community itself.* 1. MERTON, ON THE PRICING OF CORPORATE DEBT: THE RISK STRUCTURE OF INTEREST RATES. The Journal of Finance. Vol 29, No. 2. December 1973 2. XIA, ZHOU, STOCK LOANS. Mathematical Finance, Vol. 17, No. 2, pp. 307-317, April 2007. 3. EKSTROM, WANNTROP, MARGIN CALL STOCK LOANS. 2008 # The Bancor Protocol: the Tip of the Iceberg .png?generation=1574787235653480\&alt=media) Equilibrium recently announced the launch of its new R\&D division, [Equilibrium Labs](https://equilab.io/), aiming to develop new price-pegging algorithms and structures that will bring enhanced liquidity to the decentralized finance market. It was a logical choice to start our research with the [Bancor](https://about.bancor.network/) protocol and [Daniel Larimer’s pegging algorithm](https://medium.com/@bytemaster/high-liquidity-price-pegged-token-algorithm-d86d71188162). The Bancor protocol is a simple and elegant solution that lets tokens be converted to other types of tokens. The price of conversion is solely determined by the ratio of the transparent reserves of each token. It’s an ambitious initiative named after Keynes famous [proposal](http://imsreform.imf.org/reserve/pdf/keynesplan.pdf) to create a “\_c\_urrency union” that would “generalize the essential principle of banking as it is exhibited within any closed system. This system is the necessary equality of credits and debits, of assets and liabilities.” Extensive research has already formalized and simulated Keynes’s model. Looking at [Valdecantos and Zezza](http://models.sfc-models.net/vz2015/models.pdf)’s work, we can immediately weigh the potential complexity of modelling a real-world economy with four “countries:” the United States, Europe, China, and the rest of the world. In the real-world economy, a country’s inhabitants work, produce, export, import, and consume. Agents have risks and preferences. Naturally, prices will reflect these risks and preferences. By contrast, the price of[ a Bancor Relay](https://blog.bancor.network/how-bancor-relays-work-c712a374374f) *\*\**is completely determined by the amount of available tokens held in reserve (eg. the Bancor “connectors”). The concept of risk is missing, and with good reason. The Bancor protocol is a fundamental concept that should be considered the backbone of a central bank. And like a central bank, the Bancor protocol structure is not profit-oriented. From a stablecoin perspective, Bancor can be used to synthesize the most trivial model of a central bank with a pegged currency policy. ## Daniel Larimer’s pegging algorithm For instance, Larimer describes a pegging algorithm based on the [Bancor](https://storage.googleapis.com/website-bancor/2018/04/01ba8253-bancor_protocol_whitepaper_en.pdf) protocol in a recent [article](https://medium.com/@bytemaster/high-liquidity-price-pegged-token-algorithm-d86d71188162). The new Market Making token (MMS) introduced there is a wrapper around a Bancor Relay token with two connectors — one for the collateral asset (EOS, for example) and the second one for the USD-pegged asset. Pegging the Bancor price to the market price consists of rebalancing the connectors’ quantities to keep their market value equal, or within a tight range of ± 2%. The market value of each connector is based on a trusted price feed or a 24-hour median. Rebalancing the connectors’ quantities happens by moving collateral in and out of an excess collateral reserve. The perfectly named “pegging algorithm” could be perceived as the first simple representation of a country choosing to peg its currency to that of another. The country would use its currency reserves to intervene in the market if it became necessary to enforce the peg. Similarly, the “pegging algorithm” can use the excess collateral to buy a depreciated USD-pegged token. However the “pegging algorithm” is not an MM algorithm. Larimer points out that those willing to hold MMS tokens are those willing to be slightly leverage-long in a collateral asset (such as EOS). \_\_They are the ones willing to hold inventory risk. They essentially accept this risk for free or little benefit. So how would the structure compensate for inventory risk? Let us resume the rational market maker’s (MM) objectives: * A rational MM would seek to maximize profits under inventory risk constraints. The market maker should be rewarded for holding this risk. * A market maker will also be concerned with running out of inventory, in which case they wouldn’t be able to quote both a bid and ask. They prefer to hold a mix. Once again, the Bancor Protocol is a decentralized exchange facility where anyone can show a price that’s determined and fully backed **by transparent quantities. For a participant, the price ratio has to reflect a ratio of tangible reserves, but the ratio of tangible reserves could reflect the participant’s risks and preferences. The ratio of tangible reserves can be the output of an algorithm** (like the “pegging algorithm”) that accounts for inventory risk. In other words, the price produced by Bancor is only the tip of the iceberg. It could be the price that an MM decides to publish. We know it’s not a fake price because it’s backed by actual quantities. What we don’t know is how the quantities will be adjusted: we don’t know the MM actual risks (like the MM’s true inventory) or preferences (like the MM’s aversion to risk). In these conditions, anyone can try to reverse engineer the MM’s risks and preferences. Anyone can try to build a better model to arbitrage the MM: “the (stablecoin) shorts” would start to compete. Competition between rational MMs might be what is needed to effectively attract liquidity. Alternatively, can a community reach a consensus on a more advanced MM model. Can a community vote to set the parameters of this advanced MM model on a regular basis? ## The Bancor Framework... With Custom Preferences? Let’s illustrate the above with a simple model that is widely used in economics theory. Given the sole dependency of the Bancor relay price on the connectors’ quantities, the model reminds me of one that is at the heart of some of the most advanced economic models: the [Dixit-Stiglitz model](https://www.brown.edu/Departments/Economics/Faculty/Matthew_Turner/ec2410/readings/Dixit_Stiglitz_AER_1977.pdf). The Dixit-Stiglitz model follows this simple hypothesis: “a consumer who is indifferent between the quantities (1,0) and (0,1) of two commodities prefers to hold a mix.” In other words, agents love variety. In his [40-year review](https://www8.gsb.columbia.edu/faculty/jstiglitz/sites/jstiglitz/files/Monopolistic%20Competition%2C%20he%20Dixit-Stiglitz%20Model....pdf) since the Dixit-Stiglitz model, Stiglitz states: *\*\**“If the returns to shares of firms” (aka tokens) “are not perfectly correlated, then each is an imperfect substitute for the other. Individuals will want to hold all shares in their portfolio — just as in the Dixit–Stiglitz model, individuals want to buy all commodities” (aka tokens) ”that are produced.”  Bancor is a limit case of the Dixit-Stiglitz utility. Because inventories can never deplete, there will always be a mix. For two relays with similar connector positions, Bancor will always show the same consensus price, regardless of preferences. If the connector quantity of an asset drops, the Bancor price for the asset will soar. But what if the MM wants to take more risk and sell more of the asset, despite the low inventory? Dixit-Stiglitz lets the experienced market-makers show a more aggressive offer, should they believe that the price will revert to its mean. It gives market-makers more freedom. The table below shows how the alternative Dixit-Stiglitz price would evolve compared to the Bancor price.   ## A Generalized Bancor Protocol Wrapper Dan Larimer’s algorithm lets the Bancor Relay show a price that is within a spread, close to a feed price: the 24-hour median price. In fact, the feed price can be anything. If we rebalance the Bancor connectors’ quantities such that their ratio equates the feed price (FP): qEOSDTBancorqBancorEOSDT / qEOSBancorqBancorEOS = 1 / FP, then the Bancor Relay formula will force the Bancor price qBancorEOS/EOSDTqEOS/EOSDTBancor to revert to FP. For an agent with specific preferences, *FP* should be the price that maximizes the Dixit-Stiglitz Utility. For a Market Maker, *FP* should be within market bid-ask spread, closer to the bid if there is a buying interest, and closer to the ask in case there is a selling interest. The choice of feed price is the critical leeway we need to make the MMS algorithm a true market making algo. FP could factor in a market maker’s preferences and risk aversion. We can let the market maker algorithm modify the connector quantities to target any set price.  ## A Simple Wrapper: The Dixit-Stiglitz Protocol For an EOS-EOSDT Relay, an agent with preferences holds a total quantity QEOSQEOS of EOS tokens and a total quantity QEOSDTQEOSDT of EOSDT tokens. If they prefer to quote a more aggressive ask if the price goes up, or a more aggressive bid if the price goes down. The agent can set: $$FP = (Q\_{EOS}/Q\_{EOSDT})^{1−ρ}$$ Then $$q^{Bancor}\_{EOS/EOSDT}$$ will be reset towards the optimal level that maximizes the agent’s Dixit-Stiglitz utility. ## An Advanced Wrapper: The Market-Maker Protocol Unlike a nonprofit central bank, the MMs objective is to maximize the book value of their MMS tokens. The astute MMs can design an algorithm that target the equilibrium price that maximizes the expected book value under their inventory risk constraints over a specific investment horizon. This is the next step to build serious incentive for anyone to buy (or create) market-making tokens, and trust that their invested value will be maximized. In the context of Equilibrium Labs, there is room for research into an extended role for the NUT token holders. NUT holders could interact with or even manage such an EOS/EOSDT wrapper for EOS collateral liquidations. The transfer of more EOS to a Bancor Relay would intuitively drive the EOS/EOSDT price down to account for the keepers rebate. Stay tuned! \_\_ \[1] [STIGLITZ. MONOPOLISTIC COMPETITION AND OPTIMUM PRODUCT DIVERSITY. American Economic Association. The american Economic Review, 1977](https://www.brown.edu/Departments/Economics/Faculty/Matthew_Turner/ec2410/readings/Dixit_Stiglitz_AER_1977.pdf) # Equilibrium Infrastructure: Collateral Adjustment Mechanisms .png?generation=1574787236435823\&alt=media) The killer features of the Equilibrium framework are its protection of EOSDT-to-USD parity and its ability to maintain a high level of confidence in the framework’s responsiveness to market events. Reviewing the main two protections in place: * the EOSDT generator needs to **post sufficient EOS collateral to fulfill at least 170% of the generated EOSDT value** (measured at 1 EOSDT = $1 USD). Assuming no margin calls, liquidations or adverse market action, the 170% requirement theoretically protects EOSDT’s $1 parity from a 41% maximum drawdown event (i.e. 70% less collateral). * The EOSDT generator is heavily incentivized to post more than the minimum 170% collateral, or else there is a material **risk of auto-liquidation with a 20% liquidation penalty**. If the EOSDT generators can’t post enough, they can alternatively repay the position’s original amount voluntarily. Either way, the system’s collateral-to-position ratio benefits from a natural resistance level. In other words, the average EOSDT generator should display strong risk-averse behaviors against collateral drops that would exceed the resistance level. To avoid the liquidation penalty, a participant would post in excess of 50% or 100% of the minimum required collateralization ratio. In the following analysis, we consider a mono-currency EOS collateral framework and its parameters, since EOS is the initial collateral asset supported by Equilibrium at the time of writing. ## **Insight on Equilibrium participant behavior: the DAI-ETH case** Equilibrium is a new project with no historical data yet. EOS price history is similarly only available since the January 2018 launch of EOSIO. In order to mitigate our lack of EOSDT and EOS data, we have modeled data on the comparable DAI stablecoin (with ETH as collateral) to gain insight on how EOSDT participants will behave. EOS warrants a conservative approach to our analysis because its returns have a much higher risk profile. Let’s start with a few simple observations of the collateral to position ratio: Like EOSDT, the DAI has also a penalty fee for auto-liquidation around 15%. The correlation between ETH returns and DAI Collateral to debt ratio movements unsurprisingly exceeds 65% for daily movements and 75% for weekly movements: the ETH collateral to debt ratio movements highly correlate with the ETH returns. It furthermore looks like the 250% ETH collateral to debt ratio could be the *natural resistance level* that we mentioned earlier. The [collateral](https://mkr.tools/system) to debt ratio hardly goes below this level. The 250% resistance level surprisingly does not reduce the overall risk of the collateral to debt ratio, as measured by volatility and higher order moments. Above the resistance level, movements in the collateral to debt ratio display sharply increasing volatility and convexity measures, as shown in table \[1] and figures \[1] and \[2]. | | min | max | mean | median | stddev | skew | kurtosis | | ------------------------------------ | ------- | ------ | ------ | ------ | ------ | ----- | -------- | | EOS Returns | -27.98% | 42.6% | 0.04% | -0.14% | 7.71% | 0.96 | 5.29 | | ETH Returns | -18.68% | 18.07% | -0.38% | -0.23% | 5.48% | -0.10 | 1.44 | | DAI-ETH Collateral to debt movements | -46.40% | 60.89% | 0.01% | -0.17% | 12.0% | 0.15 | 3.43 | ![Figure \[1\]: Densities of the ETH/USD log-returns and the ETH collateral to DAI debt ratio movements (empirical). Data source: CoinMarketCap and mkrtools](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWaejQTbic_71yF%2Fimage%20\(2\).png?generation=1574787236221537\&alt=media) ![Figures \[2\]: Densities of the ETH/USD log-returns and the ETH collateral to DAI debt ratio movements (gaussian kernel fit). Data source: CoinMarketCap and mkrtools](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWc6Cgim_fRNqvr%2Fimage%20\(1\).png?generation=1574787236425202\&alt=media) ## **An analysis of the collateral asset: the EOSDT-EOS case** The EOS daily log-returns essentially display most of the [characteristics](http://rama.cont.perso.math.cnrs.fr/pdf/empirical.pdf) seen in stocks and equity indexes. By this we mean, * Absence of autocorrelations (see figure \[3]). * Heavy tails (kurtosis > 3): EOS distribution is leptokurtic with fat tails. * Volatility clustering (see figure \[4]): Autocorrelation in the absolute returns process is generally a sign that high volatility returns tend to cluster: volatility is stochastic. If we have an extreme absolute log-return, there is a high probability that the absolute log-return on the following day will also be high. * Slow decay of autocorrelation: decay is typically a power law of time. Slow decay is a sign of long-range memory for the absolute or squared returns process: EOS volatility can be projected with better results if the model learns from the long history of volatility behavior (see the rough volatility model and its calibration on historical intraday volatility by [Gatheral and Rosenbaum](https://arxiv.org/pdf/1410.3394.pdf), for example). EOS’s limited history doesn’t let us conclude for significant correlations above order 10 (correlation of absolute log-returns with 10-day lagged absolute log-returns), as shown by the autocorrelogram, but more investigation in that direction is warranted. Accounting for stylized facts around logarithmic EOS returns, we propose a framework using an intuitive and conservative approach similar to [Jurek’s](https://www.nber.org/papers/w17422.pdf). Our objective is to determine a measure of crash risk, and *in fine*, a reasonable liquid portion of the total collateral that is required to protect Equilibrium from a crash. Let’s assume here that the liquid portion can be sold instantly on the markets, without friction. Our concern is to make sure that there’s enough collateral available to be sold. The proceeds of the sale should at least cover the generated EOSDT value (and potential penalties: 20% of the current position). The remaining portion can be optimally staked, frozen for three days, and then used to vote for block producers, vote on propositions for changes in parameters, and enjoy other powers that we described in the previous article [“*Equilibrium infrastructure: Roles and Voting Mechanisms.*”](https://blog.eosdt.com/equilibrium-infrastructure-roles-and-voting-mechanisms/) ![Figure \[3\]: Autocorrelations of daily EOS/USD log-returns. Data source: CoinMarketCap](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWeSBzMx_N7OWWR%2Fimage%20\(11\).png?generation=1574787236345736\&alt=media) \_\_ ![Figure \[4\]: Autocorrelations of daily EOS/USD absolute log-returns. Data source: CoinMarketCap](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWgCQ8RxB_yYJ9c%2Fimage%20\(5\).png?generation=1574787236228642\&alt=media) ## **The Threshold for Staked EOS Collateral: A Robust Framework** **STEP 1: adjust the collateral asset returns for stochasticity.** In order to eliminate the effects of stochastic volatility, the first step is to **scale each daily return by a measure of lagged volatility**. Applying the suggested measure by [Jurek](https://www.nber.org/papers/w17422.pdf), the chosen volatility measure is the three-month lagged standard deviation. The resulting log-return to volatility ratios is a series of z-scores. No matter the market’s regime or volatility state, we are looking at the jump rather than the level. In other words, we are looking for negative shocks or surprises in EOS volatility and returns. These shocks are the only movements that can break the *natural resistance level* without warning. EOSDT generators and bad debt keepers wouldn’t have any time to either replenish their collateral position or sell it in the markets at a reasonable price. Such are the extreme events that drive the Equilibrium insolvency risk. **STEP 2: define the empirical crash distribution.** In order to isolate the collateral’s crash risk exposure, we have to define a lower threshold below which z-scores are considered “crash” material. Given the limited historical data on EOS, we set the threshold at -2.0 for our exercise. At a z-score of -2.0 and a standard deviation level of 5% ( corresponding to an annualized standard deviation at 200%), the daily log-return equivalent is -10%.\ At a z-score of -6, the daily log-return equivalent is -30%. If no portion of the collateral is staked, the 41% required haircut and an extra 20-30% posted by risk-averse EOSDT generators should largely compensate for extreme adverse market movements (\~ -60%). In these conditions, staking a portion of the collateral can be a reasonable option. Figure \[5] outlines the selected crash observations (highlighted in red). ![Figure \[5\]: EOS/USD Z-scores computed with the daily log-return divided by 3-months lagged standard deviation. Data source: CoinMarketCap](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWihgPkLYmv2DC5%2Fimage%20\(10\).png?generation=1574787236430967\&alt=media) The conditional crash distribution is obtained by transforming the z-scores into losses. The current volatility level is used with the distribution of z-scores to simulate a series of potential losses:  **STEP 3: fit a Pareto distribution to the crash risk distribution.** The Generalized Pareto Distribution (GPD) is a classic alternative to the normal distribution to better fit the probability distribution of extreme events. It has two parameters: the scale parameter and the shape parameter. The maximum likelihood method produces point estimates of these parameters, as well as a standard error that we use to determine a 99% confidence interval. The worst z-score observed is -3.36, computed with a -15.75% negative return scaled by a lagged three-month standard deviation at 4.68%. It is not the worst return recorded — that distinction belongs to a -30% return recorded on Sep 4th, 2017 with a standard deviation at 10.40%. -3.36 is the worst negative **shock.** The worst z-score (worst shock) combined with the worst volatility level observed sets a potential negative return at **-34.96%**! Furthermore, the worst z-score **observed** is not the worst z-score of the population of log-returns. The observed z-scores constitute a sample of the population of log-returns. We mitigate the sample bias using the **99%** confidence interval. The confidence interval on the GPD parameters implies a confidence interval on the quantile of the worst z-score observed. In this interval, the lowest quantile candidate for the -3.36 worst z-score is only at 0.655. In other words, **if we have a strong negative return that belongs to the crash distribution (z-score < -2), then the conditional probability that its corresponding z-score exceeds the -3.36 level is 34.5% regardless of the current volatility level**. If the three-month lagged standard deviation is at 10% with a shock level at -3.36, then the equivalent negative return is -33.6%. ![Figure \[6\]: EOS/USD Crash distribution (in red) fit to a Pareto distribution. Data source: CoinMarketCap](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWkUciHPnRi7r17%2Fimage%20\(13\).png?generation=1574787236439028\&alt=media) **STEP 4: Determine a safe staked portion of the collateral.** The probability of a crash multiplied by the conditional level of the crash should not exceed the unstaked *liquid* collateral. Any remaining portion could theoretically be staked. We can fit a gamma distribution on the negative z-scores, or similarly a beta distribution on the crash distribution. Both distributions have very appealing properties: we can derive the cost of insuring a crash ξ from a simple closed-form formula. The cost is written as the product of the probability of observing market failure (π Q) multiplied by the exposure to the crash, which is the expected shortfall above the critical z-score level. ***a*** **and** ***b*** are the parameters from our conservative beta distribution. ***β*** a parameter that measures the loss we want to insure against such that: (1-x)*β* -1 is the consequent loss function where x is the loss (crash) on the underlying EOS. **Ɣ** is a risk aversion parameter.  A simplified version (*β*=1) is given by:  To fit the beta distribution on the crash series, we enforce two constraints as in Jurek’s article \[3]: * the median of the crash distribution should be equal to the median of the beta distribution * the quantile of the worst observed z-score should equal to the most conservative quantile derived from step three. The beta distribution estimation over crash returns gives the following estimates: z-score threshold of -2.0: a=25.6, b=177.7 (figure \[7]). z-score threshold of -1.5: a=18.9, b=151.8. z-score threshold of -1.0: a=8.34, b=91.4 (figure \[8]). Choosing Ɣ=2.5: z-score threshold of -2.0: the resulting loss above threshold is at 13%. z-score threshold of -1.5: the resulting loss above threshold is at 11%. z-score threshold of -1.0: the resulting loss above threshold is at 9%. Assuming a safe collateralization ratio of 250% and a three-month lagged standard deviation at 10%, the loss in this ratio would amount to a 47.5% drop (10% of the collateral value, and a 9% excess loss in value), which would leave us with a 202.5% collateralization ratio if it happened. This is still above the 170% critical level. Note that over three days, assuming the same level in market crash every day, this exposure would be 1-(1-47.5%)^3 = 85.53%. Starting from a safe collateralization ratio of 250%, the loss in this ratio would amount to 213%, which would leave us with a 37% collateralization ratio if it happened. This is below the 100% parity level. In this case, a cut of 63% of the 250% EOS collateral ratio must remain liquid and reserved for potential liquidation. Furthermore, at least 133% should be in reserves if we wish to satisfy the 170% critical level. We can then consider staking the remaining collateral for three days. The model offers a robust and conservative methodology to determine whether a portion of the collateral can be staked. But our analysis is far from complete. Questions remain over the choice of the standard deviation measure, the risk aversion parameter, the probability of having extreme crash returns over three consecutive days, and most importantly, the choice of the z-score threshold that should ideally be below -6. The small sample of daily data we are working with clearly has its limitations. ![Figure \[7\]: density of the 19 worst crash returns corresponding to a z-score \< -2.0 - Constraint (at 50% and the lowest percentile of the max crash return obtained by fitting the Pareto distribution): Beta fit in blue.](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWm9j3bm5bUhU8e%2Fimage%20\(6\).png?generation=1574787236305818\&alt=media) ![Figure \[8\]: density of the 64 worst crash returns corresponding to a z-score \< -1.0 - Constraint (at 50% and the lowest percentile of the max crash return obtained by fitting the Pareto distribution): Beta fit in blue.](https://2144390662-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lu2hSiIJL6s9mDCM4rn%2F-LuccEjLyYzeoLIrpRm7%2F-LuccYWokEfVz5jENbQb%2Fimage%20\(8\).png?generation=1574787236324286\&alt=media) Given the numerous sources of liquidity for trading EOS today, the expected collateral to debt ratios (\~250%-300%) would sit in a very high range compared to other traditional liquid-like collateral assets. There are obviously always more factors to be considered, like market liquidity risk and market impact. When all these measurable factors are accounted for, only the black swan factor remains. A black swan is, by definition, impossible to model — it’s unpredictable. EOSIO and Equilibrium can give their community the power to deal with black swans the same way they are dealt with in the real world: by adapting or changing the rules. More than a set of static rules and parameters, the EOSDT Equilibrium is a robust, dynamic framework where a variety of models and parameters are possible as long as it’s justified and convincing to larger group of voters. *With this article and many to come, we are taking serious steps to educate the Equilibrium community, to instill confidence in the framework’s mechanisms, and to ultimately benefit the community itself.* \_\_ \[1] CONT, EMPIRICAL PROPERTIES OF ASSET RETURNS, STYLIZED FACTS AND STATISTICAL ISSUES. October 2000. \[2] GATHERAL, ROSENBAUM, VOLATILITY IS ROUGH, October 2014.