# \[PROPOSAL\] Omnibus Letter Of Credit Upgrades & Configurations: Implementation Upgrade For Liquidation Refinement, Collateral Factor Globalization, Global Max Token Updates, Dynamic EURC Support **URL:** \ **Category:** Proposals\ **Created:** [August 10, 2026, 2:49pm UTC](https://forum.anvil.xyz/t/proposal-omnibus-letter-of-credit-upgrades-configurations-implementation-upgrade-for-liquidation-refinement-collateral-factor-globalization-global-max-token-updates-dynamic-eurc-support/166 "2026-08-10T14:49:17Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![anvil](https://yyz2.discourse-cdn.com/flex004/user_avatar/forum.anvil.xyz/anvil/32/11_2.png) [@anvil](https://forum.anvil.xyz/u/anvil)\ **Post date:** [August 10, 2026, 2:49pm UTC](https://forum.anvil.xyz/t/proposal-omnibus-letter-of-credit-upgrades-configurations-implementation-upgrade-for-liquidation-refinement-collateral-factor-globalization-global-max-token-updates-dynamic-eurc-support/166/1 "2026-08-10T14:49:17Z")
# Proposal Date 2026-08-13 # Relevant Contracts **LetterOfCredit Proxy:** [0x14db9a91933aD9433E1A0dB04D08e5D9EF7c4808](https://etherscan.io/address/0x14db9a91933aD9433E1A0dB04D08e5D9EF7c4808) **LetterOfCredit Proxy Admin:** [0x12225bB169b38EF8849DD4F5Cc466ae5996e341D](https://etherscan.io/address/0x12225bB169b38EF8849DD4F5Cc466ae5996e341D) **Proposed LetterOfCredit Singleton:** [0x6c22beA8930980C6C5B4f9c449DA0964eDCAa33B](https://etherscan.io/address/0x6c22beA8930980C6C5B4f9c449DA0964eDCAa33B) **PythPriceOracle:** [0xC6f3405c861Fa0dca04EC4BA59Bc189D1d56Ee05](https://etherscan.io/address/0xC6f3405c861Fa0dca04EC4BA59Bc189D1d56Ee05) # Overview Now that the protocol’s Letter Of Credit system has been utilized for a significant period of time, it is warranted to re-examine the functionality and configurations through the lens of user feedback and the latest market data. The project contributors have been collecting feedback from LOC creators, integrators, and liquidators in addition to refining market analysis and risk frameworks. The resulting output has resulted in this omnibus proposal. # Background ## Liquidation Learnings ### Globalization of Collateral Factors Currently, the Governance-set collateral factors that ensure sufficient overcollateralization of dynamic LOCs are stored in the contract state as both global and local (per-LOC basis) variables. When a new LOC is created its health is governed by a memorialized version of the current collateral factor and liquidation incentive. However, this value is version-controlled on the LOC level and is not affected when Governance updates these values globally. This is an intentional design feature but worth re-examining. The benefit of having LOCs governed by locally stored collateral factors is largely for the LOC creator’s user experience. When a new LOC is created, the issuer knows that there is an unchanging ratio at which their LOC could be subject to liquidation as well as the basis points they stand to lose to cover the liquidator’s incentive. While this may provide peace of mind to the LOC creator regarding the exact parameters of the financial promise they are entering into and may allow them not to care about changes to the protocol while their LOC is active, it does come with some significant risk to the protocol writ large. The main tradeoffs of this model involved protocol solvency, Governance impact, and liquidator experience. The first two of these go hand in hand: simply put, if LOCs are grandfathered into the collateral factors at their creation, they prevent Governance from fully doing one of its core functions: protecting protocol solvency. While collateral factors may have been responsibly set at the time of the LOCs creation, digital asset markets are not frozen in time and are often subject to overall large, sometimes unprecedented, swings as well as individual token volatility. While Governance can take action to update these collateral factors globally, it does nothing to impact existing LOCs that may have become unhealthy yet remain uncorrectable via liquidation. This is worth addressing now that the protocol has gotten substantially more usage and risk frameworks have been created to monitor these values in real time. In addition, it is worth considering the experience needed for Governance and liquidators. Governance should be able to protect against changing market conditions on behalf of the entire protocol and not just future LOCs. Also, the most important experience in the dynamic LOC lifecycle is the role of the liquidators. Liquidators play a key role in the solvency of the LOC system and need to be properly incentivized accounting for the latest market competition while experiencing the least development friction and operational complexity possible. A liquidator’s job is made much more difficult by having to monitor every LOC against its specific collateral factor as well as needing to evaluate the benefit of liquidation using LOC-specific incentive values. The result is the clear need to enable global collateral factors as the only governing parameters regarding LOCs health and liquidator incentive. ### Separation of Incentive Values The process of converting the collateral of a dynamic LOC into its credited form can either be the result of: 1) a permissioned action like a beneficiary redeeming a LOC or 2) a permissionless action taken on an unhealthy LOC (where its collateral factor has been exceeded). Both of these scenarios require providing a “liquidator” (in the form of contract address) to execute, however they result from different motivations and processes. The permissioned conversions are initiated on-demand and by the benefiting party; they do not require extra incentive to be initiated. Conversely, the permissionless conversions are often driven by third-parties watching chain data and initiating conversion when a LOC becomes unhealthy. This requires incentivization and is critical to maintaining protocol solvency. Despite the different motivations, both scenarios are currently incentivized the same way: a token-pairing specific “liquidation incentive” that acts as a premium paid to the liquidator for processing the conversion. This creates two issues: 1) it might incentivize a beneficiary to redeem LOCs and act as the convertor, thus keeping excess beyond what is required to fulfill the financial promise and 2) it makes the LOC creator less capital efficient by taking more collateral than is actually necessary for redemption. The solution is to address these paths separately. However, permissioned actions cannot simply provide the liquidation contract without any excess. This is because a portion of the liquidation incentive is used to cover slippage for liquidators that utilize DEXs to execute the conversion. Without any conversion margin, slippage would result in a liquidator either not being solvent to execute the swap or not resulting in a profitable transaction. One of the main goals of the protocol should be to foster a diverse and robust decentralized liquidation environment that encourages redundancy, optionality, and capital efficiency. Taken together, the proposed upgrade is the addition of a fourth collateral factor used specifically for permissioned on-demand conversions that should be set to the conservative cost of DEX swaps without any significant excess. ### Creator Permissioned LOC Conversion The protocol was created with a nice-to-have feature whereby LOC creators can convert their own LOC at any time. The reasoning behind this functionality was to provide maximum flexibility to the creator regarding how they are collateralized. In most instances, it is not economically advantageous for the LOC creator to be liquidated. As a LOC approaches becoming unhealthy, the creator is able to either bolster their collateral or, alternatively, process the conversion themselves keeping the liquidation incentive versus losing value to a third-party liquidator. While this approach certainly considers the LOC creators experience, it does so at the detriment of the liquidators. As discussed, since the permissionless liquidator’s experience should be paramount, allowing the LOC creator permission to front-run their own inevitable liquidation is counterproductive to the overall protocol’s success and should be removed. This finding has been validated via communications with potential liquidators as well as in research that shows that this concept of permissioned self-liquidation is not common with DeFi protocols. ## Integrator Feedback ### LOC Maximums In conversations with integration partners, notably those utilizing the “Promise Now, Pay Later” use case for higher value conference sponsorships, it was learned that the current token configurations for dynamic LOC credited maximums of 100,000 [USDC](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) and [USDT](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7) are insufficient. It is not uncommon for these sponsorships to be in the six figures and it is not preferred to have to split the commitment across multiple LOCs. Increasing these maximums from their initial conservative values at launch is warranted and does not expose the protocol to any undue risk. Note that as the adoption of these LOCs increases, there may be a need to adjust the global maximum of these tokens in the near future. ### Metadata Expansion One of the highlights of Anvil’s adoption with enterprises involves the newly released “institutional beneficiary” tool created by Anvil Research Labs. This enterprise solution maximizes ease of operational integration via, among other things, its customizable display, parsing, and filtering of the metadata “tag” field at LOC creation. The use of this field to memorialize relevant operational data onchain allows businesses to contextualize the LOC’s existence in an easy to leverage way. This field was introduced at the maximum fixed length size (32 bytes) but integrators are requesting additional space. Increasing the potential length of this field by making it dynamic provides much greater flexibility. Since this parameter is only used in the LOC creation event, there is no added cost to protocol users since it is not stored in the contract state. ### EURC Support After receiving [this](https://discord.com/channels/1276592881817354396/1279171443464081499/1495757498613895240) request, ARL was able to confirm that this user is leading the Swiss-based finance startup [Helva](https://helva.finance/). Their model is built to offer fiat consumer loans against Anvil LOCs – one of the protocol’s flagship proposed use cases. Since the protocol currently only supports USD-pegged stablecoins as credited values for dynamic LOCs, it creates an extra level of operational complexity for EU based customers. After evaluating [EURC](https://etherscan.io/token/0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c) as a dynamic credited token against market data and third-party modeling, there emerged reasonable, yet conservative, token configurations and collateral factors that can be implemented to aid in this integration. # Proposed Changes ## Described Changes ### Implementation Changes - Changes `_tag` parameter on `createStaticLOC()` and `createDynamicLOC()` from type `bytes32` to `bytes calldata` - By changing from a fixed 32-byte size to a dynamic length, the amount of metadata that can be appended to a LOC greatly increases. - Expands `CollateralFactor` to include new `redeemBufferBasisPoints` value - Used to differentiate between an amount sent to the liquidator to cover slippage while on demand redeeming vs the cumulative amount sent to cover both slippage and the monitoring incentive. - When `redeemLOC()` is called, `redeemBufferBasisPoints` value is added to the amount sent to the liquidator instead of `liquidatorIncentiveBasisPoints` - Utilizes global `liquidatorIncentiveBasisPoints` when `convertLOC()` is called via the `ILiquidatable` interface. - This value is now only used for permissionless liquidations of unhealthy LOCs. For redemptions, `redeemBufferBasisPoints` is now used - Utilizes global `collateralFactorBasisPoints` when evaluating health of a LOC instead of the value memorialized in the data mapped from the specific LOC id - Removes path whereby a LOC creator can call `convertLOC()` on a healthy LOC - This prevents the front-running third-party liquidators so as to keep them economically incentivized ### Configuration Changes - Updates the USDC and USDT token configurations on `CreditedToken` to increase the `maxPerDynamicLOC` to from 100,000 to 250,000 - Note: Global maximums and LOC minimums remain the same - Adds dynamic LOC credit support for EURC, configuring its `CreditedToken` values - Values are conservative and third-party risk-assessed yet within the usable range provided by the integrator (Helva Finance) - Adds `CollateralFactor`s for every existing dynamic collateral token with EURC as the credited token - These values generated from latest third-party produced model - Adds the stable EURC/USD [Pyth price feed id](https://docs.pyth.network/price-feeds/core/price-feeds/price-feed-ids?search=Crypto.EURC/USD) to the `PythPriceOracle` adapter contract - Requirement for dynamic use ## Executed Changes Calls `LetterOfCredit Proxy Admin`::`upgradeAndCall()` to set the `LetterOfCredit Proxy` implementation to [0x6c22beA8930980C6C5B4f9c449DA0964eDCAa33B](https://etherscan.io/address/0x6c22beA8930980C6C5B4f9c449DA0964eDCAa33B) Calls `LetterOfCredit Proxy::upsertCreditedTokens()` to set: - [USDC](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) - `maxPerDynamicLOC` to `250,000.000000` - [USDT](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7) - `maxPerDynamicLOC` to `250,000.000000` - [EURC](https://etherscan.io/token/0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c) - `minPerDynamicLOC` to `100.000000` - `maxPerDynamicLOC` to `30,000.000000` - `globalMaxInDynamicUse` to `320,000.000000` Calls `LetterOfCredit Proxy::upsertCollateralFactors()` to set: | Collateral Token | Credited Token | Creation Collateral Factor | Collateral Factor (Liquidation) | Liquidator Incentive | Redeem Buffer | | --- | --- | --- | --- | --- | --- | | cbBTC | EURC | 6127 (61.27%) | 7208 (72.08%) | 800 (8%) | 500 (5%) | | cbBTC | USDC | 6000 (60%) | 7100 (71%) | 800 (8%) | 500 (5%) | | cbBTC | USDT | 6000 (60%) | 7100 (71%) | 800 (8%) | 500 (5%) | | sUSDe | EURC | 6922 (69.22%) | 8143 (81.43%) | 800 (8%) | 500 (5%) | | sUSDe | USDC | 7100 (71%) | 8300 (83%) | 800 (8%) | 500 (5%) | | sUSDe | USDT | 7100 (71%) | 8300 (83%) | 800 (8%) | 500 (5%) | | USDC | EURC | 6774 (67.74%) | 7970 (79.70%) | 800 (8%) | 500 (5%) | | USDC | USDT | 7100 (71%) | 8300 (83%) | 800 (8%) | 500 (5%) | | USDC | WETH | 0000 (0%) | 0001 (0.01%) | 800 (8%) | 500 (5%) | | USDT | EURC | 6754 (67.54%) | 7946 (79.46%) | 800 (8%) | 500 (5%) | | USDT | USDC | 7100 (71%) | 8300 (83%) | 800 (8%) | 500 (5%) | | USDT | WETH | 0000 (0%) | 0001 (0.01%) | 800 (8%) | 500 (5%) | | WBTC | EURC | 6078 (60.78%) | 7151 (71.51%) | 800 (8%) | 500 (5%) | | WBTC | USDC | 6000 (60%) | 7100 (71%) | 800 (8%) | 500 (5%) | | WBTC | USDT | 6000 (60%) | 7100 (71%) | 800 (8%) | 500 (5%) | | WETH | EURC | 5901 (59.01%) | 6943 (69.43%) | 800 (8%) | 500 (5%) | | WETH | USDC | 5600 (56%) | 6600 (66%) | 800 (8%) | 500 (5%) | | WETH | USDT | 5600 (56%) | 6600 (66%) | 800 (8%) | 500 (5%) | | wstETH | EURC | 6037 (60.37%) | 7102 (71.02%) | 800 (8%) | 500 (5%) | | wstETH | USDC | 5600 (56%) | 6600 (66%) | 800 (8%) | 500 (5%) | | wstETH | USDT | 5600 (56%) | 6600 (66%) | 800 (8%) | 500 (5%) | Calls `PythPriceOracle`::`upsertPriceFeedIds()` to set [EURC](https://etherscan.io/token/0x1aBaEA1f7C830bD89Acc67eC4af516284b1bC33c) to `0x76fa85158bf14ede77087fe3ae472f66213f6ea2f5b411cb2de472794990fa5c`