EqualFi is a trust minimized DeFi protocol built around Position NFTs and explicit encumbrance. It offers 0% interest self secured loans, solo and community maker AMMs, maker auction markets (MAM curves), physically settled options and P2P Lending. All without Oracles and No Liquidations
WEB: https://equalfi.org
DISCORD: https://discord.gg/brsMNDux4T
MATRIX: https://matrix.to/#/#EqualFiLabs:matrix.org
EqualFi is building the Equalis Protocol. A trust-minimized, permissionless financial stack that deliberately moves away from the core assumptions most of DeFi relies on.
In traditional DeFi, safety and efficiency are enforced through price oracles, liquidation auctions, governance intervention, and a rotating cast of privileged actors. These systems work in calm conditions, but under stress they introduce reflexive failures: oracle manipulation, liquidation cascades, MEV extraction, and discretionary intervention when rules break down.
EqualFi takes a different approach. Instead of reacting to prices, it defines outcomes deterministically. Time, collateral, and explicit accounting replace judgment calls, liquidators, and emergency governance. This philosophy runs through every module in the stack: Self-Secured Credit, P2P Lending, Covered Options (ERC-1155 and P2P), AMM Auctions, and MAM Curves.
Most DeFi protocols tie positions to wallet addresses. Your deposits, your loans, your yield, all bound to the EOA or contract that created them. In Equalis positions are NFTs, and everything associated with a position travels with the token.
When you mint a Position NFT, the system derives a deterministic positionKey from the NFT contract address and token ID. This key becomes your identity within the protocol. All deposits, loans, yield accruals, and encumbrances are indexed by this key, not by your wallet address.
The key insight is that the position key never changes. It is a pure function of (nftContract, tokenId). When you transfer the NFT, the key stays the same, but now a different wallet controls it. The new owner inherits everything: the principal, the accrued yield, the outstanding loans, the locked collateral. There is no migration, no claim process, no admin intervention. Ownership transfer is atomic and complete.
This design unlocks several capabilities that address-bound positions cannot provide:
Positions become tradeable. If you have a position with accrued yield, locked collateral, or favorable loan terms, you can sell the NFT on any marketplace. The buyer gets the full position state, not just a claim on it.
Positions become composable. Smart contracts can hold Position NFTs and operate on them programmatically. A vault can manage multiple positions. A DAO can own lending positions. An options protocol can use positions as collateral backing.
Positions become portable. Moving a position between wallets does not require withdrawing and redepositing. You transfer the NFT, and the position moves with it. This is especially useful for cold storage workflows or multi-sig migrations.
A single Position NFT can participate in multiple pools. When you deposit to a pool, the system records your membership and tracks your principal, yield, and encumbrances per pool. The NFT is the container, the pools are the contexts.
This means one NFT can hold ETH in pool 1, USDC in pool 2, and have active loans in both. The position key is the same across all pools, but the accounting is isolated per pool. You can close your position in one pool without affecting the others.
Pool membership is tracked explicitly. When you deposit, you join the pool. When you withdraw everything and clear all obligations, you can leave. The system enforces that you cannot leave a pool while you have outstanding loans, locked collateral, or pending offers.
The Position NFT system enforces solvency at the position level, not the wallet level. Each position has a loan-to-value ratio that must be maintained. If you try to withdraw principal that would push your position below the required collateralization, the transaction reverts.
Encumbrances are tracked per position per pool. The system knows how much of your principal is locked as collateral, how much is lent out in direct loans, how much is escrowed for pending offers. These encumbrances reduce your available principal for withdrawal but do not affect your total balance.
This granular tracking means the protocol can enforce constraints without blocking unrelated operations. You can withdraw from pool A even if pool B has locked collateral, as long as pool A's solvency is maintained.
Yield accrues to positions based on fee index checkpoints. When fees are collected from borrowers, they are distributed to lenders proportionally. Each position tracks its last checkpoint, and settlement calculates the delta.
Accrued yield sits in a separate bucket from principal. You can withdraw it proportionally with principal, or you can roll it into principal to compound your position. Rolling yield increases your deposit base, which increases your share of future fee distributions.
The yield reserve is pool-level, not position-level. When you withdraw yield, it comes from the pool's yield reserve. If the reserve is insufficient (because yield has been distributed but not yet collected), the withdrawal reverts. This ensures yield claims are always backed by actual collected fees.
The system blocks NFT transfers when the position has open direct offers. This prevents a scenario where you list an offer, transfer the NFT, and the new owner is surprised by an incoming loan or obligation they did not consent to.
This is enforced at the ERC-721 _update hook level. Before any transfer completes, the system checks with the Diamond whether the position has open offers. If it does, the transfer reverts. The owner must cancel their offers before transferring.
For managed pools, the pool manager can enable whitelisting. Only whitelisted position keys can deposit or participate. This allows permissioned pools for institutional use cases, private lending circles, or curated liquidity.
The whitelist operates on position keys, not wallet addresses. This means the manager whitelists specific NFTs, not specific users. If a whitelisted NFT is transferred, the new owner inherits the whitelist status. The manager can revoke whitelist access at any time.
The Position NFT system transforms DeFi positions from static account entries into portable, tradeable, composable assets. Your position is not where you are, it is what you hold. And what you hold can move, be sold, be programmed, or be inherited, all without touching the underlying protocol state.
This is not just a UX improvement. It is a structural change that enables new financial primitives: position markets, position-backed derivatives, position custody services, and position-level risk management. The NFT is the interface, the position key is the identity, the protocol is the ledger.
The EqualFi Flywheel
From this foundation, EqualFi exposes several composable venues:
Self-Secured Credit for rolling and fixed-term borrowing against your own deposits
P2P Lending for direct, negotiated credit between counterparties
Covered Options with ERC-1155 tokenized rights and P2P settlement
AMM Auctions for continuous two-sided liquidity
MAM Curves for programmable, time-varying price schedules
The architecture is designed to extend. Once the core is stable, the same encumbrance and Position NFT primitives can support additional modules: oracle-based isolated lending markets with MAM-curve liquidations, perpetual trading with opt-in LP underwriting, and prediction markets resolved via bonded assertions. These are roadmap items, not promises, but the infrastructure to build them already exists.
Solo Maker AMMs in EqualFi are built for market makers who want tight control, clean accounting, and predictable execution without being forced into a shared pool with strangers. Instead of depositing into a communal AMM and accepting whatever risk, flows, and inventory outcomes the pool delivers, a Solo AMM is position-backed liquidity you control end-to-end.
The biggest advantage is ownership of your flow and inventory. You decide the pair, the sizing, and the exact capital commitment. Your inventory is not diluted by other LPs joining at different times, and you are not exposed to adverse pool composition changes caused by third parties. That means your strategy stays your strategy, not a blended average of everyone who showed up.
Second, Solo AMMs let you express a specific market-making thesis without governance or coordination overhead. If you want to run a narrow spread, short-duration liquidity, or tailor parameters around known flow windows, you can do it directly. There is no need for a DAO vote, no whitelisting gate, and no reliance on external operators to keep conditions healthy.
Third, the system is designed to reduce toxic composability and hidden tail risk. In many AMMs, your LP position becomes entangled with oracle assumptions, liquidation dynamics, and external leverage cycles that can turn normal volatility into a cascade. EqualFi’s model isolates commitments at the position level through explicit encumbrance, so your liquidity is constrained by deterministic accounting rules rather than socialized loss mechanisms.
Fourth, Solo AMMs offer cleaner performance attribution. You can measure fees and outcomes against your own deployed capital rather than estimating your share of a constantly changing pool. That makes it easier to iterate on strategies, manage inventory, and decide when to scale up or shut down.
Finally, Solo AMMs are a natural bridge to more advanced maker behavior. If you want deterministic execution instead of passive curve exposure, you can graduate to Maker Auction Markets (MAM curves) and express time-based pricing directly. If you want to package your market-making strategy, the Position NFT container makes it composable and transferable.
In short: Solo Maker AMMs are for market makers who prefer control over consensus, deterministic accounting over socialized risk, and strategy purity over pooled compromise.
Maker Auction Markets (MAM Curves) are EqualFi’s answer to a simple question: why should market makers be forced to express every strategy through a constant-product curve or a pooled AMM? MAM Curves let makers define a time-varying price curve for selling inventory, turning market making into something closer to a programmable execution desk than a passive liquidity deposit.
At the core, a MAM curve is a linear price schedule between a start price and an end price over a fixed duration. Unlike an AMM where price is a function of reserves and taker flow, a MAM curve’s price is a function of time. That distinction matters. It means the maker defines the trajectory and the risk profile up front, and takers choose when to fill.
If a maker sets startPrice == endPrice, the curve becomes a fixed price schedule for its entire duration. That is economically equivalent to a limit order: “I will sell up to X units at price P.” The curve remains fillable until volume is consumed or the time window expires. This gives makers a native limit-order primitive without needing an order book, matching engine, or external solver logic.
If startPrice > endPrice, the maker is running a classic Dutch auction. Price decreases over time until a buyer accepts. This is extremely useful for inventory liquidation, price discovery when the fair value is uncertain, or when a maker wants to guarantee eventual execution without constantly updating quotes. It also reduces the incentive to snipe with MEV because the price improves mechanically over time rather than jumping due to reserve imbalance.
If startPrice < endPrice, the maker is expressing the opposite: a willingness to sell early at a discount, but demanding a higher price later. This can be used to prioritize early fills, reward immediate flow, or structure “early bird” liquidity that becomes more expensive as time passes. This is useful in volatile markets or when the maker wants a predictable ramp in quote quality.
MAM curves can also simulate iceberg-style behavior through sequencing and volume limits. Because each curve is volume-limited and time-bounded, a maker can post multiple smaller curves rather than one large one, refreshing supply in controlled chunks. The effect is similar to iceberg orders: visible liquidity is capped, total intended liquidity is larger, and the maker avoids advertising full size at once. You can tune this by staggering start times, durations, and price schedules, effectively shaping how the market “discovers” your inventory.
MAM curves are not trying to replace AMM-style liquidity. They complement it.
Think of AMM Auctions as your continuous baseline: a marketable venue with automated price discovery and two-sided flow. MAM curves are your execution toolkit: discrete, intentional, parameterized liquidity deployment.
Together they let makers choose the right tool per situation:
Use AMM Auctions when you want continuous exposure and passive fill behavior
Use flat MAM curves when you want limit-order style precision
Use descending curves when you want guaranteed execution and controlled price discovery
Use ascending curves when you want time-prioritized fills or strategic ramps
Use curve sequences to approximate iceberg supply and control signaling
The result is a maker-first system where “providing liquidity” is no longer one shape. It becomes a set of primitives for inventory management, execution control, and strategy expression, all enforced by deterministic on-chain rules rather than off-chain discretion.
Community AMM Auctions extend the single-maker AMM Auction model to allow multiple makers to pool liquidity into a shared trading venue. Instead of one position providing all the reserves, any number of Position NFT holders can contribute capital and share in the trading fees proportionally. This is the classic pooled AMM model seen in Uniswap and Aerodrome.
A creator initializes a Community Auction by specifying the token pair, initial reserves, time window, and fee rate, just like a regular AMM Auction. The difference is that other makers can join by contributing additional liquidity in the same ratio as the current reserves.
When a maker joins, they receive shares proportional to their contribution (calculated as the geometric mean of their token amounts). These shares determine their claim on the pool's reserves and their share of accumulated trading fees. The system tracks each maker's initial contribution separately, so when they leave, they receive their proportional share of the current reserves plus any accrued fees.
Every swap generates fees that split between makers and the protocol:
The maker share is distributed to all participating makers proportionally via a fee index system. Each maker can claim their accumulated fees at any time, or they are automatically settled when they leave the auction.
The protocol share routes through the standard fee router, Treasury, Active Credit Index, and Fee Index. This means Community Auction volume contributes to the same fee rails that benefit all depositors across the protocol.
Makers' encumbered reserves also earn ACI throughout their participation. Market making in a Community Auction is not just about trading fees, it is an active credit activity that earns from the protocol's reward system.
Makers can join an active auction at any time before it ends, as long as they contribute in the current reserve ratio. This allows liquidity to scale up organically as a trading pair gains traction.
Makers can also leave at any time. When leaving, they receive their proportional share of the current reserves (which may have shifted due to trading) plus their accumulated maker fees. The system handles the accounting automatically, settling fee indices, unlocking encumbrances, and updating principal balances.
If all makers leave, the auction automatically finalizes. The creator can also cancel the auction before it starts if no trading has occurred.
Community Auctions solve the cold-start problem for new trading pairs. Instead of requiring one maker to provide all the liquidity, multiple smaller positions can combine to create a viable trading venue. This lowers the barrier to market making and distributes risk across participants.
The shared fee distribution means smaller makers can participate in market making without needing enough capital to run a solo auction. They contribute what they have, earn proportional fees, and maintain ACI exposure on their encumbered capital.
For the protocol, Community Auctions create another fee generation surface. More trading pairs, more volume, more fees flowing to Treasury, Fee Index, and Active Credit Index. The unified fee rails mean every swap, whether on a solo auction or a community auction, benefits the entire depositor base.
The time-bounded design persists from solo auctions. Makers know exactly when the auction ends, can plan their liquidity commitment, and are not locked into perpetual exposure. When the auction finalizes, everyone gets their share and the capital returns to normal Position NFT status, ready to be deployed elsewhere.
EqualFi's options system answers a question that traditional DeFi has largely ignored: why should options require separate collateral pools, external oracles, or off-chain settlement when the underlying liquidity already exists on-chain?
The OptionsFacet and OptionToken contracts turn existing position capital into options collateral, letting makers write covered calls and secured puts directly against their deposited assets. No new capital lockup. No external dependencies. Just a transformation of idle liquidity into structured derivatives.
When a maker creates an option series, they are not depositing new funds. They are locking a portion of their existing pool position as collateral for the contract. For a covered call, the underlying asset is locked. For a secured put, the strike asset is locked. The system enforces that the maker has membership in both the underlying and strike pools, ensuring the collateral actually exists and is attributable to a real position.
This is economically equivalent to writing a traditional covered call or cash-secured put, but the collateral is already earning yield in the pool until exercise or expiry. The maker does not sacrifice capital efficiency to write options.
Each option series mints ERC-1155 tokens representing the right to exercise. These tokens are fungible within a series but distinct across series. A holder can transfer, sell, or fractionalize their options without touching the underlying collateral.
The OptionToken contract is intentionally minimal. It delegates all minting and burning authority to the Diamond (via the manager role), ensuring that option supply is always backed by locked collateral. There is no way to mint unbacked options. There is no way to burn tokens without the facet's permission. The token is a pure representation of rights, not a standalone asset.
The system supports both American and European style options. American options can be exercised any time before expiry. European options can only be exercised within a configurable tolerance window around expiry.
This distinction matters for pricing and strategy. American options give holders flexibility but expose makers to early exercise risk. European options give makers predictability but require holders to time their exercise precisely. The tolerance window for European options prevents last-block timing games while still enforcing the "at expiry" constraint.
When a holder exercises, the system performs an atomic swap between the holder and the maker's position. For a call, the holder pays the strike amount and receives the underlying. For a put, the holder delivers the underlying and receives the strike amount.
The key insight is that settlement happens entirely within the pool accounting system. The maker's position is debited, the holder receives tokens, and the counterparty's position is credited, all in a single transaction. There is no need for external settlement, escrow, or multi-step workflows.
Fees are charged at exercise and deducted from the incoming payment before crediting the maker. This ensures the protocol captures value at the moment of economic activity rather than requiring separate fee collection.
After expiry, the maker can reclaim any unexercised collateral by burning the remaining option tokens. This requires the maker to hold the tokens, which means either they never sold them, or they bought them back from the market.
Reclaim is not automatic. It requires an explicit action and proof of token ownership. This prevents griefing where a maker could reclaim collateral while tokens are still circulating. If you want your collateral back, you need to own the rights you wrote.
The system supports three fee types: creation fees (charged when writing options), exercise fees (charged when exercising), and reclaim fees (charged when reclaiming unexercised collateral). Each can be configured as a basis point percentage, a flat fee, or both.
Fees are bounded by configurable min and max values, preventing both zero-fee abuse and excessive extraction. Makers can also specify custom fees within bounds when creating a series, enabling competitive pricing for different market conditions.
Most on-chain options protocols require dedicated collateral pools, external price feeds, or complex settlement mechanisms. EqualFi's approach is different: options are a view on existing liquidity, not a separate system.
This means:
Makers do not sacrifice capital efficiency to write options
Collateral continues earning pool yield until exercise
Settlement is atomic and on-chain, no external dependencies
Option tokens are standard ERC-1155, composable with existing DeFi
The same position can back multiple strategies: lending, market making, and now options
The result is a derivatives layer that feels native to the liquidity system rather than bolted on. Options become another tool in the maker's toolkit, not a separate product requiring separate capital.
EqualFi's P2P lending system replaces the reactive liquidation model with explicit, negotiated credit agreements. Instead of pooled lending with hidden parameters and oracle-triggered forced sales, Direct lets lenders and borrowers define the deal: collateral ratios, terms, maturities, payment schedules, and pricing.
Both lenders and borrowers can post offers. This creates a CLOB-style market discovery mechanism where supply and demand meet through explicit terms rather than algorithmic pricing.
Lenders post offers specifying what they are willing to lend, what collateral they require, and under what terms. Borrowers can accept these offers, or post their own offers specifying what they want to borrow, what collateral they are willing to lock, and what rate they will pay. Lenders can then fill borrower offers. This two-sided market lets price discovery happen organically. Borrowers compete for capital by offering better rates, and lenders compete for borrowers by offering better terms.
When an offer is accepted, the system locks the borrower's collateral using the encumbrance system. The collateral never leaves the pool. It is marked as directLocked and cannot be withdrawn until the loan is settled. The lender's capital is marked as directLent. Both sides maintain their Fee Index exposure on unencumbered balances.
Standard offers have fixed principal amounts. A lender offers exactly 10,000 USDC, and a borrower accepts exactly 10,000 USDC. Ratio Tranches remove this constraint.
A Ratio Tranche offer specifies a price ratio (collateral per unit of principal) and a total capacity, but allows partial fills of any size above a minimum. A lender can post "up to 100,000 USDC at 1.4x collateral ratio, minimum fill 1,000 USDC" and borrowers can take 5,000, 20,000, or any amount that fits the constraints. The collateral required scales proportionally with the fill size.
This enables more efficient capital deployment. Lenders do not need to guess exact demand sizes. Borrowers do not need to find offers that exactly match their needs. The market clears at the ratio, not at fixed notional amounts.
Borrowers can also post Ratio Tranche offers from their side by locking a collateral capacity and letting lenders fill variable amounts against it. This completes the CLOB-style market. Both sides can post flexible liquidity, and counterparties fill what they need.
The most powerful feature of Direct is rolling credit. A rolling loan has a term (say, 30 days) and a grace period. At the end of each term, the borrower pays the interest due. If they pay, the loan rolls into the next term. If they do not pay within the grace period, the loan defaults and the lender can claim the collateral.
This is fundamentally different from liquidation-based lending. There is no health factor. There is no oracle watching the collateral value. There is no third-party liquidator waiting to force-close your position at the worst moment. The loan survives market volatility as long as the borrower makes their payments.
This enables what we call perpetual leverage loops: leverage positions that can be maintained indefinitely regardless of market conditions, as long as there is a lender willing to service the loan and a borrower able to make the periodic payments.
Consider a user who wants leveraged exposure to TK1 (an asset they are bullish on) using TK2 (a stablecoin) as the borrowing currency:
User A deposits 2 TK1 into their Position NFT
User B (a lender) posts rolling offers: lend 2,000 TK2 per fill, require 0.5714 TK1 as collateral, 30-day terms
User A accepts the offer, locking 0.5714 TK1 as collateral and receiving 2,000 TK2
User A swaps the borrowed TK2 for TK1 via an AMM Auction
User A deposits the received TK1 back into their position
User A now has more TK1 principal, which can collateralize another loan
Repeat
Each iteration increases TK1 exposure. The leverage is not maintained by a health factor. It is maintained by the borrower's ability to pay the rolling interest. If TK1 drops 50%, the position does not get liquidated. The borrower keeps paying, the loan keeps rolling, and the position survives to recover.
Example: Perpetual Leverage Loop Using Rolling Loans and AMM Auctions
This is perpetual leverage in the literal sense: continuous leverage over time, bounded only by the willingness of counterparties to continue the agreement.
Traditional DeFi leverage is fragile. A flash crash, an oracle delay, a liquidity crunch, any of these can trigger cascading liquidations that wipe out positions that would have been fine if given time to recover. The reactive model punishes users for volatility they did not cause.
Direct's explicit model shifts the enforcement mechanism. Risk does not disappear. It becomes legible. Lenders decide their terms. Borrowers choose deals they can live with. Defaults are handled as defaults, not as third-party extraction opportunities.
For professional lenders, this opens real credit desk workflows: revolving credit facilities, term loans with structured repayment, callable structures, or even undercollateralized credit for vetted counterparties where real-world underwriting exists above the protocol.
For retail users, it means leverage without the constant anxiety of health factor monitoring. You know your payment schedule. You know your terms. You can plan.
Throughout all of this, the encumbrance system ensures isolation. Locked collateral cannot be withdrawn, but it also cannot be rehypothecated or used to back other obligations. The lender's exposure is bounded by the collateral they required. The borrower's exposure is bounded by the loan they accepted.
If a borrower defaults, the lender claims the locked collateral. There is no auction, no slippage, no MEV extraction. The collateral transfers to the lender's position. Clean, deterministic, explicit.
This is credit as it should work: two parties, clear terms, enforceable outcomes, no hidden intermediaries taking a cut when things go wrong.
EqualIndex is a primitive for creating static, fully-backed basket tokens. It is not an actively managed product. There is no rebalancing, no changing weights, no governance committee steering composition over time. An index is defined once at creation and its bundle stays fixed forever. If you want a different basket, you create a different index.
Each EqualIndex token represents a fixed bundle of underlying assets on a 1e18 index unit scale. There is no oracle needed to tell you what the index is worth. Value is determined by deterministic accounting: your pro-rata share of the index vault backing, plus your pro-rata share of accumulated fee pots, minus burn fees.
Minting deposits the exact underlying bundle amounts into the vault and collects per-asset mint fees. Burning redeems your proportional share of the vault and your share of the fee pots, and collects per-asset burn fees. The vault is the NAV backing. The fee pots are where index holders get paid.
Index creation is permissionless, but every underlying asset must already have an Equalis pool. This keeps the system coherent: fee routing has a home, Position integration stays consistent, and indexes remain composable inside the wider protocol.
The fee system is where EqualIndex connects to the broader Equalis economy.
Every mint, burn, and flash loan fee is split into two parts. One part is routed through the standard fee router, Treasury, Active Credit Index, and Fee Index for the underlying asset pools. The rest goes into the fee pot for that asset and accumulates for index holders.
This means:
Pool depositors earn from index activity through Fee Index
Index holders earn from fee pot accumulation realized on redemption
The protocol treasury takes its share
Active credit participants earn ACI from the pool share
A concrete example: an index contains stETH and WETH. You mint 1.0 index unit and the mint fee collected for stETH is 1.00 stETH. If the pool share is 40%, then 0.40 stETH is routed through the fee router into Treasury, ACI, and the stETH pool Fee Index. The remaining 0.60 stETH goes into the index's stETH fee pot. Over time, those fee pots accumulate, and when you burn your index tokens you receive your pro-rata share of the pot alongside your share of the backing vault.
EqualIndex supports basket flash loans. Instead of borrowing a single asset, a borrower can atomically borrow the proportional amounts of every underlying asset that make up a chosen number of index units, use that inventory for arbitrage or multi-leg execution, and return the full basket in the same transaction plus fees.
This turns an index into more than a passive basket. It becomes a deterministic liquidity primitive for bundling and unbundling exposure on demand. Basket flash loan fees follow the same routing model: a configured share goes to the fee router (Treasury, ACI, Fee Index), while the remainder accrues to the index fee pots for redeemers.
EqualIndex creates a new fee generation surface for the protocol. Every mint, burn, and flash loan produces fees that flow back to both index holders and pool depositors. If index products gain adoption, ETH ecosystem baskets, stablecoin diversification indexes, sector exposure tokens, the fee volume compounds across the entire system.
The design is deliberately boring in the right ways: fixed baskets, transparent backing, permissionless creation, deterministic redemption, and fee flows that reward the people who actually supply liquidity and participate in the system. No governance votes to change weights. No rebalancing trades that leak value. No oracle dependencies that can be manipulated.
Just baskets that work, fees that flow, and liquidity that stays unified.
Traditional DeFi treats borrowed capital as a liability. You deposit to earn yield OR you borrow and pay interest. Your capital is either productive or it is being used, never both simultaneously. Equalis inverts this model.
Equalis routes protocol revenue through two separate indices:
The Fee Index is the passive leg. Depositors earn a share of protocol fees proportional to their net equity (principal minus same-asset debt). This is monotonic, account-based yield that accrues automatically. No claiming, no farming, no schedule. Your position simply grows.
The Active Credit Index is the active leg. Capital that is doing work, borrowed, lent, locked as collateral, escrowed in offers, committed to an AMM, earns from a separate reward stream. This rewards participation without diluting passive depositors.
The key design choice: these indices are separate. Pure depositors are not diluted by active credit activity. Active participants are not forced to compete with passive liquidity for the same reward pool. You choose your posture, and the accounting stays coherent.
Equalis allows users to borrow the same asset they deposited at up to 95% LTV with 0% interest. This is possible because the debt is secured by your own principal in the same asset, no oracle required, no liquidation market needed.
But here is what makes it different: the borrowed amount earns ACI.
When you borrow against yourself, you create a "debt state" that participates in the Active Credit Index. The protocol pays you to put capital to work. This transforms self-secured borrowing from "unlocking liquidity" into "creating an additional yield-bearing position."
A user who deposits 100 USDC and borrows 95 USDC now has:
5 USDC of net equity earning passive Fee Index yield
95 USDC of debt state earning ACI yield
95 USDC of liquid capital to deploy elsewhere
The same 100 USDC is earning from two index streams simultaneously.
The encumbrance system is the architectural foundation that makes this possible.
When capital is deployed to a venue, locked as collateral, lent in a P2P agreement, escrowed in an offer, committed to an AMM, it is marked as encumbered rather than transferred. The tokens stay in the unified liquidity pool. Only the internal ledger changes.
This has three consequences:
Unified liquidity: Flash loans, withdrawals, and other pool operations see the full balance. Liquidity is not fragmented across venues.
Gas efficiency: Most operations are ledger moves, not token transfers.
Simultaneous yield: Encumbered capital earns ACI while also earning from whatever venue it is deployed to.
Here is what a sophisticated user's capital deployment can look like:
A user deposits 100 ETH. They self-secured borrow 95 ETH at 0% interest. The debt state earns ACI. They deploy the 95 ETH to P2P lending, where the lent principal earns ACI through encumbrance state, earns interest from the borrower, and platform fees route back to the indices. The remaining 5 ETH of net equity earns Fee Index. The entire balance sheet is contained in a single Position NFT.
The same capital is:
Earning Fee Index (passive depositor yield)
Earning ACI on borrowed amount (debt state)
Earning ACI on encumbered lent capital (encumbrance state)
Earning venue-specific yield (lending interest)
All at once. All from the same deposit.
The Active Credit Index has built-in protections against trivial farming:
A 24-hour time gate requires principal to mature before it contributes to ACI earnings. You cannot flash-deposit before a fee distribution.
Weighted dilution means adding principal to an existing position does not reset your timer to zero. It calculates a weighted average. If you have 100 tokens 20 hours mature and add 100 more, your effective maturity becomes approximately 10 hours.
Zero-principal reset means if your principal hits zero, the state completely resets. You cannot maintain a ghost maturity timer with dust.
Separate index streams mean Fee Index and ACI are independent. Farming one does not dilute the other. Passive depositors and active participants are not competing for the same pool.
Traditional DeFi: Debt is a liability. You pay to borrow. Collateral is locked and idle. Capital is either earning or being used.
Equalis: Debt is an asset class. Borrowed capital earns ACI. Encumbered capital earns ACI. Deposited capital earns Fee Index. Capital can earn from all three simultaneously.
The protocol does not just allow capital to be used. It rewards capital for being used, through a separate index stream that does not dilute passive participants.
This is a fundamentally different capital efficiency model. The same dollar of liquidity can be backing flash loans (unified pool), earning passive yield (Fee Index), earning active yield (ACI on debt), earning active yield (ACI on encumbrance), and earning venue yield (lending interest, perp fees), all at once, all from the same deposit, all contained in a single transferable Position NFT.
The unifying idea behind EqualFi is that capital should remain productive without becoming fragile. By removing reliance on prices, liquidations, and discretion, EqualFi aims to deliver a DeFi stack that is hard to capture, hard to corrupt, and resilient under stress, while still offering capital-efficient primitives that users can compose freely.
Agent Wallet Core: Onchain Authorization for Autonomous Agents
The Position NFT system creates portable, transferable financial positions. Agent Wallet Core extends this by enabling those positions to be operated autonomously with scoped, revocable authorization.
The core problem is straightforward. AI agents are increasingly capable of managing complex financial strategies, but the wallet infrastructure has not kept pace. Today, an agent either gets full private key access, which is dangerous, or no onchain access at all, which defeats the purpose. Neither option works for agents managing real capital.
Agent Wallet Core provides the middle path. Instead of handing an agent a private key, you give it a session key with a policy attached. The policy defines what the agent can do, for how long, with what spending limits. The smart contract enforces the policy at execution time. If the agent attempts something outside its bounds, the transaction reverts. The constraints are protocol-enforced, not trust-based.
Agent Wallet Core composes seven Ethereum standards into a unified account system.
ERC-6551 provides the identity layer. Every account is a Token Bound Account derived from an NFT. For Equalis integration, this means a Position NFT can control a TBA. Transfer the Position NFT and you transfer control of the account, the deposits, the loans, the yield claims, the points, and the agent authorization. Ownership is resolved live from the NFT, never stored.
ERC-6900 provides the modularity layer. All authorization logic lives in installable validation modules. The account contract itself makes no decisions about what actions are permitted. Different modules handle different authorization patterns: owner signatures, session keys, HTTP authentication. Modules can be installed and uninstalled without modifying the core account.
ERC-4337 provides the abstraction layer. Accounts participate in the standard UserOperation mempool via bundlers. This enables gasless transactions, batched operations, and the session key flows that make autonomous operation practical. Agents submit UserOperations signed with their session keys, and bundlers include them in transactions.
ERC-1271 provides signature validation for smart contracts. This allows the account to authenticate to offchain services, which becomes important when agents need to interact with APIs, indexers, or other infrastructure.
ERC-8128 provides HTTP authentication. Agents can sign HTTP requests using their onchain identity and prove to any API that they control a specific account. This bridges the gap between onchain authorization and offchain service access.
ERC-8004 provides agent identity. An account can register as a named agent with metadata in a global registry, making it discoverable by other systems. Other protocols can query the registry to understand who or what controls a given account.
ERC-6492 provides counterfactual signature support. An agent can prove it controls an account before that account is even deployed. This enables gasless onboarding flows where authorization is configured before paying deployment costs.
The practical core of Agent Wallet Core is the SessionKeyValidationModule. This module enables scoped delegation with granular policy controls.
When an owner creates a session policy, they define time windows specifying when the session is valid, with explicit start and end times. They define value limits including maximum value per transaction and cumulative spending budgets. They define target restrictions specifying which contracts the session key can call. They define selector restrictions specifying which functions on those contracts are permitted. They can define per-target rules with fine-grained selector permissions for specific contracts.
When an agent submits a UserOperation signed with a session key, the module validates every constraint. Is the policy active and within its time window? Is the target contract in the allowed list? Is the function selector permitted? Is the value within both per-call and cumulative limits?
If any check fails, the transaction reverts. The agent cannot exceed its policy bounds at the protocol level, regardless of what the agent software attempts.
Owners can revoke a specific session key instantly. They can also revoke all session keys for an account in a single transaction by incrementing an epoch counter. Revocation is immediate and onchain.
The integration between Agent Wallet Core and Equalis is native, not bolted on. A Position NFT can control a Token Bound Account. That TBA can have validation modules installed that scope what actions are permitted. An agent runtime can then operate the position within those bounds.
Consider a concrete example. A user owns a Position NFT with deposits in multiple pools, active loans, and yield claims. They want an agent to manage their MAM curves and roll their Direct loans, but not withdraw funds.
They create a TBA bound to their Position NFT. They install the SessionKeyValidationModule and create a policy for the agent's session key. The policy allows calls to the MAM curve facet and the Direct rolling payment facet, but excludes withdrawal functions. The policy sets a 30-day time window and a cumulative value limit.
The agent runtime receives the session key. It can now sign UserOperations that update MAM curves, make rolling loan payments, and execute strategies within those bounds. It cannot withdraw principal. It cannot exceed its spending budget. It cannot operate past the time window.
If the user wants to pause agent activity, they revoke the session key. Immediate, onchain, no coordination required.
Deterministic settlement matters more to agents than to humans. Agents cannot handle ambiguity the way humans can. They need to know what states are reachable before committing to a strategy. Equalis provides this through time-based settlement, explicit agreements, and absence of oracle-triggered liquidations.
Liquidation-free infrastructure matters more to agents than to humans. An agent operating a leverage loop does not need to worry about a flash crash triggering cascading liquidations. The position survives volatility as long as the rolling payments are made. The agent can reason about its obligations without modeling adversarial liquidation behavior.
Onchain policy enforcement matters more to agents than to humans. If an agent is compromised or misconfigured, the damage is bounded by its policy limits. The smart contract prevents the agent from exceeding its authorization regardless of what instructions it receives.
The combination of Equalis and Agent Wallet Core creates infrastructure designed for a future where the primary users of financial protocols are not humans clicking buttons, but agents executing strategies. The deterministic guarantees, the transferable positions, the scoped authorization, these are features that become essential when the user is a program that needs to reason about its own constraints.
This report summarizes three weeks of intensive development across the Equalis Protocol and Agent Wallet Core infrastructure.
Disclosure: this was generated by claude from git logs
The most significant development this period was the extraction and formalization of Agent Wallet Core as a standalone submodule. What began as Position Agent infrastructure inside Equalis has become a general-purpose onchain authorization framework for autonomous agents.
We implemented comprehensive session key controls through the SessionKeyValidationModule. Owners can now delegate scoped authority to session keys with granular policy enforcement including time windows with explicit start and end bounds, per-call and cumulative value limits, target contract allowlists, function selector restrictions, and per-target inner-selector constraints for fine-grained control.
The module supports all three ERC-6900 validation paths: UserOperation validation for ERC-4337 flows, runtime validation for direct calls, and ERC-1271 signature validation for offchain authentication. Duration-based policy creation was added to simplify common delegation patterns without requiring clients to compute absolute timestamps.
We deployed a beacon proxy pattern for Position Agent TBAs. This enables coordinated upgrades across all deployed agent accounts through a single beacon update while preserving the immutability of individual account addresses. The deployment integrates with the canonical ERC-6551 registry and ERC-4337 EntryPoint v0.7.
The PositionAgentAmmSkillModule received significant expansion. Agents can now finalize solo and community auctions, add liquidity to active auctions, and join community auctions. New policy flags provide owners with granular control over which operations their agents can perform. The module now exposes 15 execution functions with full policy enforcement at the validation layer.
Agent Wallet Core was refactored into a clean standalone repository and integrated back into Equalis as a git submodule. This required removing duplicated ERC-6551 and ERC-6900 code, standardizing import paths to the @agent-wallet-core namespace, and rewiring all deployment scripts and tests. The result is a canonical wallet primitive source that can be used independently or as infrastructure for Equalis Position Agents.
We implemented a complete Module Encumbrance System enabling external modules to lock position capital with protocol-level accounting and fee collection.
The system introduces a fifth encumbrance category alongside direct locked, direct lent, direct offer escrow, and index encumbered. Modules register through a fee-gated permissionless process with governance bypass for trusted modules. Each module maintains independent encumbrance accounting per position per pool.
Modules pay daily AUM fees on their encumbered capital. The LibModuleAum library implements tuple-based accrual with first-touch checkpoint initialization, exact-once treasury routing, and native ETH accounting. Modules that fail to maintain sufficient encumbrance to cover fees enter a grace period leading to permanent deactivation.
Module encumbrance is now included in all solvency calculations. The calculateAvailablePrincipal function accounts for module-locked capital, and pool membership cleanup is blocked when module encumbrance is nonzero. This ensures modules cannot create hidden claims that break position solvency invariants.
Three new facets expose the module system: ModuleRegistryFacet handles registration, ownership transfer, and pause controls. ModuleGatewayFacet provides the encumber, unencumber, and poke entrypoints with proper access control and ACI integration. ModuleViewFacet exposes module configuration, encumbrance totals, and delinquency state for offchain consumption.
We implemented a complete onchain points system designed for future token emissions.
Points accrue to position keys rather than wallet addresses. This means points transfer with Position NFTs, enabling tradeable participation histories. Non-position actions route to the caller's default position, and accounts without positions earn nothing.
The system includes per-action cooldowns preventing rapid-fire farming, daily caps per account limiting extraction, self-match suppression for Direct offer flows, and silent non-accrual behavior that allows transactions to proceed without revealing why points were not earned.
We split coarse action categories into per-entrypoint keys enabling independent tuning of deposits, borrows, repays, offer posts, acceptances, swaps, index operations, and derivatives creation. Each action type has configurable point weights and cooldown periods.
The PointsRedemptionFacet implements burn-to-mint redemption with global and epoch caps. Redemption is disabled by default and can be activated through governance when a token launches. The accounting infrastructure is production-ready and requires no redesign for emissions.
We enforced deterministic fixed-bundle accounting across mint, burn, and flash loan paths. Minting is now deterministic where units deposited equals units minted. Burns and flash loans use fixed bundle amounts rather than NAV-share math, eliminating rounding edge cases.
New minters now pay for their share of accumulated fee pots at mint time. This prevents dilution of existing holders and ensures fee pot value is properly priced into entry. The change required updating both wallet and position mint paths along with IndexToken preview functions.
Native ETH mint paths now revert on refund failure rather than silently retaining user funds. This required adding explicit revert handling and ensuring tracked native accounting rolls back correctly on failure.
The burnFromPosition path now correctly backs fee pot credits with tracked liquidity. Previously, pot credits were added to principal without updating the pool's tracked balance, creating a potential backing gap.
MAM curves now support native ETH as either quote or base token. We relaxed descriptor validation to allow one-side native pairs while still rejecting both-native and same-token configurations. The execution path handles native quote tokens with proper msg.value policy enforcement.
When takers provide more quote than needed, the excess is now refunded rather than credited to the maker. This required reordering the swap flow to finalize accounting before transfers and updating the CurveFilled event to emit net taker spend rather than gross pull amount.
We added centralized msg.value validation through LibCurrency.assertMsgValue, ensuring native and ERC20 paths enforce consistent value semantics. Stray ETH on ERC20 paths now reverts explicitly.
Rolling lender and borrower offers now share a single ID counter with explicit kind tracking. This eliminates the ambiguity of ID collisions and enables kind-based dispatch for accept and cancel operations.
EqualLendDirectAgreementFacet was split to extract ratio-tranche acceptance flows into a separate EqualLendDirectAgreementRatioFacet. This reduces individual facet bytecode size and unblocks deployment on networks with contract size limits.
The bulk cancel path for position transfers now includes rolling lender and borrower offers. Previously these could be orphaned, blocking NFT transfers unexpectedly.
Derivative creation fees now correctly handle native ETH through LibCurrency.decimals rather than direct IERC20 calls. This ensures 18-decimal scaling for native fee tokens.
Option and futures exercise paths now refund excess maxPayment to the payer rather than crediting the maker. This prevents overpayment extraction and aligns with user expectations.
This period included extensive security hardening across the codebase.
We added config validation preventing zero and non-contract addresses in admin setters, zero agentId rejection in registration flows, TBA deployment postcondition checks verifying bytecode existence, and AMM policy bounds validation for duration, fee, and reserve ranges.
New tests cover LibCurrency pullAtLeast overpull behavior, high-cardinality cancel liveness with gas bounds, multi-user module deactivation sequences, and secp256k1 pubkey validation for atomic swap infrastructure.
We added targeted tests for MAM over-cap refund behavior, EqualIndex fee pot dilution scenarios, cross-facet accounting consistency, and trust boundary validation for atomic swap settlement.
Deployment scripts were updated for Arbitrum Sepolia with proper ERC-6551 registry resolution, EntryPoint v0.7 integration, and beacon proxy deployment. Local test chains now deploy mock registries when canonical addresses lack deployed code.
The test runner and GitHub Actions workflow were updated to handle the expanded test suite. Sequential test execution prevents resource exhaustion on CI runners.
We published the protocol whitepaper as PDF and updated documentation across Position Agents, session key delegation, module encumbrance, and EqualIndex semantics.
February has been focused on three major initiatives: extracting Agent Wallet Core as production-ready infrastructure for autonomous agent authorization, implementing the Module Encumbrance System to enable external protocols to build on Equalis liquidity, and hardening the protocol for testnet deployment.
The codebase now exceeds 1,100 tests across unit, integration, property, and fork test suites. Deployment scripts are ready for Arbitrum Sepolia. Agent Wallet Core is positioned as standalone infrastructure while remaining tightly integrated with Equalis Position NFTs.