vfat.io Autopilot

vfat.io has run automated concentrated-liquidity management in production across ~30 live chains and 50+ CL DEXs, with a 24/7 keeper executing rebalances. Current open footprint is $32.1M TVL across 20,238 positions and 8,889 unique users (snapshot 2026-06-16; onchain-verifiable via the Sickle contracts). Keeper throughput is real and onchain-checkable: 16,958 successful rebalances over 180 days across the final seven Aerodrome user pools (refreshed 2026-06-17), 81.6% keeper-automated. The senior build team covers contracts, backend, frontend, metrics/scan, tooling, IT, and operations, and has worked together for roughly four years with prior crypto experience before that. Named founder bios and detailed security-incident history can be provided to Dromos on request.

vfat.io positions itself as the infrastructure/operator team behind Sickle, with hands-on multi-chain contract, router, replay, and monitoring experience. Role coverage spans senior engineering across contracts, backend, and frontend, plus junior engineering support, dedicated IT, operations, metrics/scan, and internal tooling. A function-by-function headcount breakdown can be shared with Dromos directly.

Runway, funding, and investor details are available under NDA. We will disclose the proposal-relevant runway figures and investor list to Dromos reviewers once an NDA is in place, in line with the RFP's runway-disclosure requirement.

$32.1M is managed across ~30 chains with live balances (35 configured); Base leads at $22.3M / 13,231 positions / 5,425 users, followed by Ethereum ($2.15M), Hyper EVM ($1.63M), Arbitrum ($1.42M), Monad ($1.13M), and BNB Chain ($1.12M), with ~17 further smaller chains and 6 configured-but-idle. To be candid, this is vfat.io's automated Sickle user-position footprint, not pooled-ALM-vault AUM (pooled vaults are the product being proposed here), so it should be read as operational scale and chain reach rather than managed-vault returns. The breadth is direct evidence for the RFP's full-footprint / fast-new-chain rollout requirement. Figures are from vfat API and onchain-indexed data as of 2026-06-16.

Integrated with 50+ CL DEXs (57 configured) plus 17 swap aggregators for routing and zaps. Aerodrome is already vfat's single largest venue by managed TVL at $17.3M / 9,622 positions / 4,344 users, ahead of Uniswap v3 at $6.61M; together with Velodrome on Optimism ($1.48M) the Slipstream family totals ~$18.8M, so the team is already running Slipstream-style CL automation at scale on this RFP's exact AMM family. Figures use vfat-managed TVL (userTvl), not each venue's total protocol TVL, and are from vfat API and onchain-indexed data as of 2026-06-16.

An AutopilotRewardLedger tracks per-share xAERO/AERO rewards from gauge claims using per-share accumulators plus per-account reward debt, so rewards follow share ownership. The vault never sells or compounds emissions into LP assets: emissions are excluded from pricePerShare()/totalAssets() principal accounting. The ledger exposes claimableReward(account) for settled, storage-backed balances and pendingReward(account) for claimable plus view-estimated unsettled gauge rewards. Default behavior is in-kind local pass-through (claim()), with optional assisted root redemption (requestRewardRedemption) where gas is charged to the requesting LP, a documented subsidy bucket, or vault policy; a failed redemption never blocks LP principal redeem. When AERO/xAERO is also token0 or token1, reward liabilities are isolated in explicit ledger buckets rather than inferred from raw token balances.

The vault share token is a pro-rata claim on the managed Slipstream position, idle balances, uncollected fees, and the reward ledger; the underlying staked-position NFT stays controlled by the vault/Sickle, not individual LPs. We propose a hybrid: a base vault with ERC-20-transferable shares plus ERC-7540-style two-asset extensions for CL deposits, previews, pending state, and redemptions, which is more honest than claiming strict single-asset ERC-4626 for a two-sided position. An optional ERC-4626-compatible shim (following the PR 826 wrapper concept, which has passing local tests) can wrap vault shares for integrators needing a single-asset surface. The Aerodrome UI integrates directly with the base vault and AutopilotLens so LPs see token0/token1 amounts, range, fee, and reward state rather than a flattened wrapper view. Existing Sickle NftFarmVault already provides ERC-20-style shares and single-NFT-per-pool ownership; the final ERC-7540 base interface and shim packaging are to build.

