basis-cash / basiscash-protocol Goto Github PK

BIP-6

Title: Bond Proposal
Author: angelo_bounty0x, dennet
Category: Economic (Bond Issuance)
Summary: Limiting bond minting

Current protocol design:

Whenever the 1 hour TWAP (Time Weighted Average Price) of the $BAC price is below $1, unlimited Basis Bonds (hereinafter “$BAB”) can be minted at a discount. The discount is determined by the 1 hour TWAP. With a Basis Cash oracle price of P DAI, bonds are sold off at a price of P BAC (effective price being P^2 DAI), promising bond holders a premium when redeemed. For example, when the TWAP is $0.9 , then it is possible to mint one $BAB by burning 0.9 $BAC. A speculator can purchase $0.9 $BAC for $0.81 DAI, burn 0.9 BAC for 1 BAB, resulting in an effective price of 1 BAB = 0.81 DAI.

Problem

Unlimited $BAB issuance capacity will lead to over issuance of $BAB debt. There is likely to be a time lag between the reduction in supply caused by $BAB issuance, and the twap price adjustment towards $1. The one hour window between each twap adjustment guarantees an unlimited amount of $BAB bonds will be available for speculators to purchase as long as demand exists.

The Basis protocol should disincentivize issuance of unnecessary $BAB debt because long term overissuance of debt will lead to numerous protocol risks and vulnerabilities, including but not limited to the following:

1. A decline in value of $BAS. Only when the level of debt no longer exceeds the treasury balance will $BAS resume receiving seigniorage rewards. If there is a large pool of outstanding debt to be redeemed then there will be an increasingly long wait period for $BAS holders to resume receiving $BAS seigniorage rewards. This will result in a decline in $BAS price, as the present value of $BAS will be reduced.

2. A larger pool of outstanding $BAB Bond debt. A rapidly increasing debt pool will result in reduced demand to purchase new bonds, due in part to a longer bond redemption waiting period. In order to offset increasingly lengthy redemption time a correspondingly larger bond discount will be needed to entice new bond purchasers. If the debt issuance outpaces debt redemption there is a greater risk of systemic protocol failure due to inability to repay outstanding debt.

3. Over contraction of the $BAC supply: Over issuance of $BAB will result in an over contraction of the $BAC supply, resulting in increased volatility as the over contracted supply of $BAC will swing in the opposite direction, above $1 necessitating further issuance of $BAC to expand the supply. This instability hinders the chief goal of the protocol which is to provide consistent price stability.

4. Opportunity for bad actors: An unlimited $BAB issuance enables an attack vector whereby bad actors artificially manipulate price to below $1 in order to purchase a large quantity of $BAB bonds at a discount.

Proposed Solution:

This proposal suggests altering the bond issuance mechanism by setting a maximum bond issuance cap. The cap will be of the following size: ($1-1hTWAP)*(Circ $BAC), where 1hTWAP is the 1h TWAP of the $BAC price and “Circ $BAC” is the Circulating $BAC supply. The cap will last for one hour; after an hour a new TWAP will be calculated and the cap is reset based on the new TWAP value.

Hi team,
I have no intention to transfer 3000 usdt to a contract address . The contract address is: 0xa7ed29b253d8b4e3109ce07c80fc570f81b63696
Can u help me find it back ? I am really sorry for causing such an error.
My transaction hash is:
0x234668830b2efff882cd068424a27a1421e17ceb16b750cc65c736a69b39038b
If you can, please forward my address, I would be very grateful:
0x7c874010fe56324eb4935478b7b345547201cdf9

thanks,
Rainie

npx hardhat run ./scripts/deploy.ts --network ropsten

I ran this command but it occurs error
"HardhatError: HH700: Artifact for contract "PoolWrapper" not found.
at Artifacts._getArtifactPathFromFiles (E:\projects\Blockchain\Upwork\basiscash-protocol-master\node_modules\hardhat\src\internal\artifacts.ts:391:13)
at Artifacts._getArtifactPath (E:\projects\Blockchain\Upwork\basiscash-protocol-master\node_modules\hardhat\src\internal\artifacts.ts:316:17)
at Artifacts.readArtifact (E:\projects\Blockchain\Upwork\basiscash-protocol-master\node_modules\hardhat\src\internal\artifacts.ts:49:26)
at getContractFactoryByName (E:\projects\Blockchain\Upwork\basiscash-protocol-master\node_modules@nomiclabs\hardhat-ethers\src\helpers.ts:100:20)"

https://github.com/Basis-Cash/basiscash-protocol/blob/master/docs.basis.cash
basis.cash documentation giving me 404 error

BIP-3
Title: Creation of a Community Development Fund + Formal Audit
Author: @yyctrader
Category: Economic

Simple Summary
The author proposes to allocate 2% of future seigniorage to a newly created Community Development Fund (not to be confused with the Basis Cash Treasury, which is integral to the stabilization mechanism and will continue to function as before).

If passed, the process of engaging formal auditor(s) will commence immediately.

Motivation
With the ongoing success of the bootstrapping phase of the Basis Cash protocol, it is imperative that we continue to build on our positive momentum by investing in the growth of the platform. As we continue to feast upon some ungodly yields, we must not lose sight of the ultimate goal: to foster adoption and have Basis Cash become the premier decentralized algorithmic stablecoin in DeFi. Attempting to reach this goal will only be possible through building a vibrant community of contributors and fostering partnerships throughout the DeFi ecosystem.

The Community Development Fund will enable the Basis Cash protocol to cover operational expenses, fund a marketing budget, hire new team members as required, and incentivize community contributors through grants etc.

The funds will be secured by a 48-hour timelock until the launch of V2, at which time it is envisioned that we will transition to a community-controlled multi-signature wallet.

If passed, the author proposes that the first use of the Community Fund will be to commission a formal audit of the Basis Cash Protocol. In light of the heavy demand across the industry, it is essential that we start the audit process as soon as possible.

Specification
We are proposing to implement one primary change:

1. 2% of future Seigniorage will be transferred to a newly created Community Development Fund.

0x1B1a6963118a031d609f4B1f46Dbf2976c0cA801

Summary:
The Basis Bond (BAB) deflationary policy is activated when Basis Cash de-pegs below $1 leading to auction of BAB.

When the price reclaims $1, the new supply of BAC that goes to the treasury is distributed proportional to the amount of bonds supply, and any excess BAC minted is distributed to the Boardroom.

We propose a transaction incentive fee on bond purchase & redemption to avoid a whale attack on bond auctions & capture value from bond treasury operations for BAS holders, by transferring the fees to the Boardroom.

Motivation:
The newly minted BAC has two destinations

1. To the treasury for Bond redemptions
2. Excess supply of BAC after Bond redemptions are transferred to the Boardroom

The current economic design does not impose any fees on Bond purchase & redemption from treasury operations. However, there is a possibility of an attack vector by a large whale investor in Bonds, that could capture the entire seigniorage on next expansion.

Example:

1. Assume one hour TWAP BAC price is 0.97
2. A large whale investor could scoop up 90% of Bonds, speculating on likely reclaim of the 1 peg
3. The large whale investor captures almost 90% of the BAC on next expansion

We propose a transaction fee upon Bond purchase & redemption that would be transferred to the boardroom as revenue from bond treasury operations. This is how it would work:

1. A fee of x basis points will be deducted from the BAC burned upon purchase of bonds
2. A fee of y basis points will be deducted from redemption proceeds of bonds from the new BAC minted
3. Total fees earned from treasury bond operations at the end of epoch will be transferred to the boardroom

Specifications:

There appears to be a bug in Boardroom.sol that allows a user to double-claim a snapshot reward if stake() or claimDividends() is called in a tx that is the same block as a new boardSnapshot but after the tx with the boardSnapshot.

In particular, claimDividends() includes:

 uint256 totalRewards = getCashEarningsOf(msg.sender);
 directors[msg.sender].appointmentTime = now;

If called in the same tx as as the boardSnapshot, getCashEarnings will include the rewards from the snapshot. AppointmentTime will be set to now. When called again in a subsequent block, having an appointmentTime that equals the time of the snapshot results in rewards being claimed for that snapshot.

Possible solution: setting the appointmentTime to the lastBoardSnapshotTime() + 1. claimDividend() calls that are in the same block but after the snapshot will not be double-claimable. claimDividend() calls that are in the same block but before the snapshot will still be claimable in a later block.

Implementation of this solution : link

BIP-5
Title: Lowering Seignorage TWAP Threshold
Author: liquidity_king, @liquidity_king
Category: Economic

Summary:
Currently, Basis Cash only mints additional BAC to BAS/BAB holders when the TWAP for BAC is over 1.05 This proposal is to lower the seignorage threshold to a lower value voted on by the community.

Motivation:
Early on in an algo coins lifecycle, investors are primarily speculators who are betting on continued expansion, while having confidence that the bond mechanism backstop will encourage buying below peg. BAC does not have a natural source of demand, with demand primarily coming from speculation that the network will expand.

Speculators rely on the seignorage dynamic to support BAS prices, which ultimately drive demand for BAC. They take comfort that the BAB mechanism will support them when prices fall below peg. However, with the current parameter of 1.05 there is a gap from 1.0-1.05 where investors are not supported by the protocols incentives. Speculators buying BAC at 1.04 are not supported by BAB demand for another 4 cents, and they are also not going to be receiving any seignorage income from their farmed BAS. The 1.05 parameter also effects BAB redemptions, meaning that BAB buyers need to have faith that TWAP will reach 1.05 in a reasonable time frame. Lowering this threshold gives BAB more potency which is the most critical incentive for the protocols long term survival. Finally in the very long term having a more narrow threshold should help us target a more narrow peg which is the ultimate value proposition of the project.

Voting Options for BAS/BAB Seignorage Threshold:
*1.05 (current)
*1.04
*1.03
*1.025
*1.02
*1.01
*1.0

It seems no people to ask , when meet questing

BIP-1
Title: Use BAC CirculatingSupply for Minting
Author: Basis-Cash Analysis Group
Category: Economic

Simple Summary
The current Basis Cash (BAC) mint function calculates the number of BAC tokens to mint as: totalSupply *(oraclePrice-1). We propose changing this to circulatingSupply *(oraclePrice-1) where ciculatingSupply is the totalSupply of BAC minus the balanceOf BAC within the treasury contract.

Motivation
The Basis Cash protocol is designed to quickly expand the supply of BAC when the time weighted average Uniswap pair price of BAC-DAI is above 1. There is no hard limit on how much each expansion can create in supply. The function simply calculates the deviation from the oracle price, then multiplies by the current total supply of BAC: totalSupply *(oraclePrice-1).

The minted BAC has two possible destinations: the treasury or the boardroom. The treasury is used for Basis Bond (BAB) holders to redeem BAB for BAC. Minted BAC to the boardroom is distributed to staked Basis Share (BAS) holders. The Basis Cash protocol first mints BAC into the treasury if there is less than 1000 BAC within the treasury, regardless of if there is BAB tokens in circulation. If there is more than 1000 BAC within the treasury at the next expansion, then the protocol mints BAC into the boardroom.

During the first 5 days of the Basis Cash protocol, a hard cap of 50000 BAC tokens will be minted with no expansions through the mint function. Because of this unique scenario and demand for BAC in farming pools, the price of BAC has risen to all time high prices of over $1,000/BAC (currently about $100 as of writing). This means that the first expansion of the protocol after the 5 day genesis period will possibly mint millions of new BAC if current prices hold. These millions of BAC will be placed within the treasury first where they are not able to be accessed to sell into the open market since no BAB tokens have been created. With no new BAC in circulation to lower the price and the total supply of BAC potentially in the millions, the second expansion on day 7 could be excessively large for the early days of the protocol since the total supply of BAC would then be extremely high. Such a high supply of BAC could make stabilizing the peg unnecessarily long which can be fixed with BIP-1’s simple and resilient parameter change.

For example, a BAC price of $500 would mean that the first expansion into the treasury is calculated as: 50000 * (500-1) = 24950000. These 24.95m BAC cannot be accessed by anyone since they are only for BAB holders (which don’t exist on day 6). With no new BAC supply entering the market to lower the price, the second expansion on day 7 would then be calculated as: 24950000 * (500-1) = 12450050000

This creates billions of BAC in circulation if a comparable scenario occurs. Of course, it’s entirely possible that the price of BAC drops significantly naturally as this scenario is anticipated, but BIP-1’s simple and intuitive fix for this early scenario is a win-win. The calculation of the circulatingSupply instead of totalSupply would prevent excessive expansion in this current scenario (and all future scenarios). This change is not a vulnerability/security fix, it simply takes more parameters into account (the supply of treasury BAC) when calculating expansions. This new addition to the expansion phase of the protocol makes Basis Cash more secure against all possible economic states now and in the future.

Specification
We propose changing the BAC minting function from totalSupply *(oraclePrice-1) to instead use circulatingSupply *(oraclePrice-1) where circulatingSupply is calculated as all BAC minus the tokens within the treasury contract.

This permanently solves the unique motivating scenario as well as creates a future-proof new protocol rule that can remain within the Basis Cash protocol. This change to the protocol expansion rules is in effect more resilient not only for the genesis case that it is needed, but also makes the Basis Cash system more adaptable if there’s various levels of funding remaining in the treasury for BAB holders.

BIP-4
Title: Modifications to bond redemption process and adding a bond-operation oracle
Author: DeFi Morty, @defibeth
Category: Economic

Summary:
The current Basis Bond deflation policy is determined by the treasury’s BAC balance. We propose a new expansion mechanism by which:

1. In cases of expansion, current bond supply-treasury balance BAC is sent to the treasury from allocated seigniorage for bond redemptions.
2. Any excess seigniorage is sent to the Boardroom.

Furthermore, we suggest deploying an additional oracle with an epoch length of 1 hour, to be used when performing Bond-related operations by the Treasury.

Motivation

Newly minted Basis Cash has two possible destinations: the treasury or the boardroom.

The treasury is used for Basis Bond (BAB) holders to redeem BAB for BAC. The newly minted BAC that goes to the boardroom is distributed amongst Basis Share (BAS) holders. The Basis Cash protocol first mints BAC into the treasury if there is less than 1000 BAC within the treasury, regardless of the number of BAB tokens in circulation. If there is more than 1000 BAC within the treasury on next expansion, then the protocol mints BAC into the boardroom.

Currently, the Treasury’s BAC balance is set to 1001 by the initializer function. However, this can create a potential attack vector, involving the following steps:

1. When the price of BAC sits below $1, bonds are issued
2. Treasury balance falls below 1,000 due to bond redemption
3. Seigniorage goes to the treasury
4. If BAC price remains below $1, the attacker will be able to purchase a large amount of BAB
5. Drain the BAC balance of the treasury upon next expansion

The attack described above has very low feasibility, but should it succeed it can potentially damage the value of the BAC token. Furthermore, as oracles currently use 24hr TWAP for peg valuation, this may allow the purchase of BAB at the 24H TWAP price window regardless of the current price of BAC.

The attack can be mitigated by changing two components of the contract:

1. Allow BAC that goes to the Treasury to only be distributed proportional to the amount of bonds minted, and for any excess amount to be distributed to the Boardroom.
2. Add a new oracle with an epoch length of one hour, and for the Treasury to utilize the oracle for bond-related operations.

Specification
We suggest modifying Treasury.sol as follows:

let treasuryReserve = min(seigniorage, bondSupply - seigniorageSaved);
sendTo(Treasury, treasuryReserve);
sendTo(Boardroom, seigniorage - treasuryReserve);

We suggest modifying the oracle mechanism as follows:

Deploy a new oracle BondOracle.sol with an epoch length of one hour, and modify the Treasury’s bond-related operations to use the new BondOracle.sol instead of the current TWAP oracle.

bond price should be cash price ^2, but in contract code, it just set the cash price to bond price.

Title: Update oracle period to 24 hours
Authors: @defibeth, @fr-jerry-smith
Category: Technical, Economic

