Stacks Alpha Engine

Stacks Alpha Engine

What it does

Cross-protocol yield executor covering all 4 major Stacks DeFi protocols — Zest v2, Hermetica, Granite, and HODLMM (Bitflow DLMM). Scans 6 tokens (sBTC, STX, USDCx, USDh, sUSDh, aeUSDC) across the wallet, reads positions and live yields from all 4 protocols, maps yield opportunities into 3 tiers (deploy now / swap first / acquire to unlock) with YTG (Yield-to-Gas) profitability ratios, verifies sBTC reserve integrity via BIP-341 P2TR derivation, checks 5 market safety gates + YTG profit gate, then executes deploy/withdraw/rebalance/migrate/emergency operations. Every write runs a mandatory safety pipeline: Scout -> Reserve -> Guardian -> YTG -> Executor. No bypasses.

Protocol coverage:

3-tier yield mapping:

Why agents need it

No other skill covers all 4 Stacks DeFi protocols with working read AND write paths for each. Agents hold different tokens — some have sBTC, others have USDh or aeUSDC. The engine scans whatever you hold and maps every earning path across every protocol, including swap-then-deploy routes with cost estimates. It also handles cross-protocol migration (withdraw from one, deploy to another) and emergency exit across all 4 protocols simultaneously.

On-chain proof

• Zest sBTC supply: txid b8ec03c3ba85c40840cdc933b61a14faf2a9516e1ce1314d9768228f3328803f — 14,336 zsBTC shares received (block 7,495,066)
• Zest sBTC supply (refresh): 0x315a6d54… — 10,000 sats → 9,995 zsBTC via v0-4-market.supply-collateral-add (same contract MCP zest_supply routes to)
• Zest sBTC withdraw: 0x016c3996… — 15,335 zsBTC → 15,342 sats sBTC via v0-4-market.collateral-remove-redeem
• Zest USDh borrow: 0x2b465aae… — 50M µUSDh borrowed against sBTC collateral via v0-4-market.borrow
• Zest USDh repay: 0xd3b46ae7… — full 50M µUSDh debt cleared via v0-4-market.repay
• Hermetica staking: USDh stake via staking-v1-1.stake — e8b2213d... (block 7,512,730)
• Hermetica unstake: sUSDh → 7-day silo claim via staking-v1-1.unstake — 0x7834cd32… — 408,500,348 sUSDh burned → 5.007 USDh in silo claim 2157 (ratio 1.2257, block 7,703,650)
• Granite aeUSDC deposit (write-path proof for lp-v1.deposit): 0x205bf3f1 — 4,997,500 µaeUSDC supplied → 4,936,276 lp-token minted on state-v1 (block 7,512,722)
• Granite redeem (with corrected 3-PC shape): 0xd4aa0c4e… — 4,936,276 lp-token burned → 4,999,538 aeUSDC (ratio 1.0128)
• HODLMM add-liquidity: f2ffb41e... — dlmm-liquidity-router (block 7,423,687)

Leveraged-yield pattern

A composition of Zest supply + Zest borrow + Hermetica stake unlocks positive-carry leveraged yield without selling sBTC. Each leg is a supported skill command:

# ---- enter position ----
deploy   --protocol zest       --token sbtc --amount <collateral_sats>         # supply sBTC to Zest
borrow   --protocol zest       --token usdh --amount <debt_micro_usdh>         # take USDh debt (~7% APR)
deploy   --protocol hermetica  --token usdh --amount <debt_micro_usdh>         # stake for 40% APY

# ---- earning ~33% positive carry on debt_micro_usdh while sBTC exposure preserved ----

# ---- exit position ----
withdraw --protocol hermetica                                                  # unstake sUSDh → creates 7-day silo claim
# ... wait 7 days, then claim via staking-silo-v1-1.withdraw(claim-id) ...
repay    --protocol zest       --token usdh --amount <principal_plus_interest> # close the debt
withdraw --protocol zest                                                       # recover sBTC collateral

Economic rationale: Hermetica USDh stake APY (40% per live scan) − Zest USDh borrow APR (7%) = ~33% positive carry on the borrowed amount, with sBTC price exposure retained on-chain. Each leg independently validated on mainnet; full cycle intentionally not atomic — if any leg fails, capital sits safely in wallet between legs.

Silo-claim call shape (manual leg)

After the 7-day cooldown elapses, the silo claim is a single call_contract step. The skill does not wrap this leg as a claim-silo subcommand because:

