Formal Verification
Summary
This report represents work and conclusions based on Term Labs using Certora’s Prover tool to formally verify security properties of Term's smart contracts. Term finalized formal verification of the protocol's smart contracts using Certora's Prover solutions with guidance and technical support provided by the Certora team. The work was undertaken from Dec. 1, 2023 to Mar. 23, 2024. Some of these tests were verified using beta and staging versions of Certora's Prover, which are scheduled to be deployed to their production service in the near future. The latest commit that was reviewed and ran through the Certora Prover was 831292726cdc22e9d4d2953d59051fa00fbd4f72.
The scope of this verification includes all Term Servicer contracts within Term Protocol. This includes the following.
TermRepoToken.solTermRepoLocker.solTermRepoServicer.solTermRepoCollateralManager.solTermRepoRolloverManager.sol
Auction Contracts within Term Protocol were partially verified, with coverage on all functions except for those related to auction clearing, whose loop complexity is too elevated for formal verification. Runtime Verification was previously engaged to focus specifically on auditing and manually verifying this small but critical part of the codebase, see here. Contracts with partial coverage include:
TermAuction.solTermAuctionBidLocker.solTermAuctionOfferLocker.sol
The Certora Prover proved the implementation of the protocol is correct with respect to formal specifications written by the Term Labs team.
List of Main Issues Discovered
Severity: Low
Description:
In the case where a borrower (i) has an outstanding repurchase exposure that (ii) has also been submitted as an open rollover such that (iii) the amount they are able to collapse is 0, the burnCollapseExposure function nevertheless executes, calling 0 transfers and adding 0 to accounting for a burn collapse exposure . Although there is no harm done, this is a waste of gas for the user.
Mitigation/Fix:
Add a revert condition to burnCollapseExposure to revert execution if the max repayment a borrower can make is 0.
Rule coverage:
burnCollapseExposureIntegrity burnCollapseExposureRevertConditions
Disclaimer
The Certora Prover takes as input a contract and a specification and formally proves that the contract satisfies the specification in all scenarios. Importantly, the guarantees of the Certora Prover are scoped to the provided specification, and the Certora Prover does not check any cases not covered by the specification.
We hope that this information is useful, but provide no warranty of any kind, explicit or implied. The contents of this report should not be construed as a complete guarantee that the contract is secure in all dimensions. In no event shall Term, Certora or any of its or their respective employees be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the results reported here.
Overview of the verification
Description of the system
The Term Finance Protocol enables noncustodial fixed-rate collateralized lending on-chain (Term Repos) modeled on tri-party repo arrangements common in TradFi. Borrowers and lenders are matched through a unique recurring auction process (Term Auctions) where borrowers submit sealed bids and lenders submit sealed offers that are used to determine an interest rate that clears the market for participants of that auction. Participants who bid more than the clearing rate receive loans and participants willing to lend below the clearing rate make loans, in each case at the market-clearing rate. All other participants’ bids and offers are said to be “left on the table.” At the conclusion of an auction, borrowers receive loan proceeds and lenders receive ERC-20 tokens (Term Repo Tokens), which are receipts that lenders will burn to redeem for principal plus interest at maturity. Protocol smart contracts service these transactions by ledgering repayments and monitoring collateral health and liquidations.
Description of the specification files
For each contract, spec rules are divided into separate spec files per business logic function type (separate spec for state variable rules), but during runtime are compiled together in a rules.spec file. For the termRepoCollateralManager, the rules.spec is further divided into a rules.spec and other spec files for liquidations and state variables, due to the nature of high verification fun times for those functions.
Assumptions and Simplifications
Some loops were run with a fixed size of 1 in able to enable formal verification. Verifying beyond a 1st loop would have cause formal verification to time out.
Token prices are fetched from a constant mapping in CVL instead of a live price feed. This enables easier comparison of expected calculations and actual token amounts.
Some of the multiplications and divisions in liquidation functions in the smart contracts inherit a contract called
ExponentialNoError, which scales and truncates multiplications and divisions in Solidity in a way that precision is not lost. The calculations in these functions were replaced with CVL equivalents in order to prevent timeouts of FV rules.
Contract Invariants and Rules
Common Rules
Applied to every contract in the protocol.
Rule:
pairTermContractsRevertsWhenAlreadyPaired- constrain input space to only include contracts that have already been paired.
Rule:
onlyPairTermContractsChangesIsTermContractPairedRule- ensures that only pairTermContracts(...) can change state oftermContractPaired
TermRepoToken.sol
Invariant
totalSupplyIsSumOfBalances- ensures that the total supply of tokens always equals the sum of individual account balances, maintaining the principle of token conservation.
Rule:
totalSupplyNeverOverflow- guarantees that the total supply of tokens cannot exceed the maximum value allowed by the system, preventing overflow errors.
Rule:
noMethodChangesMoreThanTwoBalances- ensures that no single operation can alter more than two account balances at once.
Rule:
onlyAllowedMethodsMayChangeAllowance- verifies that changes to token allowances are restricted to approved methods, ensuring that delegated spending limits are securely managed.
Rule:
onlyAllowedMethodsMayChangeBalance- verifies that token balance changes within accounts can only be done through approved methods, preventing unauthorized modifications.
Rule:
onlyAllowedMethodsMayChangeTotalSupply- verifies that changes to the total supply of tokens are conducted only through authorized methods, maintaining supply integrity.
Rule:
reachability- verifies that all non-initialization and non-upgrade methods can be executed, ensuring contract functionality is accessible.
Rule:
onlyAuthorizedCanTransfer- verifies that token transfers can only be initiated by authorized entities.
Rule:
onlyHolderOfSpenderCanChangeAllowance- verifies that changes to spending allowance, which is the limit set by the token holder for how much another account can spend on their behalf, can only be made by the token holder or a designated spender
Rule:
mintTokensIntegrity- ensures that after minting tokens, the balance of the minter and the total supply are correctly increased.
Rule:
mintRedemptionValueIntegrity- ensures that after minting tokens and returning a value, the balance of the minter and the total supply are correctly increased.
where expScale = 10^ 18.
Rule:
mintTokensRevertingConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
mintRedemptionValueRevertingConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
mintRedemptionValueDoesNotAffectThirdParty- verifies that when one account invokesmintRedemptionValue, this action does not affect third-party balances.
Rule:
mintTokensDoesNotAffectThirdParty- verifies that when one account invokesmintOpenExposure, this action does not affect third-party balances.
Rule:
burnIntegrity- ensures that after burning tokens, the balance of the burner and the total supply are correctly decreased.
Rule:
burnAndReturnValueIntegrity- ensures that after burning tokens and returning a value, the balance of the burner and the total supply are correctly decreased.
Rule:
burnRevertingConditions- checks conditions under which a burn operation should revert, such as not having enough balance, the contract being paused, etc.
Rule:
burnDoesNotAffectThirdParty- verifies that burning tokens from one account does not affect third party balances.
Rule:
burnAndReturnValueDoesNotAffectThirdParty- confirms that burning tokens and returning a value from one account does not impact the balance of an unrelated account.
Rule:
transferIntegrity- asserts that after a transfer, the balances of the sender and recipient are updated correctly, respecting the case when sender and recipient are the same.
Rule:
transferIsOneWayAdditive- demonstrates that if a transfer of a combined amount succeeds, individual transfers of the components should also succeed without affecting the final state.
Rule:
transferRevertingConditions- identifies conditions under which a transfer should revert, such as the sender not having enough balance.
Rule:
transferDoesNotAffectThirdParty- ensures that a transfer between two accounts does not affect the balance of a third party.
Rule:
transferFromIntegrity- confirms that after a transferFrom operation, the balances of the holder and recipient are correctly adjusted, and the allowance is updated appropriately.
Rule:
transferFromRevertingConditions- checks for conditions that should cause a transferFrom to revert, such as insufficient allowance or balance.
Rule:
transferFromDoesNotAffectThirdParty- verifies that atransferFromoperation does not impact the balance or allowance of third parties.
Rule:
transferFromIsOneWayAdditive- shows that if atransferFromfor a combined amount is successful, then separatetransferFromoperations for each component of the amount should also succeed, without altering the final state.
Rule:
approveIntegrity- ensures that the allowance is correctly set after an approve operation.
Rule:
approveRevertingConditions- identifies scenarios in which an approve operation should revert, such as when trying to approve from a zero address.
Rule:
approveDoesNotAffectThirdParty- confirms that an approve operation between two parties does not affect the allowance of a third party.
Rule:
onlyAllowedMethodsMayChangeMintExposureCap- ensures that only specific methods can modify the mint exposure cap. Methods like minting, burning, or resetting the cap are allowed to change it.
Rule:
mintExposureCapNeverOverflow- verifies that when the mint exposure cap is increased, this action does not cause it to overflow, ensuring the cap's value remains within safe limits.
Rule:
noMethodChangesRedemptionValue- confirms that the redemption value remains unchanged across transactions, except by methods explicitly intended to modify it. This rule ensures stability in the redemption value.
Rule:
onlyRoleCanCallRevert- checks if a method call that is not a view and requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
onlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermRepoLocker.sol
Rule:
onlyAllowedMethodsMayChangeTransfersPaused- ensures that the state of transfers being paused can only be altered by specific methods designated for pausing or unpausing transfers.
Rule:
noMethodChangesTermRepoId- confirms that the Term Repo ID remains constant and is not changed by any method calls, ensuring its immutability post-initialization.
Rule:
onlyAllowedMethodsMayChangeEmitter- verifies that the emitter's address can only be changed through specific methods, preserving the integrity and security of the emitter identification.
Rule:
onlyAllowedMethodsMayChangeBalance- checks if the treasury balance is correctly updated by allowed methods and remains unchanged by others.
Rule:
reachability- verifies that all non-initialization and non-upgrade methods can be executed, ensuring contract functionality is accessible.
Rule:
transferTokenFromWalletIntegrity- validates the integrity of transferring tokens from the wallet, checking the update in treasury and sender balances post-transaction.
Rule:
transferTokenToWalletIntegrity- ensures the correct adjustment of balances when tokens are transferred to the wallet, factoring in role permissions and pause status.
Rule:
pauseTransfersIntegrity- validates that transfers can be paused correctly by the authorized role, ensuring the state is changed as expected.
Rule:
unpauseTransfersIntegrity- confirms that transfers can be unpaused accurately, reverting the paused state and allowing transactions to proceed.
Rule:
onlyRoleCanCallRevert- ensures that methods not related to initialization, upgrade, or role management only revert if the caller lacks the necessary roles. This rule safeguards against unauthorized actions while allowing legitimate operations.
Rule:
onlyRoleCanCallStorage- verifies that storage modifications by non-view methods are properly guarded by role checks, preventing unauthorized changes to the contract's state. This rule enforces role-based access control for sensitive operations.
TermRepoServicer.sol
Invariant:
totalOutstandingRepurchaseExposureIsSumOfRepurchases- asserts that the total outstanding repurchase exposure is equal to the sum of all individual repurchase exposures, ensuring consistency within the ledger.
Rule:
onlyAllowedMethodsMayChangeTotalOutstandingRepurchaseExposure- specifies that only particular methods can increase or decrease the total outstanding repurchase exposure, aligning changes with expected business logic operations.
Rule:
totalOutstandingRepurchaseExposureNeverOverflows- ensures that actions intended to increase the total outstanding repurchase exposure do not result in an overflow, preserving the integrity of financial calculations.
Rule:
onlyAllowedMethodsMayChangeTotalRepurchaseCollected- identifies methods permitted to increase or decrease the total repurchase collected, ensuring that financial metrics reflect actual repurchase activity accurately.
Rule:
totalRepurchaseCollectedNeverOverflows- verifies that the total repurchase collected metric cannot overflow as a result of any operation, maintaining the system's financial stability.
Rule:
shortfallHaircutMantissaAlwaysZeroBeforeRedemptionAndLessThanExpScaleAfter- confirms the shortfall haircut mantissa remains zero before the redemption timestamp and falls within expected bounds after, ensuring fair and predictable financial adjustments.
Rule:
totalRepurchaseCollectedLessThanOrEqualToLockerPurchaseTokenBalance- ensures that the total repurchase collected does not exceed the locker's purchase token balance, preventing overestimation of collected repurchases.
Rule:
noMethodsChangeMaturityTimestamp- validates that no method changes the maturity timestamp, ensuring consistency in the term's length and financial obligations.
Rule:
noMethodsChangeEndOfRepurchaseWindow- confirms the end of the repurchase window is immutable across all contract interactions, preserving the predetermined timeframe for repurchases, which is critical for contractual agreements.
Rule:
noMethodsChangeRedemptionTimestamp- ensures the redemption timestamp remains constant across all contract interactions, guaranteeing the redemption period's stability and predictability.
Rule:
noMethodsChangeServicingFee- verifies that the servicing fee rate is maintained across all transactions, ensuring consistent fee calculations and financial expectations for parties involved.
Rule:
onlyAllowedMethodsChangeShortfallHaircutMantissa- restricts adjustments to the shortfall haircut mantissa to specific authorized methods, safeguarding the metric's integrity against unauthorized modifications.
Rule:
noMethodChangesPurchaseToken- confirms the purchase token's address remains unaltered through contract operations, ensuring continuity and reliability in financial mechanisms involving the token.
Rule:
onlyAllowedMethodsMayChangeTermContracts- specifies that term contract addresses can only be modified through designated methods, preventing unauthorized updates and maintaining contract ecosystem integrity.
Rule:
onlyAllowedMethodsMayChangeRepurchaseExposureLedger- limits the conditions under which the repurchase exposure ledger can be altered, ensuring that changes are strictly governed and reflect actual repurchase activities.
Rule:
burnCollapseExposureMonotonicBehavior- verifies that burning to collapse exposure reduces the caller's repo token balance, their repurchase obligation, and the total outstanding repurchase exposure monotonically, ensuring systemic risk reduction and individual accountability.
Rule:
burnCollapseExposureIntegrity- ensures that burning for exposure collapse adjusts the repo token balance, repurchase obligation, and total outstanding repurchase exposure by the expected amounts, reflecting accurate and fair financial adjustments.
Rule:
burnCollapseExposureDoesNotAffectThirdParty- confirms that an individual's action to burn repo tokens to collapse exposure does not impact the financial positions (token balances or repurchase obligations) of unrelated third parties, maintaining isolation of financial activities.
Rule:
burnCollapseExposureRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
mintOpenExposureMonotonicBehavior- ensures that minting open exposure increases the minter's repo token balance, their repurchase obligation, and the total outstanding repurchase exposure, as well as the minter's collateral balance, indicating correct operation and accountability in minting activities.
Rule:
mintOpenExposureIntegrity- confirms that minting for open exposure results in expected increases in the minter's repo token balance and repurchase obligation, as well as the total outstanding repurchase exposure, demonstrating the transaction's impact aligns with predefined financial mechanisms.
Rule:
mintOpenExposureDoesNotAffectThirdParty- verifies that a minter's action to open exposure does not alter the repo token balances of unrelated third parties, ensuring the isolation of minting effects within the financial ecosystem.
Rule:
mintOpenExposureRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
redemptionsMonotonicBehavior- verifies that redemption operations result in expected changes to the balances and obligations involved, ensuring that the redeemer's repo token balance decreases, their purchase token balance increases, and the overall repurchase obligations and available tokens within the locker adjust accordingly.
Rule:
redemptionsIntegrity- confirms that the redemption of repo tokens by a redeemer leads to the precise adjustments in the total repurchase collected, the repo token balance of the redeemer, and the purchase token balance in accordance with the redemption value and terms defined, reflecting the accurate financial transaction and impact.
Rule:
redemptionsDoesNotAffectThirdParty- ensures that a redemption action taken by one participant does not inadvertently alter the financial position or balances of unrelated third parties, maintaining the integrity and isolation of individual transactions within the ecosystem.
Rule:
redemptionsRevertConditions- evaluates whether the operation correctly reverts under the prescribed conditions, ensuring compliance with defined contractual behaviors and protections.
Rule:
repaymentsMonotonicBehavior- validates that repayments lead to expected monotonic changes in borrower obligations and system totals, ensuring borrower balances and overall repurchase exposures decrease as payments are made, while the total repurchase collected and potentially the collateral values adjust accordingly.
Rule:
repaymentsIntegrity- ensures the integrity of repayments by verifying that the repayments correctly decrease the borrower's obligations and appropriately adjust the system's repurchase exposure and collected totals, with specific attention to the treatment of collateral in the event of complete repayment.
Rule:
repaymentsDoesNotAffectThirdParty- confirms that a borrower's repayment activity does not inadvertently affect the financial obligations or collateral standings of any unrelated third parties, preserving the isolation and accuracy of individual account statuses within the system.
Rule:
repaymentsRevertingConditions- check if the operation correctly reverts under specified conditions, ensuring adherence to defined contractual behaviors and safeguards.
Rule:
liquidatorCoverExposureIntegrity- validates the integrity of a liquidation process where a liquidator covers the exposure of a borrower using purchase tokens. It checks that balances and obligations adjust correctly, reflecting the liquidation payment in system totals and individual accounts.
Rule:
liquidatorCoverExposureDoesNotAffectThirdParty- ensures that the liquidation process does not inadvertently impact the financial status or obligations of any third parties, maintaining the precision and isolation of account transactions within the system.
Rule:
liquidatorCoverExposureRevertConditions- evaluate if the transaction reverts as expected under identified conditions, ensuring compliance with system rules and safeguards.
Rule:
liquidatorCoverExposureWithRepoTokenIntegrity- examines the proper functioning of liquidation via repo tokens, verifying that such transactions correctly reduce borrower obligations and adjust system and participant balances in accordance with the repo tokens used in the liquidation.
Rule:
liquidatorCoverExposureWithRepoTokenRevertConditions- define conditions that would lead to a transaction revert; aggregate revert conditions to determine expectation; eliquidation attempt with potential revert and validate against expected outcome; ensure actual revert aligns with expectations based on identified conditions.
Rule:
openExposureOnRolloverNewIntegrity- ensures that all relevant balances properly accounted for after opening a repoExposure on account of a successful rollover.
Rule:
openExposureOnRolloverNewDoesNotAffectThirdParty- verifies that rolling over loan exposures from one account does not affect third-party balances.
Rule:
openExposureOnRolloverNewRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
closeExposureOnRolloverExistingIntegrity- ensures that all relevant balances properly accounted for after closing a repoExposure on account of a successful rollover.
Rule:
closeExposureOnRolloverExistingDoesNotAffectThirdParty- verifies that rolling over loan exposures from one account does not affect third-party balances.
Rule:
closeExposureOnRolloverExistingRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
fulfillOfferIntegrity- ensures repoTokens are properly minted to a user's address when their offer is fulfilled.
Rule:
fulfillBidIntegrity- check that the bidder's token balance has decreased and protocol's token balance has increased afterfulfillBid.
Rule:
fulfillOfferRevertsIfNotValid- ensure thatfulfillOfferreverts if not valid.
Rule:
fulfillBidRevertsIfNotValid- ensure thatfulfillBidreverts if not valid.
Rule:
fulfillOfferDoesNotAffectThirdParty- verifies that fulfilling an offer belonging to one account does not affect the third party balances.
Rule:
fulfillBidDoesNotAffectThirdParty- verifies that fulfilling a bid belonging to from one account does not affect the third party balances.
Rule:
lockOfferAmountIntegrity- ensures purchase tokens are properly deducted from a user's address when they lock an offer.
Rule:
unlockOfferAmountIntegrity- ensures purchase tokens are properly transferred to a user's address when they unlock an offer.
Rule:
lockOfferAmountDoesNotAffectThirdParty- verifies that locking an offer belonging to one account does not affect the third party balances.
Rule:
unlockOfferAmountDoesNotAffectThirdParty- verifies that unlocking an offer belonging to one account does not affect the third party balances..
Rule:
lockOfferAmountRevertsWhenInvalid- ensure that locking offers reverts if not valid
Rule:
unlockOfferAmountRevertsWhenInvalid- ensure that unlocking offers reverts if not valid
Rule:
onlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
onlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermRepoCollateralManager.sol
Rule:
auctionLockCollateralIntegrity- ensures that all relevant balances are properly reflected on account of locking collateral when callingauctionLockCollateral
Rule:
auctionLockCollateralThirdParty- verifies that locking collateral belonging to one account when callinglockBiddoes not affect the third party balances
Rule:
auctionLockCollateralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
auctionUnlockCollateralIntegrity- ensures that all relevant balances are properly reflected on account of locking collateral when callingauctionUnlockCollateral
Rule:
auctionUnlockCollateralThirdParty- verifies that unlocking collateral belonging to one account when callingauctionUnlockCollateraldoes not affect the third party balances
Rule:
auctionUnlockCollateralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
journalBidCollateralToCollateralManagerIntegrity- ensures that all relevant balances are properly reflected on account of locking collateral when fulfilling a bid.
Rule:
journalBidCollateralToCollateralManagerThirdParty- verifies that journaling collateral to thelockedCollateralLedgerwhen fulfilling a bid belonging to one account does not affect the third party balances.
Rule:
journalBidCollateralToCollateralManagerRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
externalLockCollateralIntegrity- ensures that all relevant balances are properly reflected on account of locking collateral when callingexternalLockCollateral.
Rule:
externalLockCollateralThirdParty- verifies that locking collateral belonging to one account when callingexternalLockCollateraldoes not affect the third party balances
Rule:
externalLockCollateralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
externalUnlockCollateralIntegrity- ensures that all relevant balances are properly reflected on account of locking collateral when callingexternalUnlockCollateral.
Rule:
externalUnlockCollateralThirdParty- verifies that unlocking collateral belonging to one account when callingexternalUnlockCollateraldoes not affect the third party balances
Rule:
externalUnlockCollateralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
lockerCollateralTokenBalanceGreaterThanCollateralLedgerBalance- verifies the assumption that total collateral token balances is always less than or equal to the balance recorded in ledger
Rule:
onlyAllowedMethodsMayChangeEncumberedCollateralBalances- verifies that changes to the balances of encumbered collateral to specific methods, ensuring that such modifications are controlled and intentional.
Rule:
encumberedCollateralBalancesNeverOverflows- ensure thatencumberedCollateralBalancesnever overflows
Rule:
noMethodsChangeTermRepoId- verifies that termRepoIds are immutable.
Rule:
noMethodsChangeNumOfAcceptedCollateralTokens- verifies that the number of accepted collateral tokens are immutable.
Rule:
noMethodsChangeDeMinimisMarginThreshold- verifies that thedeminimisMarginThresholdis immutable.
Rule:
noMethodsChangeLiquidateDamagesDueToProtocol- verifies that the liquidated damages due to protocol is immutable.
Rule:
noMethodsChangeNetExposureCapOnLiquidation- verifies that thenetExposureCapOnLiquidationparameter of a termRepo is immutable.
Rule:
noMethodsChangePurchaseToken- verifies that the purchaseToken associated with a termRepo is immutable.
Rule:
onlyAllowedMethodsChangeTermContracts- verifies that changes to term contracts addresses are restricted to certain allowed methods.
Rule:
noMethodsChangeMaintenanceCollateralRatios- verifies that maintenance collateral ratios associated with a termRepo are immutable.
Rule:
noMethodsChangeInitialCollateralRatios- verifies that initial collateral ratios associated with a termRepo are immutable.
Rule:
noMethodsChangeLiquidatedDamages- verifies that liquidated damages associated with a termRepo are immutable.
Rule:
onlyAllowedMethodsChangeLockedCollateralLedger- verifies that changes t othe collateral ledger is restricted to certain approved methods.
Rule:
sumOfCollateralBalancesLessThanEncumberedBalances- verifes the assumption that the total sum of all collateral balances is always less than the encumbered collateral balance.
Rule:
batchLiquidationSuccessfullyLiquidates- assert that the locker's balances, the liquidator's balances and protocol reserve's balances have changed by the correct amount afterbathLiquidate
Rule:
batchLiquidateWithRepoTokenSuccessfullyLiquidates- assert that the locker's balances, liquidators balances and protocol reserve blances have changed by the correct amount after callingbatchLiquidatedWithRepoToken
Rule:
batchDefaultSuccessfullyDefaults- assert that the locker's balances, liquidator's balances and protocol reserve balances have changed by the correct amount after callingbatchDefault
Rule:
batchLiquidationDoesNotAffectThirdParty- verifies that liquidating collateral belonging to one account does not affect the third party balances.
Rule:
batchLiquidationWithRepoTokenDoesNotAffectThirdParty- verifies that liquidating collateral usingbatchLiquidationWithRepoTokenbelonging to one account does not affect the third party balances.
Rule: batchDefaultDoesNotAffectThirdParty- verifies that liquidating collateral belonging to one account when callingbatchDefaultdoes not affect the third party balances.
Rule:
batchLiquidationRevertsIfInvalid- ensures thatbatchLiquidatereverts if not valid.
Rule:
batchLiquidationWithRepoTokenRevertsIfInvalid- ensure thatbatchLiquidateWithRepoTokenreverts if not valid.
Rule:
batchDefaultRevertsIfInvalid- ensure thatbatchDefaultreverts if not valid.
Rule:
onlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
onlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermRepoRolloverManager
Rule:
noMethodsChangeTermRepoId- ensures that thetermRepoIdis immutable.
Rule:
onlyAllowedMethodsChangeTermContracts- verifies that changes to term contracts addresses are restricted to certain allowed methods.
Rule:
onlyAllowedMethodsChangeApprovedRolloverAuctionBidLockers- verifies that changes to approved rollover contracts are restricted to certain allowed methods.
Rule:
onlyAllowedMethodsChangeRolloverElections- verifies that changes to rollover elections are restricted to certain allowed methods.
Rule:
electRolloverIntegrity- ensures that all relevant balances are properly reflected when electing to roll-over a loan.
Rule:
electRolloverDoesNotAffectThirdParty- verifies that the action of one account electing to roll over their loan does not impact third-party balances.
Rule:
electRolloverRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
cancelRolloverIntegrity- ensures that all relevant balances are properly reflected when cancelling a roll-over election.
Rule
cancelRolloverDoesNotAffectThirdParty- verifies that the action of one account cancelling their roll over election does not impact third-party balances.
Rule:
cancelRolloverRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
fulfillRolloverIntegrity- ensures that a rollover election is properly marked as processed when fulfilled.
Rule:
fulfillRolloverDoesNotAffectThirdParty- verifies that fulfilling a rollover election submitted by one account does not affect the third party balances
Rule:
fulfillRolloverRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
onlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
onlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermAuctionBidLocker
Rule:
PauseLockingCausesBidLockingToRevert- verifies that pausing locking reverts any attempts at locking bids.
Rule:
UnpauseLockingAllowsBidLocking- verifies that unpausing locking allows users to lock bids.
Rule:
PauseUnlockingCausesBidUnlockingToRevert- verifies that pausing unlocking reverts any attempts at unlocking offers.
Rule:
UnpauseUnlockingAllowsBidUnlocking- verifies that unpausing locking allows users to unlock bids.
Rule:
lockerCollateralTokenBalanceGreaterThanCollateralLedgerBalance- verified the assumption that the total amount of collateral locked is always greater than or equal to the amount recorded in ledger.
Invariant:
LockedBidIdAlwaysMatchesIndex- verifies the assumption that the bidId matches the ledger.
Invariant:
BidCountAlwaysMatchesNumberOfStoredBids- verifies the assumption that the bidCount matches the ledger.
Rule:
LockBidsIntegrity- ensures that collateral token balances are properly transferred to the repo locker when locking bids.
Rule:
LockBidsDoesNotAffectThirdParty- verifies that locking bids belonging to one account does not affect the third party balances.
Rule:
lockBidsMonotonicBehavior- verifies that locking a bid is monotonically increasing in the bid count.
Rule:
LockBidsRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
lockBidsWithReferralIntegrity- ensures that collateral token balances are properly transferred to the repo locker when locking bids with a referral.
Rule:
lockBidsWithReferralDoesNotAffectThirdParty- verifies that locking bids belonging to one account when callinglockBidsWithReferraldoes not affect the third party balances.
Rule:
lockBidsWithReferralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
lockBidsWithReferralMonotonicBehavior- verifies that locking a bid with referral is monotonically increasing in the bid count.
Rule:
UnlockBidsIntegrity- ensures that collateral token balances are properly transferred from the repo locker to the user when unlocking bids.
Rule:
UnlockBidsDoesNotAffectThirdParty- verifies that unlocking bids belonging to one account does not affect the third party balances.
Rule:
UnlockBidsRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
UnlockBidsMonotonicBehavior- verifies that unlocking a bid is monotonically decreasing in the bid count.
Rule:
AuctionUnlockBidIntegrity- ensures that collateral token balances are properly transferred from the repo locker to the user when unlocking bids.
Rule:
AuctionUnlockBidDoesNotAffectThirdParty- verifies that unlocking bids belonging to one account does not affect the third party balances.
Rule:
AuctionUnlockBidRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
AuctionUnlockBidMonotonicBehavior- verifies thatauctionUnlockCollateralmonotonically decreases the bid count.
Rule:
RevealBidsIntegrity- ensures that prices are revealed when revealing bids.
Rule:
RevealBidsDoesNotAffectThirdParty- verifies that revealing a bid belonging to one account does not affect the third party balances.
Rule:
RevealBidsRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
RevealBidsMonotonicBehavior- verifies thatrevealBidsdoes not change the bid count.
Rule:
OnlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
OnlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermAuctionOfferLocker
Rule:
PauseLockingCausesOfferLockingToRevert- verifies that pausing locking reverts any attempts at locking offers.
Rule:
UnpauseLockingAllowsOfferLocking- verifies that unpausing locking allows users to lock offers.
Rule:
PauseUnlockingCausesOfferUnlockingToRevert- verifies that pausing unlocking reverts any attempts at unlocking offers.
Rule:
UnpauseUnlockingAllowsOfferUnlocking- verifies that unpausing unlocking allows users to unlock offers.
Invariant:
LockedOfferIdAlwaysMatchesIndex- verifies the assumption that the offerId matches the ledger.
Invariant:
OfferCountAlwaysMatchesNumberOfStoredOffers- verifies the assumption that the offerCount always matches the ledger.
Rule:
lockerPurchaseTokenBalanceGreaterThanOfferLedgerBalance- verifies the assumption that total purchaseToken balances are always greater than or equal to the amount recorded in ledger.
Rule:
LockOffersIntegrity- ensures that purchase token balances are properly transferred to the repo locker when locking offers.
Rule:
LockOffersDoesNotAffectThirdParty- verifies that locking offers belonging to one account does not affect the third party balances.
Rule:
LockOffersMonotonicBehavior- verifies that locking offers is monotonically increasing in the offer count.
Rule:
LockOffersRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
LockOffersWithReferralIntegrity- ensures that purchase token balances are properly transferred to the repo locker when locking offers with referral.
Rule:
LockOffersWithReferralDoesNotAffectThirdParty- verifies that locking offers belonging to one account when callinglockOffersWithReferraldoes not affect the third party balances
Rule:
LockOffersWithReferralRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
LockOffersWithReferralMonotonicBehavior- verifies that locking offers with referral is monotonically increasing in the offer count.
Rule:
UnlockOffersIntegrity- ensures that purchase token balances are properly transferred to user when unlocking offers.
Rule:
UnlockOffersDoesNotAffectThirdParty- verifies that unlocking offers belonging to one account does not affect the third party balances
Rule:
UnlockOffersRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
UnlockOffersMonotonicBehavior- verifies that unlocking offers is monotonically decreasing in the offer count.
Rule:
UnlockOfferPartialIntegrity- ensures that purchase token balances are properly transferred to user when partially unlocking offers.
Rule:
UnlockOfferPartialDoesNotAffectThirdParty- verifies that partially unlocking offers belonging to one account does not affect the third party balances
Rule:
UnlockOfferPartialRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
UnlockOfferPartialMonotonicBehavior- verifies that partially unlocking offers does not change the offer count.
Rule:
RevealOffersIntegrity- ensures that prices are revealed when revealing offers.
Rule:
RevealOffersDoesNotAffectThirdParty- verifies that revealing offers belonging to one account does not affect the third party balances
Rule:
RevealOffersRevertConditions- check for revert under the defined expected conditions, ensuring operation adherence to defined rules.
Rule:
RevealOffersMonotonicBehavior- verifies that revealing offers does not change the offer count.
Rule:
OnlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
OnlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
TermAuction
Rule:
OnlyRoleCanCallRevert- checks if a method call requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
OnlyRoleCanCallStorage- ensures that changes to storage by non-view method calls can only be performed by addresses with specific roles, guarding against unauthorized modifications.
Rule:
OnlyRoleCanCallRevertCompleteAuctionandOnlyRoleCanCallStorageCompleteAuction- verifies that thecompleteAuctioncall where unrevealed bids exists requires specific roles to execute successfully, does not revert if the caller has the necessary role.
Rule:
OnlyRoleCanCallStorageCompleteAuction- ensures that changes to storage by thecompleteAuctioncall where unrevealed bids exists can only be performed by addresses with the admin role, guarding against unauthorized auction clearing where unrevealed bids exist.
Getting Started
Install certora-cli package with pip install certora-cli. To verify specification files, pass to certoraRun the corresponding configuration file in the [certora/confs](<https://github.com/morpho-org/morpho-blue/blob/2ffb6821815ec542c78e0d0379b5e7094d6fd37a/certora/confs>) folder. It requires having set the CERTORAKEY environment variable to a valid Certora key. You can also pass additional arguments, notably to verify a specific rule. For example, at the root of the repository:
Last updated