Bit/Ops

“Bitcoin Ops : an AI trader-of-traders. Allium intel in, policy‑locked execution out , cross‑market BTC bets, L402 payments, and audit‑clean flows for serious capital.” 10x sharper than any degen

Comment

## What Inspired Us

Most “AI trading agents” today are toys.

They scrape Twitter, mash together sentiment, and spit out vaguely bullish or bearish takes. They don’t actually run your book: they don’t understand policy, they don’t respect limits, they don’t track daily spend, and they definitely don’t give you a clean audit trail you could show to a serious allocator.

We wanted the opposite:

  • An agent that behaves like a Bitcoin ops desk, not a meme DJ.
  • An oracle that reads real on‑chain market structure, not influencer threads.
  • A system that plugs into payments rails and wallets, with deterministic policy in front of every action.

Allium’s raw on‑chain data was too good to ignore. It gives you DEX VWAP, whales, flow, cross‑chain context – exactly the kind of data you’d feed a human trader on a desk. We decided to build the agent we’d actually trust with capital allocation:

Allium in, policy‑locked execution out.
Bitcoin as the first asset, but designed from day one to sit on top of any market rail – spot, prediction markets, or L402‑gated APIs.

This isn’t “AI that trades for you.” It’s an AI trader‑of‑traders that keeps you honest on risk, policy, and execution.

What It Does

1. Oracle: Conviction and Market State

We ingest live Allium data and compress it into a conviction oracle:

  • Live BTC price via Allium’s DEX VWAP.
  • Price history / regime (trending vs chop) via OHLCV.
  • Whale flows (exchange in/out, large cold wallets).
  • Cross‑chain relative value (BTC vs ETH vs SOL, when available).

On top of that we run a strategy engine with multiple modules:

  • DEX divergence – psychological levels, price discovery, and candle structure.
  • Volume profile – VWAP bands and accumulation vs distribution.
  • Whale tracker – net exchange inflows/outflows, whale pressure index.
  • Momentum/macro – RSI‑like proxy, ATR, wick analysis, volatility regime.

Each module emits signals; we normalize them to a composite score (s \in [-3, 3]) and interpret that as:

  • STRONG_BUY … STRONG_SELL
  • Risk band (LOW → VERY HIGH)
  • A concrete natural‑language action hint (e.g. “standard DCA”, “trim risk”, “stay flat”).

That’s what drives the “Best Action Right Now” card and the market posture line.

2. Policy Engine: Deterministic Governance

Before any BTC actually moves, everything flows through a hard policy engine:

  • Per‑transaction USD limit.
  • Per‑day USD limit.
  • New‑recipient approval requirement.
  • Minimum wallet balance floor.
  • Auto‑broadcast vs “proposal‑only” mode.

Given a send request, the engine deterministically decides:

  • ALLOW_EXECUTE
  • REQUIRE_APPROVAL
  • REJECT

and produces a checklist of which rules passed/failed. There’s no “vibes” here – just clear rules and explicit reasons.

3. Wallet + Execution Layer

We integrated:

  • Nunchuk CLI on Bitcoin testnet as a wallet backend (multi‑sig capable).
  • A wallet state layer that tracks:
    • Balance (sats + USD).
    • Recent transactions.
    • Network/wallet ID.
    • A derived wallet posture (FLAT / LIGHT / BALANCED / HEAVY).

Execution is split into phases:

  1. Parse intent – “Send 15 dollars to tb1q…” → {amount_usd, amount_sats, address}.
  2. Policy evaluation – run through per‑tx / daily / new‑recipient / min‑balance checks.
  3. Proposal & approval – for REQUIRE_APPROVAL, we generate a proposal with TTL and an approval ID.
  4. Execution – if allowed, we call into Nunchuk CLI to create, sign, and (optionally) broadcast the transaction.

Everything is logged into an append‑only JSONL audit trail: command text, policy decision, wallet source, execution status, and errors.

4. Operator Dashboard: Chat + Panels