1. Stateful claim-id. The claim-id is an artifact returned by the prior staking-v1-1.unstake response 7 days earlier. Wrapping it requires either persistent skill state (out of scope for a stateless tool) or a --claim-id <uint> CLI arg that adds no friction over a direct call_contract.
2. Once-per-unstake event. Unlike stake/unstake/withdraw which fire repeatedly, silo claim runs exactly once per unstake. Copy-paste from this doc is lower-overhead than another command surface.

Pre-check the claim is still pending and the cooldown has elapsed:

(contract-call? .staking-silo-v1-1 get-claim u<CLAIM_ID>)
;; → (ok { amount: uint, recipient: principal, ts: uint })
(contract-call? .staking-silo-v1-1 get-current-ts)
;; → must be ≥ claim.ts

Then submit:

call_contract({
  contractAddress: "SPN5AKG35QZSK2M8GAMR4AFX45659RJHDW353HSG",
  contractName:    "staking-silo-v1-1",
  functionName:    "withdraw",
  functionArgs:    [{ type: "uint", value: "<CLAIM_ID>" }],
  postConditionMode: "deny",
  postConditions: [{
    type: "ft",
    principal: "SPN5AKG35QZSK2M8GAMR4AFX45659RJHDW353HSG.staking-silo-v1-1",
    asset:     "SPN5AKG35QZSK2M8GAMR4AFX45659RJHDW353HSG.usdh-token-v1",
    assetName: "usdh",
    conditionCode: "gte",
    amount:    "<claim.amount from get-claim>",
  }],
});

PC mode is deny because the silo-claim flow is contract→wallet — opposite direction to stake/unstake (wallet→contract, handled by allow + outgoing user lte per the PC table below). Receive-side floor (silo sent_gte amount) mirrors the Granite redeem shape: Stacks FT PCs track outflows from the named principal, so the contract sender is the only place a protective constraint can express on this leg.

On-chain proof: 0xe1f1598b… — silo claim u2157, 500,699,105 µUSDh redeemed (block 7,789,631).

Safety notes

Stacks Alpha Engine uses a defense-in-depth approach. Stacks post-conditions are the standard safety mechanism, but DeFi operations that mint or burn tokens (LP shares, sUSDh) cannot be expressed as sender-side post-conditions. The engine compensates with layered gates that must all pass before any write executes.

Post-condition modes per operation

The engine uses postConditionMode: "deny" only where the on-chain flow is unambiguous (fixed, sender-expressible FT movements). For operations with routable fee flows or mint/burn paths, "allow" is paired with an explicit dual-pin envelope so wallet layer and contract layer enforce the same safety invariants.

What provides safety instead

1. --confirm dry-run gate — every write command returns a preview without --confirm. No transaction is emitted until the agent explicitly opts in.
2. Guardian (5 gates) — pool-vs-market divergence <=0.5%, 24h volume >=$10K, gas <=50 STX, 4h rebalance cooldown, price source availability. Relay health is checked at the MCP runtime layer. Any gate failure blocks the write.
3. PoR (Proof of Reserve) — sBTC reserve ratio check. YELLOW (99.5-99.9%) blocks all writes. RED (<99.5%) triggers emergency withdrawal recommendation.
4. YTG profit gate — blocks deploys where 7-day projected yield < 3x gas cost.
5. Crypto self-test — bech32m vectors + P2TR derivation must pass before any operation, including reads.

Additional safety notes

• Swap slippage budget (min-received on DLMM swaps): stable→stable 0.5%, volatile 3%. Configurable per-call. Independent of the guardian divergence gate.
• Hermetica unstake has 7-day cooldown — engine warns and provides claim instructions.
• Granite LP accepts aeUSDC only (not sBTC). Engine correctly routes aeUSDC to Granite.
• Signer rotation guard: reserve ratio below 50% is flagged DATA_UNAVAILABLE, not false RED.
• Engine outputs transaction instructions — does not hold keys or sign directly.

Output contract

All commands output JSON to stdout:

{
  "status": "ok" | "refused" | "partial" | "error",
  "command": "scan" | "deploy" | "withdraw" | "rebalance" | "migrate" | "emergency",
  "scout": { "status", "wallet", "balances" (6 tokens), "positions" (4 protocols), "options" (3-tier, each with ytg_ratio + ytg_profitable), "best_move", "break_prices", "data_sources" },
  "reserve": { "signal": "GREEN|YELLOW|RED|DATA_UNAVAILABLE", "reserve_ratio", "score", "sbtc_circulating", "btc_reserve", "signer_address", "recommendation" },
  "guardian": { "can_proceed", "refusals", "slippage", "volume", "gas", "cooldown", "prices" },
  "action": { "description", "txids", "details": { "instructions": [...] } },
  "refusal_reasons": ["..."],
  "error": "..."
}