Material state changes call or require a recent checkpoint: deposits and zaps checkpoint reward and fee state before minting shares, claims checkpoint the claimant's reward state, and rebalances checkpoint before comparing pre/post value and emitting the final result. Redeems checkpoint only what is needed to avoid diluting remaining LPs, while still allowing withdrawal if a reward harvest is temporarily unavailable. Because Slipstream emissions are continuous, accounting uses elapsed-time/gauge accumulators rather than epochs. Views make freshness explicit: each UI value is presented as either guaranteed-fresh as of the latest checkpoint or view-estimated from lazily-settled gauge state, never both. Monthly reports use keeper-enforced checkpoint windows and include the last checkpoint timestamp.

Under pauseChain, deposits/zaps are disabled for emission-bearing vaults (fee-only vaults require policy approval) and only risk-reducing or checkpoint rebalance actions run; local claims are allowed when settlement is safe, while assisted redemption pauses if cross-chain messaging is stale. Under suspendChain, deposits and ordinary rebalances stop except policy-approved emergency wind-down, settled local claims may continue where safe, and assisted redemption is disabled. In both degraded modes the strategy stops assuming fresh emissions and can move toward fee-only/risk-off where policy allows. Critically, the keeper-independent user redeem() path stays available in every mode, so LPs retain the emergency exit without admin, keeper, or Dromos cooperation except where the underlying chain itself is halted. Cap reductions and deposit pauses remain available during degraded modes; cap raises will not execute while registry, gauge, or chain state is stale.

Rebalances are triggered by parameterized range drift, expected value benefit, cooldown, TWAP deviation, slippage, Aero depth, and gas checks, and execution routes only through Aerodrome with route validation rejecting non-Aerodrome liquidity. Protective conditions abort safely with explicit reason codes (for example TWAP_DEVIATION, SLIPPAGE_LIMIT, VALUE_LOSS_LIMIT, INSUFFICIENT_AERODROME_DEPTH, CHAIN_PAUSED) and are counted separately from keeper failures, so reliability measures missed executable rebalances rather than penalizing protective no-execute decisions. Reason-coded events distinguish AutopilotRebalanceExecuted, AutopilotRebalanceSkipped (e.g. cooldown, EXPECTED_BENEFIT_TOO_LOW), AutopilotSafetyAbort, and KEEPER_RETRYABLE_FAILURE. The foundation exists in Sickle's Automation callbacks and value-loss guard; the Aero-only route validation, reason-coded events, and v3 gauge settlement are the to-build work.

We do not pitch one universal CL algorithm; we propose a policy engine with explicit pool classes and parameters. Stable/stable pools run tight ranges, low drift tolerance, and a high time-in-range target; correlated volatile pairs (e.g. ETH/BTC) use medium ranges with a volatility-scaled rebalance threshold; major volatile pairs (e.g. ETH/USDC) get a wider risk budget, explicit IL display, and protective aborts. New-token/one-sided launches use a one-sided or quote-asset deposit path until price discovery and sufficient Aero liquidity, and long-tail intermittent-emissions pools use fee-oriented unstaked mode when emissions are absent or capped and staked mode when emissions justify it. Blue-chip Autopilot vaults stay staked where Aerodrome requires.

Rebalance triggers are expressed as parameters, not narrative rules: current tick distance from target midpoint, percentage of liquidity out of active range, expected APR delta from rebalancing vs hold, max allowed value loss in basis points, minimum expected fee/emission improvement, slippage bound, TWAP-vs-current deviation bound, minimum pool depth and maximum route price impact, cooldown between rebalances, and a gas/fee threshold relative to expected benefit. Execution routes only through Aerodrome. Protective aborts are a first-class feature: when safety checks say a rebalance should not execute, that is not counted as a reliability failure, and skip reasons, safety aborts, and retryable keeper failures should be distinguished by reason code so reporting measures missed executable rebalances rather than penalizing protective no-execute decisions. The final per-pool parameter table is still being finalized.