On top of that engine we built an operator dashboard:

  • Conviction Oracle – best action + confidence + rationale, with explicit data source labels (Allium vs fallback).
  • Wallet panel – sats, USD, wallet ID, TX count, posture summary.
  • Policy view – per‑tx/daily limits, new‑recipient rules, broadcast mode.
  • Execution Queue – pending approvals with inline Approve/Deny.
  • Audit Log – chronological view of commands, decisions, and executions.
  • Market + Activity – BTC chart + recent wallet activity.
  • Chat UI – natural‑language control surface:
    • “What should this wallet do right now?”
    • “Show market state.”
    • “Send $15 to tb1q…”
    • “Approvals status.”
    • “Approve <ID>.”

The chat is not a toy front‑end to GPT; it’s a first‑class interface to an agent that has access to:

  • Real wallet state (even when the wallet backend is flaky).
  • Real policy.
  • Real market data (when Allium is live, or priced via fallback when not).

How We Built It

Architecture Overview

We split the system into clear layers:

  1. Wallet & State Layer

    • Nunchuk CLI adapter (testnet).
    • Wallet state provider (get_wallet_state_async) with caching and fallbacks.
    • Persistent store for:
      • Daily spent sats.
      • Known recipients.
      • Wallet source (live vs demo).

  2. Policy Engine

    • Pure functions to evaluate sends against:
      • max_autonomous_usd_per_tx
      • max_autonomous_usd_per_day
      • require_approval_for_new_recipient
      • require_approval_below_min_balance_usd
    • Returns a structured policy decision + per‑rule checks.

  3. Agent Layer

    • Intent parser: classifies commands into wallet_review, send_request, strategy_dashboard, approval actions, Lightning intents, etc.
    • Command handler:
      • Wallet review handler → health + flags + next steps.
      • Send handler → parse, validate, policy, proposal, execution.
      • Approval handler → approve/deny with TTL and safety checks.
      • Strategy handler → calls the Allium strategy executor.
    • Response formatter: one schema for all responses so the UI can be dumb and consistent.

  4. Signals & Strategy Layer (Allium)

    • signals/allium_client – low‑level HTTP client with API key management.
    • strategy/data_layer – only place that talks to Allium:
      • Live price
      • History
      • Stats
      • Whale transactions
    • strategy/executor – runs all strategies against a single Allium snapshot and wallet balance, outputs:
      • Composite score/verdict.
      • Per‑strategy details.
      • A top‑level summary.

  5. Audit & Approvals

    • JSONL audit logger with typed entry kinds.
    • Approval registry with TTL and clear state transitions.
    • Errors and timeouts are logged explicitly.

  6. App Layer

    • Node/Express server exposing:
      • /api/command
      • /api/wallet/state
      • /api/wallet/transactions
      • /api/policy
      • /api/price
      • /api/audit
      • /api/approvals
      • Strategy/Allium endpoints (/api/executor/run, /api/executor/data, etc.).
    • Frontend:
      • Lightweight HTML/CSS dashboard for the hackathon.
      • A parallel Next.js + TypeScript + Tailwind + shadcn project for a richer operator UI and chat experience.

We were very deliberate: Allium is treated as a pluggable oracle, not a hard dependency. The agent and wallet logic still work when Allium is down or rate‑limited.

Tech Stack

  • Backend: Node.js, Express.
  • Wallet: Nunchuk CLI (Bitcoin testnet).
  • Oracle: Allium Realtime API (primary), CoinGecko (fallback today, with a path to CoinMarketCap next).
  • Agent: pure JS modules with deterministic outputs, wired into /api/command.
  • Frontend:
    • Hackathon dashboard: vanilla HTML/CSS/JS.
    • New UI: Next.js App Router, TypeScript, Tailwind, shadcn/ui components, custom chat and loader components.

Challenges We Faced

1. Bitcoin Wallet Reality

  • APIs are immature: Many Bitcoin wallets either don’t have usable APIs or are designed for humans, not agents.
  • Testnet3 is effectively deprecated:
    • The Electrum server we used was flaky and slow.
    • Broadcast calls sometimes returned {} even after valid signing.
    • Some failures were not in our code, but in the underlying infrastructure.
  • Nunchuk CLI:
    • Powerful but not designed for low‑latency, high‑frequency agent calls.
    • We hit real‑world latency (13–18s for full wallet state in some cases).
    • We had to build defensive fallbacks and demo modes so the agent didn’t “die” when the wallet did.