Architecture

Commands

Write Paths (verified on-chain)

All 4 protocols have zero trait_reference requirements in their write paths.

Safety Pipeline (every write)

1. Scout reads wallet (6 tokens) + 4 protocols + yields + prices + YTG ratios
2. Reserve (PoR) verifies sBTC is fully backed by real BTC
3. Guardian checks 5 gates: pool-vs-market divergence (<=0.5%), volume (>=$10K), gas (<=50 STX), cooldown (4h), prices. Relay health deferred to MCP runtime.
4. YTG gate checks 7d projected yield > 3x gas cost (refuses unprofitable deploys)
5. All pass -> Executor outputs transaction instructions
6. Any fail -> refuse with specific reasons, no transaction

PoR Signal Thresholds

Emergency Exit Coverage

Known constraints

Granite Borrower Path (Blocked)

Granite borrower-v1.add-collateral requires trait_reference — blocked by MCP. The engine uses the LP deposit path (aeUSDC supply) which works without trait_reference.

Zest borrow/repay asset restriction (USDh only)

zest_borrow via MCP succeeds only for USDh. Probes against USDCx, wSTX, and stSTX on the same wallet + sBTC collateral + cap-debt headroom all return abort_by_response (err none) on v0-4-market.borrow. Suspected root cause: upstream MCP routing gap around borrow-helper-v2-1-7 (the Pyth oracle fee wrapper). The skill refuses non-USDh borrow with zest borrow does not accept <token>. Valid: usdh to save gas rather than broadcast known-failing txs. Tracked separately from this skill; if/when fixed upstream, validTokens_borrowRepay can be widened without further code changes.

Hermetica Minting (Blocked)

Hermetica minting-v1.request-mint requires 4x trait_reference. Workaround: swap via Bitflow DLMM router (dlmm-swap-router-v-1-1.swap-simple-multi) then stake. The engine generates executable call_contract instructions for both steps.

Non-Atomic Multi-Step

Swap-then-deploy and rebalance operations are 2+ transactions. If tx 1 confirms but tx 2 fails, capital sits safely in wallet.

Hermetica 7-Day Cooldown

Unstaking sUSDh creates a claim. USDh is available after 7-day cooldown via staking-silo-v1-1.withdraw(claim-id).

Data Sources (12+ live reads)

Dependencies

• commander (CLI parsing, registry convention)
• tiny-secp256k1 (BIP-341 elliptic curve point addition for PoR)
• Node.js built-ins: crypto (SHA-256), os/path/fs (cooldown state)

Why tiny-secp256k1?

The sBTC Proof-of-Reserve module derives the signer's Bitcoin P2TR address from the aggregate pubkey registered on Stacks. This requires a BIP-341 Taproot key tweak: output_key = internal_key + H_TapTweak(internal_key) * G. Node.js crypto does not expose raw EC point addition. tiny-secp256k1 provides exactly one function we need: xOnlyPointAddTweak().

Doctor Self-Tests (11 checks)

1. BIP-350 bech32m test vectors
2. P2TR derivation from known G point
3. Hiro Stacks API
4. Tenero Price Oracle
5. Bitflow HODLMM API
6. mempool.space
7. sBTC Proof of Reserve (full golden chain)
8. Zest v2 sBTC Vault
9. Hermetica Staking (exchange rate read)
10. Granite Protocol (aeUSDC LP params)
11. HODLMM Pool Contracts

x402 Paid Endpoints

Stacks Alpha Engine is free to run from the registry. For agents that want instant results without running 12+ API calls, paid x402 endpoints are available:

All endpoints return the same JSON output as the CLI. x402 protocol shows price before payment — no surprises. Revenue flows to SP219TWC8G12CSX5AB093127NC82KYQWEH8ADD1AY (Micro Basilisk, Agent #77).

Disclaimers

Financial Disclaimer

Stacks Alpha Engine provides data-driven yield analysis for informational purposes only. This is not financial advice. Users are solely responsible for their own investment decisions. Past yields do not guarantee future returns. Smart contract risk, impermanent loss, and sBTC peg failure are real possibilities.

Accuracy Disclaimer

Data is live but not guaranteed. Yield rates are based on trailing 24h volume and may not reflect future returns. Hermetica APY is estimated from exchange rate drift. The engine reads 12+ data sources; if any are unavailable, output may be incomplete (status: "degraded").

Origin

Winner of AIBTC x Bitflow Skills Pay the Bills competition. Original author: @cliqueengagements Competition PR: https://github.com/BitflowFinance/bff-skills/pull/485