The Fortress Protocol is the Decentralized Lending & Money Market project within the Jetfuel Ecosystem. Since Fortress launched in April, the protocol has seen hundreds of millions in volume and TVL, and has remained one of the top lending and borrowing protocols on BSC. As the protocol has been operating perfectly since launch, the time has arisen to bring massively positive updates to Fortress. We are thrilled to announce Fortress will be updated with some of the following items by Friday August 6th 5 PM UTC.
- Transfer the Oracle Provider from Band to Chainlink (DONE).
- Updates from Dynamic Rates to Fixed Speed Ratings.
- Removal of FAI rewards and eventual elimination of FAI.
- Adding the possibility of borrowing caps on assets.
- Add FTS as a single asset to earn FTS.
- Add FTS-BNB Pancake LP as an asset to earn FTS and promote FTS liquidity.
- Cross Chain to Polygon.
- Governance goes live.
- Fortress only Telegram & Twitter
What does all this mean? Read below to get a more in-depth explanation of the updates
Price Oracle: Updated from Band Oracles to Chainlink Oracles
- Fortress Protocol is using Chainlink price oracle feed on Binance Smart Chain network for main assets(except FTS, FTS-BNB LP)
- Chain Link cooperation announcement: https://twitter.com/chainlink/status/1422165104209104897?s=20
- Fortress Protocol is using Umbrella price oracle feed on Binance Smart Chain network for FTS. https://explorer-bsc.umb.network/first-class-data?keys=FTS-USD
- Fortress Protocol is calculating FTS-BNB LP token price with PancakeSwap LP token price calculation formula.
FTS Fixed emission
- Fortress Protocol will set fixed FTS emission to each market for the incentivize of supply and borrow of each token
- Emission can be updated by the protocol owner(governance if it is launched)
- FAI will be removed from the protocol
- FTS reward to FAI Vault will be set to 0 and the rewards will be redirected to the main assets.
- Users need to withdraw FAI from the FAI Vault and repay FAI to the protocol
- Fortress Protocol will set the borrowing cap to each market if necessary.
- Overall users total borrow amount can’t exceed the borrowing cap, once total borrow is reached to borrow cap, the borrow transaction will be failed with proper error return
- Borrow caps increase the security for lower liquidity and more volatile assets
Support FTS market
- FTS market will be added to the protocol to earn FTS by staking FTS
- Users can supply FTS, but can’t borrow FTS from the protocol
- FTS borrow may be implemented in the future when the FTS market matures
Support FTS-BNB LP market
- FTS-BNB LP market will be added to the protocol to earn FTS by staking FTS-BNB Pancake LP.
- Users can supply PancakeSwap FTS-BNB LP token, but can’t borrow FTS-BNB LP token from the protocol
Cross Chain to Polygon
- Fortress on Polygon is nearly complete and is actively tested on testnet
- A percentage of FTS emissions will be bridged from BSC to Polygon and will be able to earned by supplying or borrowing on polygon.
- Polygon Fortress governance will be enabled to allow the community to dictate the future of the protocol
The Fortress protocol is governed and upgraded by FTS token-holders, using three distinct components; the FTS token, governance module (GovernorAlpha), and Timelock. Together, these contracts allow the community to propose, vote and implement changes through the administrative functions of a fToken or the Comptroller. Proposals can modify system parameters, support new markets, or add entirely new functionality to the protocol.
FTS token-holders can delegate their voting rights to themselves or an address of their choice. Addresses delegated at least 100,000 FTS (1% of total supply) can create governance proposals.
When a governance proposal is created, the voting period begins. Voting lasts for 3 days; if a majority and at least 400,000 votes are cast for the proposal, it is queued in the Timelock and can be implemented 2 days later. In total, any change to the protocol takes at least 5 days.
Users can access the governance portal on the Vote Tab
FTS is a BEP-20 token that allows the owner to delegate voting rights to any address, including their own address. Changes to the owner’s token balance automatically adjust the voting rights of the delegate.
Delegate votes from the sender to the delegatee. Users can delegate to 1 address at a time, and the number of votes added to the delegatee’s vote count is equivalent to the balance of FTS in the user’s account. Votes are delegated from the current block and onward, until the sender delegates again, or transfers their FTS.
The required minimum number of votes in support of a proposal for it to succeed. (400,000 FTS: 4% of total supply)
The minimum number of votes required for an account to create a proposal. This can be changed through governance. (100, 000 FTS: 1% of total supply)
The duration of voting on a proposal, in Binance Smart Chain blocks. This can be changed through governance. (86400 blocks, 3 seconds/block, 3days)
Create a Proposal to change the protocol. E.g., A proposal can set a fToken’s interest rate model or risk parameters on the Comptroller.
Proposals will be voted on by delegated voters. If there is sufficient support before the voting period ends, the proposal shall be automatically enacted. Enacted proposals are queued and executed in the Fortress Timelock contract.
The sender must hold more FTS than the current proposal threshold (proposalThreshold()) as of the immediately previous block. If the threshold is 100,000 FTS, the sender must have been delegated more than 1% of all FTS in order to create a proposal. The proposal can have up to 10 actions (based on proposalMaxOperations()).
The proposer cannot create another proposal if they currently have a pending or active proposal. It is not possible to queue two identical actions in the same block (due to a restriction in the Timelock), therefore actions in a single proposal must be unique, and unique proposals that share an identical action must be queued in different blocks.
After a proposal has succeeded, it is moved into the Timelock waiting period using this function. The waiting period (e.g. 2 days) begins when this function is called.
The queue function can be called by any Binance Smart Chain address
After the Timelock waiting period has elapsed, a proposal can be executed using this function, which applies the proposal changes to the target contracts. This will invoke each of the actions described in the proposal.
The execute function can be called by any Binance Smart Chain address
Note: this function is payable, so the Timelock contract can invoke payable functions that were selected in the proposal.
A proposal is eligible to be canceled at any time prior to its execution, including while queued in the Timelock, using this function.
The cancel function can be called by the proposal creator, or any Binance Smart Chain address, if the proposal creator fails to maintain more delegated votes than the proposal threshold (e.g. 100,000).
Cast a vote on a proposal to the vote.
Each fToken contract and the Comptroller contract allow the Timelock address to modify them. The Timelock contract can modify system parameters, logic, and contracts in a ‘time-delayed, opt-out’ upgrade pattern
The Timelock has a hard-coded minimum delay of 2 days, which is the least amount of notice possible for a governance action. Each proposed action will be published at a minimum of 2 days in the future from the time of announcement. Major upgrades, such as changing the risk system, may have a 14 day delay.
The Timelock is controlled by the governance module.
A dedicated community forum has been built for discussion around the governance of Fortress. You can access the forum here: https://fortress-protocol-governance-forum.nolt.io/
New Fortress Telegram and Twitter (soon) Social Channels
Please join our new channels for Fortress!
You can join the Telegram here: https://t.me/fortressprotocol
The Fortress Twitter account will be live in the next few days to provide the community with dedicated Fortress updates and community interaction.