Freight Trust Utility Staking For More Information Post a Github Issue in our Community GitHub, freight-chain/network
- Adversarial Pools
A Memetic Verification method in which those who report are rewarded for honest reporting and punished for dishonest reporting.
These pools emulate the verification (proof of violation) method by asking "agents"/"users" to report on which of two pools will hold the least value at the end of the round. By using the "asset's at risk (i.e. stake)" verification method, adversarial pools can mimic markets in the way it uses market sentiment to predict relative value. The value of the two pools should always trend towards a 50/50 split.
- Reporting of Prices for On-Chain Assets
- Reporting of Prices for Off-Chain Assets with a Specified Price Feed
- Reporting of Prices for Off-Chain Assets with a non-Specified Price Feed
Least Value means reporting on the reported price of the asset on a per unit account basis. This means defining a benchmark price for an asset, then reporting on the aggregate value of the pool. For example:
As the reward for reporting accurately must always be over 100% of the value staked, it follows that a dominant strategy would be to report equally in both pools, yielding an EV of 1 at an absolute minimum at an equal 50/50 split. To counter this, a $% fee (e.g. 5) on the round should be introduced making the equal split method a losing strategy at value discrepancies between the pools under
Fees can be adjusted as necessary if the equal split method has become too submissive or too dominant. What this should mean is that as liquidity increases, the necessity of a fee will be diminished as rounds trend closer and closer towards a 50/50 split.
As the reward for reporting accurately must always be over 100% of the value staked, it follows that a dominant strategy would be to report equally in both pools, yields EV = 1.
EV = 1, where at an absolute minimum there is an equal 50/50 split.
To counter this, a $var_fee 5% fee on the round has been introduced making the equal split method a losing strategy at $value_discrepancies between the pools under 2.44%
The fee will be adjusted as necessary if we feel the equal split method has become too worthless or too dominant. What this should mean is that as liquidity increases, the necessity of a fee will be diminished as rounds trend closer and closer towards a 50/50 split.
A user may find themselves in a position in which they have 400 EDI in pool A which currently holds 30 more EDI than pool B. By sacrificing >30 ether into Pool B, the user both hedges against their initial position, and increases the odds that their larger report is correct.
This method is totally encouraged. As are all methods of manipulation. Proof of Violation requires a user to accurately report which side will have the least value, correctly predicting the sum actions of all including our example user.
Token holders control the contract via a mechanism that allows for voting on the operator of the contract who may start and stop the round and change the fee percent. This is a planned feature, and would correspond to a switch to a floating exchange rate for $EDI, as related to PEM rfc/issues/5.
Note: Governance tokens are not tradeable, nor transferable. The only way you can get governance tokens would be through $EDI. There is immediate implementation planned for governance decentralization until this implementation has proven to be a robust one.
In order to deposit into the staking pool a certain number of $EDI is deposited, this is pooled into a stability fund. The stability fund is used to ensure against losses, perform enhancements. The stability fund is an external pooling mechanism that can, on its own, generate returns that shall be distributed to those accounts that deposited into the staking pool.
All profits will be accumulated into a pool that can be accessed by the token holders who are participating.
By burning a portion of tokens, one relinquishes their governance in exchange for their share of the profit pool. This reduces transaction costs of periodic dividends, eliminates lock-up periods that periodic dividends require, and protects token holders against low liquidity on exchanges. The mechanism of burning tokens is by transference into the stability fund. The fund can use this either by liquidation via open market operation or by distributing it as a proceed.
Without the need for random number generation, we do not have to use an Oracle. While Oracles can be verified after the fact, accounts can be confident that they are protected from Oracle issues.
As the round is played between accounts, there is no need for a bankroll that could be lost through play or stolen by mismanagement.
The profit pool appears similar to a bankroll in that it is a central pool of ether, but it is not by design at risk and is secured by our smart contract.
Choosing and backing a side is done via the back function, which takes an unsigned integer as an argument, representing the side choice. Side A is chosen by submitting 1, and Side B is chosen by submitting 2.
This function is locked when there is no current active round or when the contract is paused.
As a security measure, choices made within a certain amount of time of the end of the round (denoted by the updateable variable bufferTime) will extend the end of the round by an amount of time (denoted by the updateable variable timeAdd). The default $bufferTime is %4 standard blocks, while the $default_time to add is %35 standard blocks.
Winnings withdrawal is done via the $withdrawWinnings function, which takes an unsigned integer as an argument, representing the $round_id to withdraw from.
This function is locked when the round associated with the given id is still in progress, when the contract is paused when the given id is invalid or does not represent a round that has been played, or when there is no active round.
The latter is to ensure that the $startRound`` function has been called before withdrawals are made, ensuring the round winner variable has been updated properly.
If the round associated with the given id only had ETH on one side, a refund is issued to anyone withdrawing from that round: no house_cut is taken, and the winning and losing side are ignored. This is to protect accounts from a low-activity round.
If the round associated with the given id ended in a tie, the house_cut taken from each withdrawal is determined by the “house_cut_tie” variable. Otherwise, the house_cut is determined by the “house_cut” variable.
Starting a new round is done via the “startRound” function. This can only be done if there is no active round, or if the contract is not paused. Beyond creating a new active round, this function also declares the winner of the previous round, takes the house_cut, awards a bounty, and allows withdrawals on the previous round to take place.
To incentivize accounts to start a new round once the current round has been completed, accounts are awarded a bounty for calling this function, equal to a percentage of the house_cut taken from the round. This percentage is stored in the updatable variable “startround_bounty_percent.”
If the previous round had no $ETH in it, the round’s time is simply extended. This is the first thing checked in the function and is a gas-saving measure. In this event, there is no bounty for the function caller.
If one side had no $ETH in it, but the other did, a new round is started without taking a house_cut, so that the accounts from the previous round get their refund. In this event, there is no bounty.
Otherwise, a house_cut is taken out of the total in the round, and a bounty is taken from the house_cut. Both are awarded to the treasury and the function caller respective, and a new round is started.
CFTC RULE 4.41 - HYPOTHETICAL OR SIMULATED PERFORMANCE RESULTS HAVE CERTAIN LIMITATIONS. UNLIKE AN ACTUAL PERFORMANCE RECORD, SIMULATED RESULTS DO NOT REPRESENT ACTUAL TRADING. ALSO, SINCE THE TRADES HAVE NOT BEEN EXECUTED, THE RESULTS MAY HAVE UNDER-OR-OVER COMPENSATED FOR THE IMPACT, IF ANY, OF CERTAIN MARKET FACTORS, SUCH AS LACK OF LIQUIDITY. NO REPRESENTATION IS BEING MADE THAT ANY ACCOUNT WILL OR IS LIKELY TO ACHIEVE PROFIT OR LOSSES SIMILAR TO THOSE SHOWN.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent