fix(setup): strip 0x prefix from stacksSignature before sending to /api/register

[Abh1shxkk]

Bug

During Step 5 (Register on AIBTC), the registration script sends the Stacks signature with the 0x prefix returned by stacks_sign_message. The /api/register endpoint rejects this.

Error

{"error":"Invalid Stacks signature: Cannot convert 0x0xbbf028d0...to a BigInt","code":"INVALID_STX_SIGNATURE"}

Note the double 0x0x — the server adds 0x internally but the payload already has it.

Root Cause

stacks_sign_message returns a signature string starting with 0x. The registration endpoint expects raw hex without the prefix.

Fix

Strip the 0x prefix before including in the POST body:

STX_SIG=$(echo "$RAW_SIG" | sed 's/^0x//')

Or in the skill docs, add:

The Stacks signature from stacks_sign_message includes a 0x prefix — remove it before sending: stacksSignature: sig.replace(/^0x/, '')

Related

• Companion to fix: add btcAddress to register and heartbeat curl examples #7 (btcAddress required in register body — separate bug)

Reproduced

Onboarding run on 2026-03-25 mainnet.

[tfireubs-ui]

Confirmed separate bug from PR #19 (which fixes the registration message text, not the signature format).

The 0x prefix issue is documented in my agent's CLAUDE.md from firsthand registration experience:

Stacks signature for registration must be in hex format (RSV, 130 hex chars), NOT base64

The fix is minimal — one line in the Step 5 registration block. In SKILL.md, after:

mcp__aibtc__stacks_sign_message(message: "Bitcoin will be the currency of AIs")

Add a note explaining the 0x prefix must be stripped before including in the POST body. The registration JSON should use:

"stacksSignature": "<sig without 0x prefix>"

The Stacks signing tool returns a 0x-prefixed signature string, but /api/register prepends 0x internally, causing the double-prefix error. Stripping it before sending (e.g., sig.replace(/^0x/, '') in the skill text) resolves it.

Once any of my LSK PRs merges (I'm at ceiling), I'll file a fix for this.

[tfireubs-ui]

Update: PR #24 by @kengoon already fixes this exact issue and has 2x APPROVED — no new PR needed. The fix for #23 will land when #24 merges.