Dear valued users,

BrownFi V1 launched over 3 months ago to address key pain points in LPing, specifically Uniswap V2's low capital efficiency and Uniswap V3's high Impermanent Loss that requires constant monitoring. Our elastic liquidity model has proven effective, generating real revenue for LPs compared to the Buy n' Hold strategy—even despite the decline in $BERA price. Several users have shared their experiences on X:

• Actual PnL of LPing on BrownFi after 2 months

• Jason's LPing portfolio

• Paven's LPing portfolio

Many other early adopters have confirmed similar results. From the takers' side, integrations with Ooga Booga and KyberSwap aggregators have processed $5,502,947 in trading volume across 10,712 unique wallets within just 3 months. This represents approximately $1.8 million in monthly trading volume against only $40k-$50k TVL on BrownFi—clearly demonstrating the platform's exceptional capital efficiency.

These results have strongly motivated us to improve our protocol. Today, we're thrilled to announce BrownFi V2, which makes liquidity providing easier for everyone while maximizing returns with minimal effort.

Let’s dive in V2!

Improving security is the highest priority of BrownFi. In V2, we add another security layers with Oracle Adapter (enables two price sources to ensure reliable price feeds to pair contracts), Admin Roles and Timelock to Effective Setting.

We define three independent admin (setter) roles associated with specific parameter settings: Oracle Price Setter (OracleSetter), Business Setter (BizSetter), and Protocol Supervisor (Pauser). After deployment, the deployer must transfer these roles to appropriate new admin addresses.

• OracleSetter: Acts on a specific pool. This role can set the adapter contract address, price feedID, and minimum valid time for a price update.

• BizSetter: Acts on a specific pool. This role configures pool parameters that align with the pool owners' business goals, including transaction fees, liquidity concentration, and protocol revenue sharing ratios.

• Pauser: Acts on all pools. This role can pause the entire protocol in case of attacks or emerging vulnerabilities.

*No administrator can withdraw funds from liquidity pools.

To prevent accidental and sudden changes in the protocol, we implement timelocks for setting changes before they become effective, with the exception of protocol pausing.

• All admin role changes require a 48-hour timelock to become effective. During this waiting period, the protocol continues to operate using the previous admin addresses.

• All OracleSetter settings require a 48-hour timelock to become effective. During this waiting period, the protocol continues to operate with the old settings.

• The "Pause the entire protocol" setting and all Bizsetter settings are immediately effective.

BrownFi is an AMM that uses oracle pricing to eliminate stale token prices in pools. This approach consistently provides global prices to takers, preventing toxic flow, impermanent loss (IL), and Loss-versus-Rebalancing (LVR) threats common in non-oracle AMMs like Uniswap. The only significant risk when providing liquidity on BrownFi is inventory imbalance, which occurs when market movements cause disproportionate token ratios in pools (e.g., too much ETH but very little USDC in an ETH-USDC pool). Inspired by Uniswap V2's design, which maintains a 50-50 ratio in USD value between tokens all the time, we've implemented several improvements in V2 to reduce this risk and enhance pool resilience as follows.

In V2, we introduce pool skewness that adjusts the oracle-fed price before each swap. The concept is simple: if a swap would increase inventory imbalance, the price becomes more expensive to discourage that trade. Conversely, if a swap would help balance the inventory, the price becomes cheaper to encourage it.

We compute the absolute skewness of the pool as follows:

$S=\frac{xP^0_x-yP^0_y}{xP^0_x+yP^0_y}$

*Where (x,y) are token balances, and $(P^0_x, P^0_y)$ are the oracle-fed prices for token0 and token1 in the pool.

If token0 reserve exceeds token1 reserve $(xP^0_x≥yP^0_y)$, the pool offers a higher price for token0 and a lower price for token1:

$\begin{cases} P_x=P^0_x(1-\lambda S) \ P_y=P^0_y(1+\lambda S) \end{cases}$

If token1 reserve exceeds token0 reserve $(xP^0_x≤yP^0_y)$, then the offered prices will be:

$\begin{cases} P_x=P^0_x(1+\lambda S) \ P_y=P^0_y(1-\lambda S) \end{cases}$

*Where λ is a configurable parameter defined by maximum imbalance target (80-20) of the pool. The default value is λ=0 with a limit range of [0,1].

Unlike V1, BrownFi V2 prevents any trade with the order size ≥ 80% of the reserve from going through (the transaction will be reverted). This protects against inventory depletion from large orders without needing to increase the concentration liquidity parameter Kappa, which would negatively impact pricing for smaller order sizes.

