Risks
Last updated
Last updated
Gloop users will interact with a number of smart contracts, all of which impose risks. This can be both known and unknown risks that could result in the failure or vulnerability in the smart contracts which could result in assets being locked or lost forever.
Gloop uses third-party oracles for price feeds and in the future, for other external data, such as redemption ratios for liquid staking tokens. Potential risks include incorrect pricing if an oracle fails or is compromised. While decentralized oracles like Chainlink provide tamper-resistant data feeds, robust reliability, and other security measures, as well as Gloop smart contracts being coded to revert if stale prices are found or if the Arbitrum L2 Sequencer is down, unforeseen risks cannot be entirely eliminated.
Assets that are supplied to or borrowed from the protocol could fluctuate in value due to systemic risks of the issuing platforms or market volatility, including depegging of stable assets. This could result in the liquidation or closing of a user's position.
You can find smart contract audit reports in the section. Gloop will acquire more security audits in the future as well, but audits don't eliminate risks completely. Please only supply asset amounts you'd be okay with losing.
No DeFi protocol can be considered entirely risk free. Different risk categories are explained in detail below. You can find additional risk and security-related information in the section.
Every blockchain network, including Arbitrum Mainnet which the Gloop protocol is built on, has potential such as congestion, sequencer outages, or security vulnerabilities.
Even with multiple audits, smart contract code can have overlooked bugs or vulnerabilities. No technology is 100% failsafe.
DeFi protocols rely on third-party data providers (Oracles) for price feeds. If an oracle fails, returns stale price information, or is compromised, it could lead to incorrect valuations of assets. This creates negative effects downstream such as fluctuations in Health Factor.
Collateral risk pertains to the value and stability of assets used as collateral. The inability to liquidate collateral due to rapid decrease in value or insufficient external liquidity can result in bad debt.
Smart Contract Risk Mitigation
We are continuously taking notes for contract improvements that can go into V2s at a later date, which will also undergo additional, formal audits. Lastly, once the protocol reaches fiscal sustainability, the protocol will consider employing bug bounty campaigns.
Oracle Risk Mitigation
Gloop reduces oracle risks by using a decentralized oracle (Chainlink) to provide reliable and tamper-resistant price feeds.
Platform and Token Risk Management
During the Lending and Borrowing protocol's infancy, Gloop will employ several strategies to keep user risk low. The Gloop Multisig will set low supply and borrow caps for all assets. As the protocol becomes battle-tested and more resilient, the Multisig will slowly raise the caps.
For lending and borrowing, there will be a primary focus on USDC as the sole asset. Although there is a risk of depegging for any stablecoin, USDC is one of the most widely used stablecoins, ensuring external protocol flexibility and liquidity for both lenders and borrowers.
On the collateral side, the setting of conservative loan-to-value (LTV) percentages help maintain overcollateralized borrow positions. The Gloop Multisig can adjust these risk parameters as needed to respond to changing market conditions, continuing to safeguard the protocol. Hopefully one day, the protocol can convert to on-chain governance by token holders, giving control to the community. Using GM assets as the main assets for Gloop products also offers flexibility as they are some of the most liquid tokens on Arbitrum.
Lastly, to help minimize bad debt from accumulating in the protocol, Gloop features a Community Liquidations system. The Liquidate dashboard shows positions with the lowest Health Factors. If there are addresses with Health Factors below 100%, any user can partially or fully liquidate one or more of these addresses.
This section provides transparency for the administrative powers within the Lending Pool (LP) platform. The Gloop Multisig will be referred to as the Admin for this entire section. The Multisig consists of 12 signers and 4 out of 12 signatures are needed for approval. By documenting the extent of the Admin's rights, users can make informed decisions when interacting with the platform. Our commitment is to build and run a sustainable, secure DeFi product, and decisions and actions by Gloop core contributors are geared toward that end. As we continue to grow and increase our Total Value Locked, we plan to slowly and thoughtfully decentralize administrative duties.
Here is a rundown of the Admin’s powers and impacts for the LP’s main and ancillary contracts (“core LP functions” means deposit(), withdraw(), borrow(), repay(), and liquidateUser()):
Lending Pool Main Contract
Set Gloop Stakers wallet
The address that is set to the Gloop Staker’s wallet will receive a portion of the accrued borrow interest from the pool. This will be distributed to Gloop Stakers.
If the wallet is set to an incorrect address, the interest would go to that address when the staker’s yield is withdrawn.
Set the Address Store
This contract acts as an address book for the Arbitrum contracts of the initial GM collateral tokens and USDC, along with other addresses that might be used by future contracts.
Setting the Store to a different contract could cause the LP’s core functions to revert.
Set the Price Oracle
The Price Oracle directly and indirectly calls Chainlink feeds to obtain current pricing of GM assets.
If this is set to the wrong address, then core LP functions could revert.
Set the Interest Rate Model (IRM)
The IRM uses a predetermined rate chart and the current borrow utilization to calculate the borrowing rate for the Lending Pool (the borrowing rate also gets translated to the lending rate for lenders).
The Admin is tasked with finding what rate formula is best for all users and desired lending and borrowing balances of the Pool. Setting non-optimal rates could cause borrowing to be expensive and deter users from engaging with the platform and/or could lead to faster liquidations.
Configure Assets
The Admin configures parameters for all collateral tokens and USDC. These parameters include: vault contract, Lending Factor, Borrow Factor, Supply Cap, and Borrow Cap
Setting these parameters is crucial for sustainability and solvency of the protocol. Setting asset caps too low could lead to users unable to deposit into or borrow assets from the pool. Setting Lend/Borrow Factors too low could suddenly give many users a poor health factor and make them liquidatable.
Set GM tokens
The Admin can set which tokens can be used as collateral in the platform. These are gmBTC, gmETH, and gmSOL at launch.
Setting GM token array to a different list of tokens would cause all transactions with assets besides USDC to revert.
Set Points contract
The Admin can change or remove the Points contract.
Setting it to the Zero Address or replacing it with a random address/contract would abruptly stop the GM Points program and/or cause the core LP functions to revert, if the new contract does not have the same functions as the GM Points contract.
Update Liquidation Bonus
The liquidation bonus, which is the bonus collateral a user gets when liquidating another user, can be set by the Admin.
If the bonus is set too low or to zero, there would be little to no incentive to liquidate users, so bad debt could build in the system, leading to insolvency. There is a hardcoded max cap of 10% on the bonus, so that extreme is protected.
Liquidate Bad Debt
This function partially or fully repays a borrower’s position that has "bad debt," meaning they have less or no collateral, and their position is at risk of or is fully insolvent.
Owner does not receive any collateral for liquidating bad debt. It is only to avoid bad debt accrual. Thus, there is not much risk in the use of this function, rather, the risk is not using it when the situation calls for it.
Set Gloop Stakers Yield Factor
Sets the percentage of repaid borrow interest that goes to Gloop stakers.
The higher the percentage the more of the repaid interest goes to the Stakers and not to the USDC lenders. The Admin must fine-tune this in a way to reward token holders but also incentivize USDC lenders.
Update Reserve Factor
Similar to above, this sets the percentage of repaid borrow interest that goes to protocol reserves.
Withdraw Reserves
Admin can withdraw the reserves to the Treasury.
Withdraw Stakers Yield
Withdraws earned interest in USDC to the Gloop Staker’s wallet.
GM Collateral Vaults
Pause/unpause operation
In the event of peculiar activity with a collateral token, the Admin can pause the vault so that no collateral tokens can be deposited or withdrawn from the Pool. This allows time for an investigation into the issue.
The Admin does not want to pause well-functioning vaults, as users would not be able to deposit or withdraw collateral into that vault.
Migrate funds to new vault
In the event of an unforeseen emergency or if the vault is compromised in some way, Admin can pause the existing vault, deploy a new vault, migrate all user funds to that vault, and configure the asset with the new vault in the Pool. This would secure assets, and users would be able to interact with their funds again from the new vault.
These actions must be handled in an effective manner or funds could be lost and user activity could be disrupted.
GM USDC Vault
Pause/unpause operation - see above
Migrate funds to new vault - see above
Set Incentives Contract
The Admin can set the Incentives contract for the USDC vault, which enables USDC depositors to be rewarded with token incentives.
If the contract is set to a different contract and does not have the same functions as the GM Incentives contract, depositing to and withdrawing from the USDC vault would not work.
GM Oracle
Update the Arb Sequencer feed and Chainlink USDC feed
The Admin can update either feed in the rare event that Chainlink would change the aforementioned feed addresses.
GM Incentives
Set Reward Vaults (addresses where the rewards are held)
Admin can set the vaults which hold rewards earmarked for USDC lenders.
If this is set to the wrong addresses, users will not be able to receive rewards.
Configure rewards
Admin configures all potential incentives, including emissions rates and distribution duration. The rates could be set to zero at any time, but this is to be avoided under normal circumstances.
There are many safeguards/checks that make configuring pretty difficult to input incorrectly.
Remove rewards
Admin can remove reward token configurations at any time (which would lead to the cessation of that particular reward), however rewards can only be removed 30 days after reward distribution end.
Pause/unpause
In the event of peculiar activity, the Admin can halt the Pool balance relaying and the claiming of rewards to allow time for troubleshooting/investigating.
Unnecessarily pausing the contract prevents users from claiming earned rewards and also could miss pool balance additions in a user’s efforts to accrue more rewards.
GM Points
Set Point Parameters
Admin can set the point program duration and the points earned per lent or borrowed dollar.
The parameters cannot be changed when the program is active.
The main Gloop Protocol contracts are or will be verified on , making them publicly available and auditable by anyone. Ottersec has audited the GMI suite of smart contracts, and Halborn and Kiki (Guardian Audits) have completed on GM Lending/Borrowing smart contracts. Gloop also uses a security expert that does security-focused reviews and offers consultation behind the scenes.