2. Rate Limits and Data Quality

  • Allium’s data is great, but:
    • The free tier will absolutely 429 you if you treat it like a local database.
    • We had to build a dedicated data layer with aggressive caching and “one snapshot per tick” semantics.
  • We also had to design around degraded modes:
    • When Allium is hot, we fall back to spot‑only prices and clearly lower confidence.

3. Complexity vs. Demo Time

We were building something you could imagine plugging into a real desk:

  • Hard policy, multi‑step approvals, audit trail, wallet integration, strategy engine, and UI.
  • Each of these could have been its own hackathon project.
  • The challenge was time‑boxing: deciding what to fully wire (policy, approvals, Allium strategies) and what to mock (Kalshi‑style trades, L402 payments) while keeping the architecture honest.

Despite all of that, we managed to keep the codebase readable and testable, with unit tests around the policy engine and strategy executor.

Accomplishments We’re Proud Of

1. Turning Allium into a Real Oracle

We didn’t just graph Allium’s price:

  • We built a layered strategy engine on top of it.
  • We normalized multiple signals into a single conviction score and action.
  • We exposed that as a clean API and a clear UI card.

This turns “beautiful raw data” into something an operator can actually use.

2. Treating Policy as First‑Class

We didn’t hand‑wave “risk management”:

  • Every send request goes through deterministic policy checks.
  • The agent is never allowed to improvise outside those rules.
  • Approvals and rejections are transparent and explainable.

This is closer to how a real desk runs than most “AI trading bots” you see today.

3. Building an Agent That Can Actually Operate

We wired the full loop:

  • Natural language → intent → policy → approval → (simulated or real) execution → audit.
  • The same agent can:
    • Review wallet health.
    • Propose sends.
    • Show market posture.
    • Drive a dashboard and a chat interface.

That’s the beginning of a true ops co‑pilot, not just a chart overlay.

4. Humility in Design

We’re proud of what we built, but also clear about where the edges are:

  • Broadcast reliability on testnet3 is out of our hands.
  • Some trades and cross‑market actions are simulated in this hackathon cut, but the architecture is ready for real rails (Kalshi‑style events, spot exchanges, Lightning/L402 payments).
  • Allium is treated as a powerful oracle, not a single point of failure.

That honesty keeps the system understandable and extendable.

What We Learned

  1. Agentic finance demands structure, not vibes.
    Policy, state, and audit matter more than clever prompts. If you can’t explain why an action happened – and which rule allowed it – you don’t have an ops desk; you have a toy.

  2. On‑chain data is a goldmine, but it needs a brain.
    Allium gives you incredibly rich views of BTC markets. The real value is in how you bundle that into regimes, scores, and trade templates a human (or another agent) can trust.

  3. Wallets and rails are the bottleneck.
    It’s not hard to have an LLM say “go long BTC”; it is hard to wire that safely into real wallets and networks, especially when APIs and testnets are flaky. This pushed us to design strong fallbacks and precise state management.

  4. Good UI for operators looks different from good UI for traders.
    We’re not building a TradingView clone. An ops desk needs:

    • Conviction at a glance.
    • Policy status.
    • Approvals.
    • Recent decisions.
    • A chat surface that feels like talking to a senior analyst, not a chatbot.

  5. Agent rails for payments are coming fast.
    L402, Lightning, and prediction markets all want to be agent‑first. Getting the architecture right now – Allium oracle → policy engine → execution adapters – is how you eventually route serious capital through this system.

In short:
We built a Bitcoin ops desk agent that takes Allium’s on‑chain intelligence, routes it through hard policy, and exposes it through an operator‑grade UI and chat. It doesn’t just say what to trade – it behaves like a junior desk running under strict governance, with enough structure that you could trust it with real money when the rails are ready.

Built With

Share this project:

Updates