Our internal metrics-anchored backtest models seven Base Aerodrome Slipstream pools spanning volatile, native AERO, FX, stable, and LST/correlated families (WETH/USDC, WETH/cbBTC, USDC/cbBTC, USDC/AERO, EURC/USDC, USDC/USDT, cbETH/WETH), using the canonical metrics database (farms fees/TVL/emissions) and internal hourly OHLC price paths from the 2026-06-16 run. ALM outperforms pool-average non-ALM LP on the volatile/native/FX pools, and net of impermanent loss the modeled ALM ending USD value beats both a 50/50 hold and a full-range LP on six of seven pools full-window (e.g. WETH/USDC ends $12,646 vs $9,542 hold, +$3,104), with ALM max drawdown no worse than the hold on six of seven; USDC/AERO is the disclosed strong-uptrend trend-IL exception where a passive hold wins. All seven pools clear the 90%-plus strict time-in-range target full-window (95.8%-99.6%); recent-30d six of seven clear it, with the tuned +/-3-tick USDC/USDT peg the lone exception at 86.0% in a choppy window. The candid caveat: the metrics-backed window is about four months (~116 days of aligned history), not the six months the RFP requests, so we either need a metrics backfill or Dromos approval to present the shorter canonical-fee window; net-of-IL baseline tables and the rerun are done, and we will refresh the run date immediately before submission.

No live Sickle-operated ALM vault track record exists yet because Autopilot is the vault product being proposed, so we will not present a 12-month managed-vault APR. The closest evidence is Sickle user-position keeper activity on Aerodrome, framed as operational scale rather than managed-vault return: internal onchain records show 16,958 successful keeper rebalances over 180 days across the final seven-pool set (81.6% keeper-automated), and rolling Base Prometheus telemetry shows ~9,496 successful rebalances over ~30 days, ~69.8% first-attempt success, median time-to-success ~59s, with the durable terminal denominator still to be agreed. This runs under a harder mix than Autopilot should face: thousands of independent user positions with user-selected, sometimes aggressive ranges and thresholds. We deliberately do not headline realized return from the current keeper book, because the internal workpackage finds open-position net performance is IL-dominated and not a clean positive ALM vault track record.

Impermanent-loss and range risk are surfaced in LP docs and UI plus benchmark tables in reporting, with the backtest's net-of-IL cut (C3) as the substance: ending USD value versus a 50/50 hold and a full-range LP per pool, with the per-pool decomposition (principal IL'd, IL effect, income, rebalance cost). The honest disclosure case is USDC/AERO, where a ~47% AERO uptrend means a rebalancing concentrated LP realizes trend-IL and trails a passive hold by -$2,222 full-window even though emissions (+$3,592) nearly offset the -$2,260 IL plus -$1,200 cost. We surface this rather than hide it, and explain the levers (wider band, mode/exposure control). The substance is filled; the remaining work is final proposal chart/table formatting and LP-facing copy.

We use a synthetic WETH/AERO stress test on a $10,000 position for 20%, 50%, and 80% instantaneous AERO moves (WETH held stable), covering band widths of +/-2000, +/-5000, and +/-10000 ticks. It quantifies how band width controls out-of-range behavior and IL versus hold: e.g. at -50% AERO a +/-2000-tick band goes out of range with IL -29.83% (52.6% value retained) while a +/-10000-tick band stays in range at IL -14.54% (64.1% retained). The readout drives the LP-facing risk language: concentrated LPs underperform a simple hold on large directional moves, once price exits the band the position converts heavily to one side and stops earning until rebalanced, and band width is the main risk control (narrow is more productive in calm markets, wide is more resilient to shocks). The scenario math is filled; the remaining work is proposal chart/table formatting.

For new-token or one-sided launches the strategy uses a one-sided or quote-asset deposit path with conservative caps, wider initial ranges, and strict safety checks until price history and Aerodrome depth are adequate for price discovery. This is the new-token/one-sided launch class of the per-pool policy engine, distinct from the blue-chip and peg classes, and it deliberately defers tight concentration until liquidity and price history support it.

Existing Sickle/vfat audit history includes yAudit, Ackee, and Omniscia, with the public audit index at docs.vfat.io/audits. For Autopilot, we commit to an independent Aerodrome-specific audit by a recognized firm or contest provider, with public report and remediation links published. The audit package will include architecture, threat model, deployment scripts, and the exact commit hash. Current working plan is to scope the Aerodrome-specific review with yAudit; exact timing and cost-sharing remain to be confirmed with Dromos.

