BrownFi V2 - Lazy LPing Era is for everyone
BrownFi AMM
0x64f4
July 11th, 2025

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:

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 of the protocol

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.

Admin Roles

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.

Timelock for Effective Settings

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.

Enhancing Resilience of Liquidity Pools

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.

Price and Skewness

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=xPx0−yPy0xPx0+yPy0S=\frac{xP^0_x-yP^0_y}{xP^0_x+yP^0_y}

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

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

{Px=Px0(1−λS)Py=Py0(1+λS) \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 (xPx0≤yPy0)(xP^0_x≤yP^0_y), then the offered prices will be:

{Px=Px0(1+λS)Py=Py0(1−λS)\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.

Adding Liquidity with 50-50 Ratio Requirement

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.

All set!

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.

About Us

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

Subscribe to BrownFi AMM
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.
Arweave Transaction
haDh-Ngj2agBmlp…i_SHxoX_9yvb_L8
Author Address
0xA5576138F067EB8…3164b757DEB2737
Content Digest
QhlhP7rD3eN8COu…XyAM3XGiLVQgI3E