Simple Summary
The Basis Cash Oracle contract currently pulls in the time-weighted average price (TWAP) of BAC against DAI on Uniswap every 10 minutes. However, this short oracle update timeframe poses two major issues:

1. Excess gas prices. An external party must call update() within the Oracle contract every PERIOD (minimum update timeframe) to keep price data up to date. However, being required to call a function every 10 minutes is not desirable, as the amount of gas required linearly increases when PERIOD is shorter.

2. Frontrunning risk. A short oracle update timeframe increases frontrunning risk. For instance, an attacker may be able to buy up bonds by dumping BAC on Uniswap, and quickly redeem them at the next oracle update, essentially draining BAC from the Treasury.

Thus, we propose to increase the minimum oracle timeframe to 24 hours, based on feedback from the community.

Motivation
The current 10 minute Oracle update timeframe was decided to maximize efficiency as a stablecoin, as the protocol is able to adjust to significant price impacts more quickly. However, a shorter timeframe results in potential frontrunning risk as described above; while a longer timeframe exposes BAC to short term price volatility within that timeframe.

While this issue should be resolved through additional research on oracle efficiency, in the short term (i.e. while Basis Cash is within its early stages) a longer oracle period is desirable - as price impacts are mitigated due to the protocol now utilizing longer periods of price data. As TWAP fundamentally weighs out older prices efficiency is also a non-issue.

Users participating in the early stages of Basis Cash should be aware that this change will most likely result in short-term price volatility, while avoiding Treasury frontrunning risks in return.

Specification
Update PERIODwithin Oracle.sol from 10 minutes to 24 hours.

It would be ideal if in this repo or readme there was a list of contract addresses for what has been deployed on mainnet.

Does this exist? If not - would love to see it

BIP-2
Title: Burn Excess Seignorage from Treasury
Authors: @defibeth, @fr-jerry-smith
Category: Economic

Simple Summary
The Basis Cash Treasury contract currently holds all excess seignorage from the past two BAC expansions, with its current balance totaling in nearly 500M BAC. This is obviously a problem, as: (i) this seignorage allocation was incorrectly executed by two different Boardroom contracts that was, or will be migrated; (ii) this excess supply leads to an incorrect, hyper-inflated valuation of circulating BAC supply; and (iii) could be a potential attack factor.

As such, the authors are proposing to burn all current BAC seignorage being held by the Treasury contract, excluding 1,001 BAC as originally intended by the protocol. This will allow any excess seignorage to be sent to the new Boardroom contract for them to be correctly distributed to BAS holders.

Motivation
BAC maintains its algorithmic stability through an incentivized monetary policy of expansion (Share dividends) and contraction (Bond redemption). The Treasury is a crucial component of this system as it controls any excess BAC supply, either for BAS distribution to the Treasury or redemption of BAB. However, as BAC has been trading at a minimum ~60x premium since protocol launch, this led to unacceptable amounts of BAC seignorage being held in the Treasury contract in an attempt to keep BAC on peg. As Boardroom launch was delayed none of the excess seignorage was distributed to shareholders and entered circulation, causing the protocol to print even more BAC on second expansion. Currently the Treasury contract holds nearly 500M BAC, valuing in more than $5 trillion at the time of writing.

This is completely unacceptable considering the current price of BAC, which in theory should only result in ~100x seignorage expansion. Thus it is trivial to burn any excess BAC issued by the protocol due to the Boardroom contract not being launched on schedule.

Specification
We are proposing to implement three primary changes:

1. All current seignorage BAC holdings of the Treasury will be burned, excluding 1,001 BAC. This will allow the Boardroom to distribute excess seignorage to BAS holders instead on next expansion, returning BAC to peg as intended.
2. We will implement an initialize function on a new, migrated Treasury contract. This function can only be called once to burn any excess seignorage holdings, and should not be executed thereafter.
3. Bonds are only redeemable if 1 BAC < 1 DAI. This is to prevent potential attack factors with Bonds, as any additional seignorage will be sent to the Treasury if there are any BAB in circulation.