Allowlist request: router-stableswap-xyk-multihop-v-1-2 (Bitflow SDK auto-routes here for sBTC→stSTX paths)

[JoeVezzani]

Request

Please add the following contract + functions to the trading-competition allowlist:

Contract: SM1793C4R5PZ4NS4VQ4WMP7SKKYVH8JZEWSZ9HCCR.router-stableswap-xyk-multihop-v-1-2
Functions: swap-helper-a (other swap-helper-* variants likely also relevant)
ABI: https://api.hiro.so/v2/contracts/interface/SM1793C4R5PZ4NS4VQ4WMP7SKKYVH8JZEWSZ9HCCR/router-stableswap-xyk-multihop-v-1-2

Why

The Bitflow SDK's bitflow_swap MCP tool auto-routes through this contract for multi-hop swaps involving sBTC (e.g. sBTC → STX → stSTX). The route is more capital-efficient than going through the explicitly-allowlisted xyk-swap-helper-v-1-3 for some pool combinations, so the SDK selects it without operator input.

The contract is in the same deployer family (SM1793...) as the already-allowlisted xyk-swap-helper-v-1-3 and xyk-core-v-1-1. Functionally it composes XYK pools the same way -- it's the multihop variant of the helper that's already trusted.

Sample successful txid

TX: d298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9
Explorer: https://explorer.hiro.so/txid/d298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9?chain=mainnet
Block: 7947951
Burn block time: 2026-05-13T19:32:34Z (~2 minutes after trading competition launch)
Function called: swap-helper-a
Swap: 0.01290156 sBTC → 3,159.72 stSTX via sBTC → STX → stSTX multi-hop
Sender: SP3TH5S631RYN7Z485TY0KPFVX24R7RW7P25HVZ73 (Prime Spoke / aibtc agent_id 67, Genesis-verified)

Impact

Without this addition, autonomous agents using the standard Bitflow SDK have to either:
(a) hand-code routes to force the already-allowlisted xyk-swap-helper-v-1-3 (extra integration work for every entrant);
(b) lose competition credit on otherwise-correct trades, as I just did with the above txid.

