I have three Uniswap v4 liquidity positions on Arbitrum. They are not in my wallet.
They live in a contract that is itself a single ERC-721 token. Whoever holds that NFT controls the contract and everything inside it — the positions, the fees they have accrued, the idle balances waiting to be deployed. My own address holds exactly one thing: the token. It has never touched a pool.
That contract is an Envelop LP manager, here mine :
https://unisafe.envelop.is/manager/42161/0x60723973abf3bbc2ce7eb4400b728390d55e264b
These are the exact types of indices that Envelop plans to create in the next phase: Uniswap v4 LP portfolios consolidated into a single transferable token (NFT), designed from the outset to be managed not by a human pressing buttons, but by an AI agent.
"Index" gets used loosely in DeFi, usually meaning a share token over a pooled treasury. This is not that. No pool of other people's money, no share accounting, no NAV, no manager who can walk off with the basket.
An Envelop LP index is one contract, one owner, N positions and its composition is on-chain state, carried by the token's own metadata. The card above is not a render from my UI. It is the token's own image, generated on-chain, by the contract, on request.
Two lineages meet here, and neither one alone gets you an index.
From Uniswap v4 comes the liquidity machinery (amazing Flash Accounting), but not the way most integrations take it. There is no Uniswap PositionManager anywhere in this stack, and no original Uniswap NFT per position. Envelop manager calls PoolManager.unlock() itself and, inside the callback, runs its own modifyLiquidity / swap / settle / take. Positions therefore live raw in the v4 singleton.
From Envelop V2 comes the ownership model. Envelop's wNFT pattern says: a smart-contract wallet whose sole authority root is a single ERC-721. The LP managers reproduce it exactly token id 1, minted once at initialize and never again, and it cannot be burned, so the wallet can never be orphaned. They keep Envelop's escape-hatch signature and its ether-accounting event model, and they emit the discovery events Envelop's indexers already listen for: the factory emits EnvelopV2Deployment, each implementation announces an EnvelopV2OracleType. An Envelop oracle picks up an LP index as just another wNFT type, with no change on the Envelop side.
Worth being precise: this is a hybrid by design, not by inheritance. The managers do not extend Envelop's SmartWallet, they deliberately narrow it. ERC-20 custody only, no rules bitmask, no signature-based execution. What ships on Arbitrum is an EIP-1167 clone: 45 bytes of code at that address.
The punchline is simple. Uniswap's NFT represents a position. Envelop's NFT represents a wallet. Compose them and the NFT represents a portfolio , which is the thing you actually want to own, price and sell.
The short version. Since early 2026, stablecoin issuers have publicly restricted roughly $2B across thousands of addresses. Meanwhile the addresses holding major protocol liquidity are, in practice, unfreezable - freezing them would break market infrastructure, but they are also immobile. You cannot take $100 out of a $7,000 position without your own address appearing in the transaction, and if that address is restricted on USDT, the transaction simply fails.
An NFT-owned wallet pulls those apart: the manager address is the one that interacts with pools, and your address interacts only with the token. Ownership and address exposure stop being the same thing.
To be explicit about what this is not, it's not a mixer and it's not obfuscation. Every transaction stays on-chain and fully traceable, which is the point. Traceability is exactly what a criminal doesn't want.
What is being restored here is unstoppability.
Concentrated liquidity earns fees only inside its range. Pick a narrow band and you earn well until the price walks out of it; then you earn nothing and hold 100% of whichever asset the market was buying from you. That maintenance burden is why most people either provide liquidity across absurdly wide ranges, or quietly stop after a month.
So the index needs an operator and this is where the architecture earns its keep. An Envelop LP manager has an operator role, granted by the owner in one call. Whatever address holds it can call exactly five functions:
allocate · allocateFrom · recenter · claimFees · reinvest
That is the whole surface. An operator cannot withdraw funds to any address. It cannot change the price oracle, add another operator, swap the metadata descriptor, or move the NFT, all of those are gated on holding token #1. The worst realistic outcome of a confused operator is bad positioning and wasted gas, not a drain.
Revocation is one transaction from the owner: setOperator (agent, false). No negotiation, no waiting for the operator to finish what it is doing.
And a detail I like a great deal: on any transfer of the NFT the contract runs _clearOperators() in the same transaction. Sell the index and it arrives at the buyer with no automation attached. They never inherit your agent, and you never have to remember to revoke it.
Adding liquidity in a mediocre range costs you some fees. Swapping at a bad price costs you principal and a rebalance almost always needs a swap, because once you pull a position out the token ratio no longer matches the new bounds. That asymmetry is where an operator role becomes genuinely risky, and it is exactly the hole an internal review round found.
So operator swaps run behind a price-oracle guard that fails closed and does so asymmetrically:
The owner, swapping through their own wallet, is unconstrained. It is their money.
An operator with no oracle wired gets OperatorSwapGuardRequired. With an oracle but no fresh feed for the pair: OperatorSwapUnverified. With a pool price further than maxDeviationBps from the Chainlink reference: PriceOutOfBounds. On Arbitrum a sequencer-uptime gate sits on top, with a one-hour grace period.
maxDeviationBps on my manager is 100 - one percent. Push the pool further than that from the oracle and the rebalance does not happen.
Note the shape of that guarantee. It's not "the operator won't propose a bad swap." It's "a bad swap can't execute at a bad price, no matter who asked for it." The guard is indifferent to whether the caller is confused, compromised or correct and that indifference is what makes it reasonable to hand the keys to a language model. The model is allowed to be wrong, because being wrong does not clear the guard.
The operator on my manager is an AI agent. Not a keeper bot, a conversation with tools attached, over MCP (Model Context Protocol), so any MCP-speaking client can drive it.
The reason it is not a keeper is that a keeper encodes the decision. "Recenter when the price leaves the range, cap slippage at 50 bps" becomes a branch in code, and every refinement a different threshold per pool, don't act during a depeg, skip when gas spikes is another branch and another deploy. As tools, the capabilities are fixed and the policy stays a sentence.
The write path is deliberately split in two:
propose_recenter builds calldata locally, simulates it against current chain state, and returns a decoded plan plus an intent id, nothing signed, nothing broadcast.
execute_recenter(intentId) re-simulates that same intent at the current block, re-checks policy, and only then signs.
That re-simulation is the step usually missing: an Arbitrum block is about a quarter of a second, and between "the agent showed me a plan" and "the plan lands on chain" the world moves. Around it sits a default-deny policy layer the agent can't argue with whitelisted managers per chain, ops-per-hour caps, per-token amount caps, mandatory simulation. The operator key sits in an encrypted keystore on disk and never leaves the process.
Here is the entire life of that index on Arbitrum One:
2026-07-22 03:35 UTC - the factory clones a manager and mints NFT #1 to me.
https://arbiscan.io/tx/0x18b632431a310a9dd8f7d63741e06d08a86e1363c6fd43e0abbbfa53d0e318fc
2026-07-22 09:13–09:15 UTC - I open three positions.
2026-07-25 05:39 UTC - setOperator(agent, true). 0xed7b…fc9ec31
2026-07-25 05:52 UTC - setPriceOracle(...); the guard goes live. 0x86b8…be42a346
2026-07-25 06:24 UTC - the agent recenters. 0x8cea…b5af05
Thirty-two minutes after the guard went live, the agent moved the ETH/USDC 0.05% position: range [-201700, -199700] → [-202060, -200060] - the same 2,000-tick width, shifted 360 ticks down to follow the price. In a single transaction it removed the liquidity, harvested the accrued fees (the protocol took its 10% of those, and only those), swapped 0.000451 ETH for 0.836503 USDC to rebalance the ratio, and re-added at the new bounds. The swap carried a minAmountOut floor of 0.832320 USDC and cleared it by about half a percent. It passed the oracle guard. Total gas: 392,711 units - roughly 1.5 cents.
Now the honest part, which matters more than the demo. That index holds about $24. It's a testbed, not a fund, and I would rather say so plainly than let a screenshot imply managed TVL. One correct recenter is not a track record, it's an existence proof that the chain works end to end: NFT ownership, operator delegation, an oracle guard that fails closed, an agent proposing, and a re-simulation gate letting it through.
What I would point at instead of returns is the shape of the failure mode. The thing to fear in agentic systems is not inaction, it's an agent that finds something to do because doing something is what it is for. An eager LP rebalancer does not earn more fees; it pays gas and crosses the spread on every balancing swap until the position is a slow leak. Most of the time the correct decision is to leave it alone, and most of the time that is what this one does. The threshold is the strategy.
So the reason I am willing to point it at real money has nothing to do with how good the model is. It has to do with what the model is structurally incapable of doing, and how fast I can revoke it.
The manager above is live and readable by anyone, and creating your own costs only gas. There is no deposit or withdrawal fee; the protocol takes 10% of earned fees and nothing else. Stable managers use one frozen range per pool and are low-touch; Volatile ones let you pick ranges and recenter. The agent side is
@envelop/mcp-lp, MIT licensed, one self-contained binary, Node 20+ and you supply the three things nobody else can: an RPC endpoint, your manager address, and an operator keystore.
Ownership stays with the token. Everything else is a delegation you can take back in one transaction.