This SIP proposes to remove the current fee penalty tiers and instead to block fee claims if the user falls below the target c ratio by a specified percentage.
\nThe fee tiers were implemented to encourage SNX holders to return their wallets to the target C ratio, in practice at the current yield no user is willingly incurring any level of fee penalty, so the penalties past 25% are unnecessary. Removing the tiers and blocking fee claims if the ratio falls below a configurable threshold will be simpler and more user friendly as a fee claim will now revert if the ratio changes while the transaction is confirming. This has happened on several occasions already and is neccesitating users paying higher gas fees to ensure fast confirmation times to avoid the risk of a penalty.
\nReducing the complexity of the fee claims process and lowering the required gas for claims transactions will be a net positive for users. The fee tiers were an attempt to implement the fee penalty curve as specified in the original white paper, but empirical evidence suggest this may not have had the intended effect on user behaviour. Users are highly avoidant of fee penalties and so any non-zero fee penalty is likely to result in complete avoidance of claims until the penalty is removed. This change implements this observed behaviour into the system to reduce the risk of lost fees due to long confirmation times and other issues.
\n * @notice Check if a particular address is able to claim fees right now\n * @param account The address you want to query for\n */\n function feesClaimable(address account)\n public\n view\n returns (bool)\n {\n // Penalty is calculated from ratio % above the target ratio (issuanceRatio).\n // 0 < 10%: 0% reduction in fees\n // 10% > above: 100% reduction in fees\n uint ratio = synthetix.collateralisationRatio(account);\n uint targetRatio = synthetix.synthetixState().issuanceRatio();\n\n // no penalty if collateral ratio below target ratio\n if (ratio < targetRatio) {\n return true;\n }\n\n // Calculate the threshold for collateral ratio before penalty applies\n uint ratio_threshold = targetRatio.multiplyDecimal(SafeDecimalMath.unit().add(PENALTY_THRESHOLD));\n\n // Collateral ratio above threshold attracts max penalty\n if (ratio > ratio_threshold) {\n return false;\n }\n\n return true;\n }\nAnd reverting the transaction if the currentPenalty is larger than 0 (Minters will have to fix their C-ratio to be above the penalty threshold to claim fees)
\n internal\n returns (bool)\n {\n require(feesClaimable(claimingAddress), \"C-Ratio below penalty threshold\");\n\n uint availableFees;\n uint availableRewards;\n (availableFees, availableRewards) = feesAvailable(claimingAddress, \"XDR\");\n\n require(availableFees > 0 || availableRewards > 0, \"No fees or rewards available for period, or fees already claimed\");\n\n _setLastFeeWithdrawal(claimingAddress, recentFeePeriods[1].feePeriodId);\n\n if (availableFees > 0) {\n // Record the fee payment in our recentFeePeriods\n uint feesPaid = _recordFeePayment(availableFees);\n\n // Send them their fees\n _payFees(claimingAddress, feesPaid, currencyKey);\n\n emitFeesClaimed(claimingAddress, feesPaid);\n }\n\n if (availableRewards > 0) {\n // Record the reward payment in our recentFeePeriods\n uint rewardPaid = _recordRewardPayment(availableRewards);\n\n // Send them their rewards\n _payRewards(claimingAddress, rewardPaid);\n\n emitRewardsClaimed(claimingAddress, rewardPaid);\n }\n\n return true;\n }\nImplementing a penalty threshold allows for the Collateralisation ratio to fluctuate between a certain percentage below the target issuance Ratio without the transaction reverting.
\nIf the collateralisation ratio for the minter does fall below the threshold, then it can be fixed by burning sUSD debt before attempting to claim fees again.
\nTest cases for an implementation are mandatory for SIPs but can be included with the implementation.
\nThe implementations must be completed before any SIP is given status \"Implemented\", but it need not be completed before the SIP is \"Approved\". While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of \"rough consensus and running code\" is still useful when it comes to resolving many discussions of API details.
\nCopyright and related rights waived via CC0.
"}},"pageContext":{"id":"97fb4f46-26ed-58fe-9042-212ff492cfb2","frontmatter__sip":2,"__params":{"frontmatter__sip":"2"}}},"staticQueryHashes":[]}