Repository navigation
Bounty Program Disclaimers & Scope Clarification
Issue description:
The global daily limits implemented in the code are susceptible to manipulation by an anyone, leading to inconvenience for legitimate users due to the time lock on any outgoing transfers. The system will remain in an undesired state until the smart contract owner intervenes.
Possible solution:
We are working on a more sophisticated strategy to decide the delay of a outgoing transfer.
Issue description:
The agreement creation precedes the token transfer. If a fee on transfer tokens is used, then the amount of tokens transferred may be reduced (due to transfer fees) and become less than the amount specified in the agreement for claiming.
Possible solution:
We are aware of it and will carefully choose assets onboarding.
Issue description:
Alterations to the rewardToken in the middle of distribution, especially without verifying the congruence of decimals between the previous and the new token and ensuring price consistency, can lead to potential risks of excessive or insufficient rewards to distribution recipients.
Possible solution:
We expect the function _setRewardToken can only be set once, we prefer to keep some flexibility here.
Issue description:
During liquidation, collateral may be seized even if the borrower has not entered the market with it. Such behavior is likely unexpected for the borrower.
Possible solution:
It is a feature to ensure the protocol's solvency.
Issue description:
The iToken uses a non-standard way to implement permit. It may cause compatibility issues when used in a third-party project.
Possible solution:
Prefer to keep it as it is.
Possible solution: Prefer to keep it as it is.
7. Manipulation of iToken when TotalSupply is zero can lead to implicit minimum deposit amount and loss of user funds due to rounding errors
Issue description:
iToken contract could be manipulated when totalSupply is 0, leads to implicit minimum deposit amount and loss of user funds due to rounding errors.
Possible solution:
when new asset is deployed, make sure a small size will be deposited.
Additional statement:
projects like sUSX, sDF and vaults, etc—where the share value is determined by an exchange rate—have similar issues, so we won’t list them separately.
A user can exceed the segregation mode debt ceiling by repeatedly borrowing amounts too small. While the issue does exist theoretically, the practical constraints like gas costs and collateral requirements are consistent with our own assessment that the risk to the protocol is minimal.
9. Interests don't accrue across all collaterals and borrowings in user's position, results in non-realtime equity check.
This represents an intentional design decision rather than a security vulnerability in two aspects:
- balance gas cost during liquidation, accruing all markets on every borrow or liquidation would impose significant gas costs, especially for positions with multiple collaterals.
- no realistic risk to Protocol Solvency, in practice, accrual occurs frequently through user interactions, keepers, or normal market activity, making the window for sustained insolvency negligible.
The debt ceiling is a limit on the principal borrowed (valued in USD at the time of borrowing) rather than the total outstanding debt including interest due to:
- Gas Efficiency: To update the debt ceiling counter with interest, the protocol would need to roll over the interest for every single borrower using that specific segregated collateral every time anyone interacts with it. This would be extremely expensive in terms of gas.
- Definition of Exposure: The debt ceiling is designed to limit the origination of debt. It is a gatekeeper for how much initial capital can be pulled out against a risky asset. While interest grows the debt, the primary risk the protocol manages with this ceiling is the Bad Debt risk from the initial principal if the collateral's price crashes to zero.
Mainly for the purpose of re-entrancy protection, we will not introduce unnecessary changes that could create risks at this point.
The following categories are not eligible under this bounty program:
• Oracle manipulation that relies on external feeds beyond protocol’s direct control
• Attacks requiring governance/admin role compromise
• Attacks requiring collusion with centralized infrastructure (RPC providers, validators, custodians, etc.)
• Attacks relying on extreme or unrealistic market conditions that cannot occur in practice (e.g., infinite liquidity, oracle returning 0 price permanently)
• Vulnerabilities that have been publicly disclosed, acknowledged, or patched prior to report submission
• Duplicated submissions — only the first valid report will be considered for bounty
The protocol team reserves the right of final interpretation for:
• Determining issue validity
• Assigning severity levels
• Deciding reward amounts within the published bounty framework