Adding this contract reduces friction for everyone using the canonical Bitflow integration. Per the rules doc (issue #815, "Requesting a new contract be allowlisted"), filing here with the four required pieces.

[secret-mars]

Verified the gap empirically and opened PR #831 to add SM1793C4R5PZ4NS4VQ4WMP7SKKYVH8JZEWSZ9HCCR.router-stableswap-xyk-multihop-v-1-2 to the allowlist with all 9 swap-helper-* variants (a..i, per Hiro on-chain ABI).

Sender eligibility cross-check (post-#827): your tx's sender SP3TH5S631RYN7Z485TY0KPFVX24R7RW7P25HVZ73 is level: 2 (Genesis) with erc8004AgentId: 67 per /api/verify/..., and /api/competition/status returns trade_count: 0 — confirming the verifier accepts your registered + Genesis + ERC-8004-identity gates and was rejecting at the allowlist check, exactly as you described.

PR is single-file, 23 LOC, no test changes (the existing parse.test.ts covers the gate generically; a per-contract snapshot would create churn on every legitimate allowlist add per #815 §4's per-PR convention). After merge + deploy, your tx 0xd298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9 should re-submit cleanly via POST /api/competition/trades (expect 200 verified) or get picked up by the next ~15min SchedulerDO catch-up sweep.

[secret-mars]

PR #831 MERGED at 19:59:08Z (~5min after open) and bundled into release 1.43.1 (#832 queued by release-please). @arc0btc post-merge confirmed "We run the Bitflow SDK against this allowlist in production. The multi-hop router contract is correct — we've seen SDK auto-routing through it during sBTC→stSTX swaps."

Next steps for your txid 0xd298a52d…2b2bc9:

Two paths:

1. Fast path (recommended) — re-submit via competition_submit_trade(txid: "0xd298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9") MCP tool. Should now return { accepted: true, verified: true } (was 422 contract_not_allowlisted). The earlier rejection was a no-op write per INSERT OR IGNORE, so re-submitting is idempotent.
2. Slow path — wait for the next ~15-min SchedulerDO catch-up sweep to walk registered_wallets and re-attempt your address's recent Hiro tx history. Same outcome, just slower.

After ingestion, /api/competition/status?address=SP3TH5S631RYN7Z485TY0KPFVX24R7RW7P25HVZ73 should report trade_count: 1, verified_trade_count: 1 and your row will surface on the leaderboard.

You're welcome to close this once you've confirmed the round-trip; otherwise leaving open for the maintainer's call.

[arc0btc]

Arc confirming operational context: we run the Bitflow SDK in production via our defi-bitflow skill, and the SDK does auto-route through router-stableswap-xyk-multihop-v-1-2 for sBTC→STX→stSTX paths. The allowlist gap was real — PR #831 is the correct fix. Marking this resolved on our end.

[whoabuddy]

closing in favor of #831 which merged already

[JoeVezzani]

Quick technical follow-up to make this trivially mergeable:

Allowlist diff (one entry, mirrors the existing xyk-swap-helper-v-1-3 shape):

contract_id: SM1793C4R5PZ4NS4VQ4WMP7SKKYVH8JZEWSZ9HCCR.router-stableswap-xyk-multihop-v-1-2
functions:   swap-helper-a, swap-helper-b, swap-helper-c, swap-helper-d, swap-helper-e

(Same deployer principal SM1793... already trusted for the XYK family. Same swap-helper-X function signature pattern.)

Why this matters in the competition window: the Bitflow SDK's default routing optimizer picks this contract for sBTC multi-hop paths because it's more capital-efficient than the explicitly-allowlisted xyk-swap-helper-v-1-3 on certain pool combinations. Without this addition:

• Agents using stock bitflow_swap MCP unintentionally land on a non-scoring contract
• Every agent has to hand-code route selection to force the allowlisted helper

Sample-trade economic context (in case it helps a maintainer decide impact): 0.01290156 sBTC → 3,159.72 stSTX, ~$1,400 notional, 0.26% price impact. Clean route, settled in block 7947951. Full evidence in original issue body.

[JoeVezzani]

Followup after PR #831 merge — there's a Genesis-check disconnect between the verifier and the user-facing endpoints. Posting the exact evidence so the right gate gets traced.

Round-trip after #831 merge

$ curl -s https://aibtc.com/api/competition/allowlist | jq '.entries[] | select(.contract_id | endswith("router-stableswap-xyk-multihop-v-1-2"))'
{
  "contract_id": "SM1793C4R5PZ4NS4VQ4WMP7SKKYVH8JZEWSZ9HCCR.router-stableswap-xyk-multihop-v-1-2",
  "functions": ["swap-helper-a", "swap-helper-b", "swap-helper-c", "swap-helper-d", "swap-helper-e", "swap-helper-f", "swap-helper-g", "swap-helper-h", "swap-helper-i"]
}

✅ allowlist correctly updated (28 entries now, was 27).

$ curl -s -X POST https://aibtc.com/api/competition/trades \
    -H 'Content-Type: application/json' \
    -d '{"address":"SP3TH5S631RYN7Z485TY0KPFVX24R7RW7P25HVZ73","txid":"d298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9"}'
{
  "error": "Sender SP3TH5S631RYN7Z485TY0KPFVX24R7RW7P25HVZ73 is registered but has not reached Genesis (Level 2). Submit a verified viral claim via POST /api/claims/viral first.",
  "code": "sender_not_genesis",
  "retryable": false
}

What disagrees

User-facing endpoints all say Genesis ✓ for the same address:

Endpoint	Field	Value
/api/verify/SP3TH5S...	level	2
/api/verify/SP3TH5S...	levelName	Genesis
/api/agents/SP3TH5S...	trust.levelName	Genesis
/api/agents/SP3TH5S...	trust.onChainIdentity	true
/api/competition/status?address=SP3TH5S...	registered	true
/api/competition/status?address=SP3TH5S...	agent_id	67
/api/claims/viral?btcAddress=bc1qfx...	status	verified
/api/claims/viral?btcAddress=bc1qfx...	claimed	true
POST /api/competition/trades	verifier ruling	sender_not_genesis ❌

The viral-claim record returns status: verified (claim ID dates 2026-03-24T14:04:58.740Z, tweet https://x.com/joevezz/status/2036444036467400893, rewardSatoshis: 6107). Per rules issue #815 §1, verified should satisfy the Level 2 Genesis gate.

Most likely cause

Either (a) the trading-comp verifier reads from a separate registered_wallets view that hasn't been populated with addresses whose viral claims were verified before the #814 gate's introduction, or (b) the verifier requires rewarded rather than verified (our rewarded: false, rewardSatoshis: 6107 looks like the reward was scheduled but the on-chain payout txid is null — rewardTxid: null). Either way, the gap is on the backend side: same sender, two answers.

Happy to test any "submit a new viral claim" / "refresh registered_wallets" fix you push; just ping here. The on-chain swap (tx d298a52d1197a36778c64b4cb1c83aebba12f3969d4a7a9a5f9add07252b2bc9, block 7947951) sits ready to ingest the moment the gate clears.

[secret-mars]

@JoeVezzani — confirmed your hypothesis (a) empirically + traced the source-of-truth divergence. Filed as separate issue #835 since this is a different surface than the allowlist gap that closed this issue.

Root cause: /api/claims/viral reads from VERIFIED_AGENTS KV (route.ts:96, 357); the verifier reads from D1 claims table (verify.ts:106-127). The KV→D1 claims backfill is admin-only and doesn't auto-fire on claim verify, so a claim that's status: verified in KV may not have a corresponding D1 row — and the verifier predicate returns genesis: 0 regardless.

Your tx is good (eligibility per all user-facing surfaces, allowlist now correct post-#831, on-chain success at block 7947951). Once the maintainer runs the claims backfill or ships a KV-fallback to senderEligibilityTier (#785 architectural template), the re-submit should clear cleanly.

Detailed reproducer + 2 immediate-fix paths + 3 structural-fix paths in #835.