In V1, LPs had to add/remove liquidity according to the USD reserve ratio of the two tokens in the pool. This created poor UX, as LPs needed to calculate this ratio before adding liquidity—a ratio that constantly changed after every swap. Furthermore, these liquidity operations didn't alter the reserve ratio, meaning they couldn't help balance the pool.

In V2, we've improved this process by allowing LPs to add liquidity with a simple 50-50 USD value split, while removing liquidity still follows the V1 method (LPs can manually rebalance to 50-50 after withdrawal if desired). This change creates a better UX and helps rebalance pool reserves more quickly.

These small improvements enhance the resilience of liquidity pools, mitigate inventory imbalance risks, and ensure that pools can quickly rebalance and resume normal operations if the inventory of one token becomes exhausted.

There are some other small improvements in this version 2 you can check in the table below, or refer to this technical document:

With V2, we strongly believe that BrownFi can operate steadily and resiliently with enhanced security layers that maximize returns for LPs through trading fees and price impact premiums. This version marks an important milestone for BrownFi, enabling us to scale to multiple chains and assets for DeFi liquidity providers. We're confidently implementing V2 across 5 EVM chains (Arbitrum One, Base, BNB, Bera and Viction) with several mature trading pairs available at launch:

• ETH - USDC (Arbitrum & Base)

• ETH - USDT (Arbitrum)

• WBTC - ETH (Arbitrum)

• cbBTC - ETH (Base)

• BNB - USDT (BNB chain)

• BERA - HONEY (Bera)

• C98 - VIC (Viction)

• etc.

Additionally, this version allows anyone to create a new pool in a permissionless manner. This process follows a design similar to Uniswap V2, with adaptations to accommodate BrownFi's oracle-based AMM, including setting oracle price feeds and liquidity concentration parameters (Kappa) for specific pairs.

We hope that the team and community members can join forces to make LPing both easy and profitable in the DeFi ecosystem.

BrownFi is an innovative oracle-based AMM, high capital efficiency (like Uniswap V3), flexible & simple LP management for average users, with arbitrage resistance.

• Website: https://brownfi.io/

• Twitter: https://x.com/BrownFidex

• Community: https://t.me/brownfiammcommunity

• Announcement: https://t.me/brownfiamm

Dear valued users,

BrownFi V1 launched over 3 months ago to address key pain points in LPing, specifically Uniswap V2's low capital efficiency and Uniswap V3's high Impermanent Loss that requires constant monitoring. Our elastic liquidity model has proven effective, generating real revenue for LPs compared to the Buy n' Hold strategy—even despite the decline in $BERA price. Several users have shared their experiences on X:

• Actual PnL of LPing on BrownFi after 2 months

• Jason's LPing portfolio

• Paven's LPing portfolio

Many other early adopters have confirmed similar results. From the takers' side, integrations with Ooga Booga and KyberSwap aggregators have processed $5,502,947 in trading volume across 10,712 unique wallets within just 3 months. This represents approximately $1.8 million in monthly trading volume against only $40k-$50k TVL on BrownFi—clearly demonstrating the platform's exceptional capital efficiency.

These results have strongly motivated us to improve our protocol. Today, we're thrilled to announce BrownFi V2, which makes liquidity providing easier for everyone while maximizing returns with minimal effort.

Let’s dive in V2!

Improving security is the highest priority of BrownFi. In V2, we add another security layers with Oracle Adapter (enables two price sources to ensure reliable price feeds to pair contracts), Admin Roles and Timelock to Effective Setting.

We define three independent admin (setter) roles associated with specific parameter settings: Oracle Price Setter (OracleSetter), Business Setter (BizSetter), and Protocol Supervisor (Pauser). After deployment, the deployer must transfer these roles to appropriate new admin addresses.

• OracleSetter: Acts on a specific pool. This role can set the adapter contract address, price feedID, and minimum valid time for a price update.

• BizSetter: Acts on a specific pool. This role configures pool parameters that align with the pool owners' business goals, including transaction fees, liquidity concentration, and protocol revenue sharing ratios.

• Pauser: Acts on all pools. This role can pause the entire protocol in case of attacks or emerging vulnerabilities.

*No administrator can withdraw funds from liquidity pools.

To prevent accidental and sudden changes in the protocol, we implement timelocks for setting changes before they become effective, with the exception of protocol pausing.

• All admin role changes require a 48-hour timelock to become effective. During this waiting period, the protocol continues to operate using the previous admin addresses.

