Barker ALM Engine

Demo

About

A market maker's backing capital normally sits idle — it has to be *there* to honour a quote, so it does nothing else. Barker ALM Engine attacks that from two directions, on two venues, with one engine. **Arc leg — Uniswap v4 on Circle's Arc.** A one-sided concentrated liquidity range is an execution primitive, not a yield position. Funded only in the base asset and placed above spot, it is an automatic take-profit ladder: as price rises through it, the position converts to USDC — and it collects trading fees the whole time it waits, which a resting limit order does not. A fully crossed range sells at the *geometric mean* of its bounds, which is worse than a limit order at the top; the fee is what pays for the difference. For exact-input swaps a crossed range realises geometricMean / (1 − fee). On Arc testnet we measured **+0.3008%** over the geometric mean on a 0.30% pool, against a predicted +0.3009% — exact to one part in a million. The Arc leg runs on Arc testnet: a position manager, a dynamic-fee v4 hook, and an unattended keeper. Three full lifecycles are on chain; the second was closed by the keeper on its own key, with the USDC paid straight to the owner. The keeper also found a real bug in our hook: it billed one trade 2.46% for the previous swap's price impact, made four days earlier. We fixed it, redeployed, and replayed the same move on chain — charged 0.30%. Mainnet deployment follows Arc's mainnet launch on Sep 16. **Aqua leg — 1inch SwapVM.** A maker whose inventory sits in an ERC-4626 vault (steakUSDC) earning yield while it quotes. A solvency guard caps every quote at what the vault can actually redeem, and settlement hooks redeem just in time for a payout and re-deposit what comes in, inside the swap. Return = vault APY + spread, and the maker never quotes a fill it cannot settle. Proven on an Ethereum mainnet fork against live steakUSDC. Both legs are on one live dashboard: https://barkermoney.github.io/barker-alm-engine/ This is a Continuity Track entry. Prior work is documented rather than hidden: a pre-hackathon feasibility probe sits unmodified in the initial commit, clearly marked, and everything after it is hackathon work visible in the git history. The proprietary strategy parameters are deliberately not in the repository — what is open is the execution layer. We kept feedback logs for Uniswap and 1inch as we built, including three of our own claims that we retracted in public when our indexer proved them wrong.

How it's made

**Uniswap v4 is the execution primitive, not a bolt-on.** `BarkerV4Positions` drives the PoolManager directly through `unlock`/`unlockCallback` into `modifyLiquidity`, settling with flash accounting (`sync`/`settle`/`take`) and deriving each position's salt from a registry id so two positions on the same range never collide. We deliberately built without `v4-periphery`. Two safety properties are the point of the contract. **One-sidedness is enforced, not assumed**: `open` rejects a range straddling spot by comparing against the live tick, then re-checks after the fact that the pool debited only one asset — the pool's own accounting, not ours. **Custody stays with the position owner**: a keeper may close and collect, but can never name a different recipient, so the worst a compromised keeper does is close a position early into its owner's own wallet. `BarkerDynamicFeeHook` carries `AFTER_INITIALIZE | BEFORE_SWAP`, deployed via CREATE2 salt mining with our own miner (`HookMiner` lives in periphery, which we do not depend on). In `beforeSwap` it measures the previous swap's price impact, dates it to the block that swap happened in, and returns an LP fee override that decays linearly over 300 blocks. The constructor checks its own address against the required flags, because a mis-mined salt otherwise yields a hook that deploys, verifies, and is silently never called. **Automation** is a TypeScript keeper (viem) over a v4 event indexer. v4 keeps every pool in one singleton, so a pool's history is `Initialize`/`ModifyLiquidity`/`Swap` plus `extsload` of `slot0`. The exit rule is a pure function of a snapshot, must hold for three consecutive observations, and runs on its own key. The dashboard runs the same indexer code in the browser (Vite + viem, no backend, no wallet). **Arc (Circle) shaped the tooling.** Arc pays gas in USDC, and its USDC is a native precompile behind an ERC-20 shell that Foundry's EVM does not implement. Since `forge script` simulates the entire script before broadcasting, a USDC-touching script **broadcasts nothing while printing success**. So Foundry does the arithmetic and the pure deployments, and `cast` sends everything that moves tokens. Arc's public node also caps `eth_getLogs` at roughly 25–30k blocks, so the indexer halves its page on rejection. **1inch Aqua / SwapVM** is extended through its two official extension points rather than forked. An `Extruction` guard caps quoted depth at min(virtual reserve, liquid + redeemable, allowance) and scales both reserves together, so it trims depth without moving the price — SwapVM's `ship()` does not itself verify that a maker can cover its quote. `IMakerHooks` does redeem-on-fill and redeposit-on-receive against the ERC-4626 vault. It runs on the signature track, because capital held in the Aqua ledger stops earning. Because SwapVM is source-available copyleft, that code lives in its own directory under SwapVM-1.1, while everything else stays MIT. 103 tests: 43 Foundry tests against a real PoolManager, 45 on SwapVM (11 on an Ethereum mainnet fork against live steakUSDC), 15 for the keeper. **The notable part is what the tests missed.** Our indexer and dashboard, reading real data, caught errors every test had passed: a `feesOwed` view off by 2^128; a hand-copied figure that had us crediting a 0.048% gap to "v4 rounding" (there was no gap); our claim that v4's `Swap` event omits an overridden fee (it carries it); a solvency guard that moved the price instead of the depth; and the fee-hook bug above. Each is fixed or publicly retracted in FEEDBACK.md and FEEDBACK-1INCH.md.