vfat.io does not currently rely on a public bounty platform, due to prior bad platform experiences, but can add one if Dromos requires a platform-based bounty for Autopilot. We commit to defining an Autopilot vault-contract bounty scope and meaningful maximum reward before launch; platform, funding, and top reward are still to be selected.

Autopilot deployment will be segregated from the rest of the vfat.io ecosystem. Proposed admin posture is a local 3-of-5 multisig, adjusted upward if Dromos requires a stricter threshold, covering all Dromos-supported chains. Signer identities and any individual signer details should be disclosed only under NDA. The exact production signer policy and role split will be finalized with Dromos.

Timelocks will follow the RFP requirements at minimum, with the proposal posture of a 48-hour timelock on parameter changes and a 7-day timelock on upgrades/admin role changes unless Dromos asks for different thresholds. Emergency cap reduction and deposit pause remain available without waiting on the timelocked, dual-approval cap-raise path. The final list of timelocked functions and any per-chain exceptions still need to be documented.

We commit to source verification and reproducible builds on every supported chain. The exact verification flow and a reproducible-build command are being documented per chain before submission.

User redeem() is the non-custodial emergency withdrawal path and remains available without admin or keeper cooperation, including during pauseChain and suspendChain states. The redeem behavior, including checkpointing only what is needed to avoid dilution while preserving exit when a reward harvest is temporarily unavailable, is designed and specified. Tests proving redeem() stays available without admin/keeper cooperation are still to be built, alongside UI copy and runbook documentation of this path.

Proposed keeper model: redundant keeper nodes across at least two providers/regions, independent RPC providers plus vfat-owned fallback RPC where available, and health checks for pool state, gauge state, gas, nonce, route simulation, and settlement freshness. Alerting escalates to an on-call rotation with escalation to Dromos, and execution emits reason-coded events for execution, skip, abort, retry, and incident states. This builds on production automation already monitored in Grafana/Prometheus; current Base rebalance telemetry shows roughly 9.9k successful rebalances, about 70% first-attempt success, median time-to-success around one minute, and 98%+ of eventual successes within ten attempts. Final submission needs a fresh query and an agreed denominator that counts only rebalances that should have executed, reporting protective aborts separately.

Draft SLA: public acknowledgement within 1 hour for LP-impacting events, mitigation updates while the incident is open, and root cause analysis within 72 hours. Strategy, admin, or key changes and abnormal keeper failures trigger immediate Dromos notification. A public security contact, emergency cap reduction, and deposit pause are part of the playbook, with user redeem() as the standing emergency exit. The incident response runbook itself still needs to be produced.

Insurance/coverage status is partially filled: vfat.io can state that coverage is through OpenCover if approved for external disclosure. The remaining step is to confirm the exact coverage details that are safe to share, including scope, limits, covered contracts/products, and any exclusions. If those details are not approved before submission, we should disclose only the high-level coverage posture and avoid implying protection beyond the confirmed terms.

Known disclosure: vfat.io operates general-purpose automation infrastructure across ~30 chains and 50+ CL DEXs, and current DEX integrations are listed in the team footprint evidence. That breadth is not an Autopilot vault conflict by itself because the proposed Autopilot vaults commit to an Aerodrome-only capital path: no routing LP capital to competing AMMs and no mixed positions under one share token. The remaining conflict disclosure is itemized business-relationship detail: token issuer, market maker, curator, and any commitments that could restrict Aerodrome-specific support.

The code license / IP terms for the Autopilot vault contracts, for example open-source versus source-available, are available under NDA pending founder sign-off. We will confirm the chosen license before submission.

All vault state renders from contract reads with no wallet and no partner API in the path: pricePerShare(), currentCapValue() (TVL), balanceOf() (user shares), and the exact owed token0/token1 via a callStatic redeem() simulation rather than an estimate. Pool price (slot0), the position's in-range/out-of-range state (NFPM.positions ticks vs slot0.tick), and harvest claimable (callStatic claim()) are all read live through a same-origin /rpc JSON-RPC proxy. Deposit/zap/withdraw/claim call the vault directly (deposit / depositWithZap / redeem / claim); vfat-api quote endpoints are advisory only (minShares / route), so the transaction is built against the contract, not relayed as opaque calldata. Still data-service today: APR, rewards-per-week, and the 12-month historical charts; for a 2.1-strict surface these move to gauge/pool views plus event derivation via the proposed AutopilotLens.