• All OracleSetter settings require a 48-hour timelock to become effective. During this waiting period, the protocol continues to operate with the old settings.

• The "Pause the entire protocol" setting and all Bizsetter settings are immediately effective.

BrownFi is an AMM that uses oracle pricing to eliminate stale token prices in pools. This approach consistently provides global prices to takers, preventing toxic flow, impermanent loss (IL), and Loss-versus-Rebalancing (LVR) threats common in non-oracle AMMs like Uniswap. The only significant risk when providing liquidity on BrownFi is inventory imbalance, which occurs when market movements cause disproportionate token ratios in pools (e.g., too much ETH but very little USDC in an ETH-USDC pool). Inspired by Uniswap V2's design, which maintains a 50-50 ratio in USD value between tokens all the time, we've implemented several improvements in V2 to reduce this risk and enhance pool resilience as follows.

In V2, we introduce pool skewness that adjusts the oracle-fed price before each swap. The concept is simple: if a swap would increase inventory imbalance, the price becomes more expensive to discourage that trade. Conversely, if a swap would help balance the inventory, the price becomes cheaper to encourage it.

We compute the absolute skewness of the pool as follows:

$S=\frac{xP^0_x-yP^0_y}{xP^0_x+yP^0_y}$

*Where (x,y) are token balances, and $(P^0_x, P^0_y)$ are the oracle-fed prices for token0 and token1 in the pool.

If token0 reserve exceeds token1 reserve $(xP^0_x≥yP^0_y)$, the pool offers a higher price for token0 and a lower price for token1:

$\begin{cases} P_x=P^0_x(1-\lambda S) \ P_y=P^0_y(1+\lambda S) \end{cases}$

If token1 reserve exceeds token0 reserve $(xP^0_x≤yP^0_y)$, then the offered prices will be:

$\begin{cases} P_x=P^0_x(1+\lambda S) \ P_y=P^0_y(1-\lambda S) \end{cases}$

*Where λ is a configurable parameter defined by maximum imbalance target (80-20) of the pool. The default value is λ=0 with a limit range of [0,1].

Unlike V1, BrownFi V2 prevents any trade with the order size ≥ 80% of the reserve from going through (the transaction will be reverted). This protects against inventory depletion from large orders without needing to increase the concentration liquidity parameter Kappa, which would negatively impact pricing for smaller order sizes.

In V1, LPs had to add/remove liquidity according to the USD reserve ratio of the two tokens in the pool. This created poor UX, as LPs needed to calculate this ratio before adding liquidity—a ratio that constantly changed after every swap. Furthermore, these liquidity operations didn't alter the reserve ratio, meaning they couldn't help balance the pool.

In V2, we've improved this process by allowing LPs to add liquidity with a simple 50-50 USD value split, while removing liquidity still follows the V1 method (LPs can manually rebalance to 50-50 after withdrawal if desired). This change creates a better UX and helps rebalance pool reserves more quickly.

These small improvements enhance the resilience of liquidity pools, mitigate inventory imbalance risks, and ensure that pools can quickly rebalance and resume normal operations if the inventory of one token becomes exhausted.

There are some other small improvements in this version 2 you can check in the table below, or refer to this technical document:

With V2, we strongly believe that BrownFi can operate steadily and resiliently with enhanced security layers that maximize returns for LPs through trading fees and price impact premiums. This version marks an important milestone for BrownFi, enabling us to scale to multiple chains and assets for DeFi liquidity providers. We're confidently implementing V2 across 5 EVM chains (Arbitrum One, Base, BNB, Bera and Viction) with several mature trading pairs available at launch:

• ETH - USDC (Arbitrum & Base)

• ETH - USDT (Arbitrum)

• WBTC - ETH (Arbitrum)

• cbBTC - ETH (Base)

• BNB - USDT (BNB chain)

• BERA - HONEY (Bera)

• C98 - VIC (Viction)

• etc.

Additionally, this version allows anyone to create a new pool in a permissionless manner. This process follows a design similar to Uniswap V2, with adaptations to accommodate BrownFi's oracle-based AMM, including setting oracle price feeds and liquidity concentration parameters (Kappa) for specific pairs.

We hope that the team and community members can join forces to make LPing both easy and profitable in the DeFi ecosystem.

BrownFi is an innovative oracle-based AMM, high capital efficiency (like Uniswap V3), flexible & simple LP management for average users, with arbitrage resistance.

• Website: https://brownfi.io/

• Twitter: https://x.com/BrownFidex

• Community: https://t.me/brownfiammcommunity

• Announcement: https://t.me/brownfiamm