Live and screenshotted: deposit either pool token (auto-zapped through the vault's own Aerodrome pool, route factory-validated) or both, with a live share-output preview. Verified on Base with real transactions, each confirmed by a share-balance change, including a fresh zap into the newly deployed USDC/cbBTC vault (shares 7840 to 9768). The shareable interface presents the Aerodrome-only token0/token1 deposit path for this proposal.

The in-range badge is onchain-derived: the position's range state is computed from NFPM.positions ticks compared against the live pool slot0.tick, read with no wallet through the /rpc proxy. This is shown across the 12-vault browse and per-vault detail. The closely related rebalance-pending state (range crossed, rebalance queued) is not yet built.

These are the remaining LP states not yet in the interface preview: rebalance pending (out-of-range, rebalance queued), safety abort / rebalance skipped, and emergency-exit copy. The wording for protective rebalance aborts is already defined (an LP should understand a skipped rebalance can be the safe outcome, and that Aerodrome-only routing can limit certain rebalances), and reason-coded rebalance/abort/skip events are planned on the contract side; the LP-facing screens themselves still need to be produced.

Withdraw is live and screenshotted as a keeper-independent redeem() back to pool tokens; the documented ungated redeem() is the emergency-withdrawal path that requires no admin or keeper cooperation. The position screen shows the stake in USD plus token0/token1 plus shares, computed exactly via the same redeem simulation. The dedicated emergency-exit framing/copy (exit via the normal withdraw/redeem even when a chain is paused or a harvest is unavailable) still needs to be written.

Live and screenshotted on the WETH/USDC harvest vault (reward token AERO): emissions are not folded into LP principal but stream to LPs as a per-share claimable balance. The UI reads live claimable via a callStatic claim() simulation and exposes a Claim button (vault.claim(receiver)), tagged harvest / claimable. All 12 deployed vaults are the bid-accurate non-compounding NftFarmHarvestVault, so this surface directly demonstrates the §2.2 no-compounding requirement; a pending-vs-settled reward split refinement is the remaining polish.

The education substance is now filled: Autopilot must not be marketed as risk-free passive income. LP copy should explain concentrated-liquidity range risk, impermanent loss, volatile/new-token pool behavior, why a rebalance may be safely skipped, why Aerodrome-only routing can limit some rebalances, why emissions are claimable rather than auto-compounded into LP assets, and how xAERO redemption works and who pays gas (requesting LP or vault policy). This is grounded in the backtest's net-of-IL baseline cut, including the USDC/AERO trend-IL case where a concentrated ALM trails a passive hold, and the WETH/AERO 20/50/80% stress test. The remaining work is polished LP-facing documentation and interface copy.

We accept the RFP's alignment model as workable but not preferred: partner compensation through baseline sAERO revenue rights, with product fees initially routed to Aerodrome's Momentum Fund rather than directly to us. Preferred economics are a 50/50 fee split from day one, subject to Dromos negotiation. Current vfat.io fee references are 0.09% on zap in/out, 0.01%-0.05% on rebalances depending on pool fee, 1.2% on harvest, and 1.8% on compound; Autopilot fees can be configured by vault over time. Final commercial constraints are available under NDA.

We treat Autopilot as a flagship product and will commit to a public LP education and reporting cadence, with weekly reporting through a shared channel. Candidate co-marketing schedule: joint launch announcement, technical architecture post, LP risk and strategy explainer, monthly performance/report post, pool-class education thread, and quarterly product roadmap update. We ask Dromos in return for UI placement, emissions support, BD/marketing collaboration, and a shared marketing/BD calendar. Disclosable marketing reach metrics are still being assembled.

The channel-conflict frame is filled: Sickle supports many venues as general infrastructure, whereas Autopilot vaults never route Aerodrome LP capital to non-Aerodrome AMMs, honoring the RFP's Aerodrome-only capital path. Existing DEX integrations are public in the footprint section and should be disclosed as operating breadth, not hidden. The final itemized conflict disclosure still needs the sensitive relationship list: token issuers, market makers, curators, commitments that restrict Aerodrome-specific support, and whether any existing product routes LP capital to competing AMMs outside the Autopilot scope.

We ask for a 50/50 split on Aero v3-specific audit cost, with quote and scope TBD, plus a chain-rollout SLA that accounts for audit and deployment dependencies on each new chain. This reflects the RFP risk that a tier-1 audit and bug bounty may need shared funding or a compressed schedule. Backup ask and final audit-plan envelope still need to be confirmed with Dromos.

Rather than open-ended economics, we propose a concrete milestone schedule where each milestone can unlock additional sAERO revenue rights subject to the RFP performance gates: baseline revenue rights begin at agreement signing; milestone 1 is the first five blue-chip pools live and reporting; milestone 2 is sustained useful TVL plus risk-adjusted outperformance over 90 days; milestone 3 is multi-chain rollout completed for the launch footprint; milestone 4 is product revenue exceeding the baseline subsidy for a defined period. The kicker is tied to useful TVL and revenue, not raw TVL alone. The exact sAERO unlock amounts per milestone need to be agreed with Dromos.

After the 6-9 month bootstrap window, milestone 4 triggers the shift from subsidized baseline to a profit split once product revenue exceeds the baseline subsidy for a defined period. We will define a maintenance-level calculation for ongoing keeper operations, support, and multi-chain coverage beyond that window. We also need to settle treatment of selected-partner Aero v3 code access expected around July 2026, which gates how fast we can ship post-launch chain rollouts.

We propose a set of vendor-neutral interface conventions any ALM provider could implement, so the Aerodrome UI can render every Autopilot-style vault from onchain state alone: a standard vault read surface (identity, position, shares/caps, fees/rewards, strategy, operations, reporting), an AutopilotLens batch getter with each field derivable from public vault/gauge state and events, and a reward-entitlement pair of claimableReward(account) for settled balances and pendingReward(account) for view-estimated unsettled gauge rewards. We also propose reason-coded keeper events (AutopilotRebalanceExecuted/Skipped, AutopilotSafetyAbort, AutopilotModeChanged, AutopilotCapsChanged, plus reward checkpoint/claim/redemption events) with a shared reason-code vocabulary (e.g. COOLDOWN_ACTIVE, TWAP_DEVIATION, SLIPPAGE_LIMIT, VALUE_LOSS_LIMIT, INSUFFICIENT_AERODROME_DEPTH, CHAIN_PAUSED/SUSPENDED, REGISTRY_STALE, GAUGE_SETTLEMENT_STALE, KEEPER_RETRYABLE_FAILURE) so protective aborts are counted separately from keeper failures. Strategy metadata fields (version, params hash, pool-class label, target range, slippage/value-loss limits, keeper status) round out the standard so reporting and reliability scoring are comparable across providers.

The remaining build is scoped and tracked: define the final share standard and build the Aero v3 gauge/xAERO adapters once ABIs are shared; implement the per-LP reward ledger with token-overlap and gas accounting for optional root redemption; add reason-coded keeper events, Aerodrome-only route validation, and the AutopilotLens batch getter; write the formal dual-approval cap-controller flow; verify the existing keeper-independent redeem() as the documented emergency exit; and build the pause/suspend, lazy-settlement, cap-change, and dynamic-fee test harness (including MetaDEX03 mocks and BASE_RPC fork tests). Foundations already merged or prototyped include PR 855 stake/unstake mode and the PR 826 ERC-4626 shim concept. Sequencing and dated milestones depend on confirmed submission timing against the June 24 deadline and on Dromos sharing the Aero v3 interfaces (expected around July 2026), so we will commit firm ship dates as soon as those inputs land.

To finalize and de-risk delivery we ask Dromos to: confirm submission format and sharing permissions for the June 24 deadline; share selected-partner Aero v3 gauge, xAERO, TokenRegistry, pauseChain, and suspendChain ABIs/source as early as possible (code may be shared with selected partners around July 2026); confirm the blue-chip pool set and fee tiers for backtests (deep majors such as WETH/USDC, BTC/USDC, ETH/BTC, and stables at primary fee tiers); confirm the UI integration contract and onchain read expectations; and confirm audit cost-sharing and the commercial kicker envelope. We also request a marketing/BD calendar and a shared channel for the weekly reporting cadence. The single largest dependency is the Aero v3 interface detail, since the gauge/xAERO ledger, redemption flow, and route validation cannot be finalized without it.