Skip to main content

nonce-manager

Backup sender nonce tracker for Stacks transactions. Use canonical payment-status polling first; use this for local nonce coordination and recovery.

소스 정보

저장소
aibtcdev/skills
최근 소스 활동
2026년 4월 3일 21:27
감지된 SKILL.md 언어
영어
스타
10
포크
47

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
4 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
nonce-manager
description
Backup sender nonce tracker for Stacks transactions. Use canonical payment-status polling first; use this for local nonce coordination and recovery.
metadata
{"author":"rising-leviathan","author-agent":"Loom","user-invocable":"false","arguments":"acquire | release | sync | status","entry":"nonce-manager/nonce-manager.ts","mcp-tools":"nonce_health, nonce_heal, nonce_fill_gap","requires":"","tags":"infrastructure, l2"}
# Nonce Manager Backup sender nonce tracker for Stacks transactions. Use canonical payment-status polling by `paymentId` as the primary x402 state machine; use this tool for local nonce coordination and recovery when a fresh sender nonce is actually needed. ## Problem Each skill independently fetches nonce from Hiro API. When tasks fire back-to-back (before mempool clears), they grab the same nonce and collide with `SENDER_NONCE_STALE` or `SENDER_NONCE_DUPLICATE` errors. ## Solution Single file-locked nonce state at `~/.aibtc/nonce-state.json`. Skills call `acquire` to get the next nonce (atomically incremented), and `release` after the transaction confirms or fails. If state is stale (>5 min), auto-resyncs from Hiro. ## Subcommands ### acquire Get the next nonce for a Stacks address. Atomically increments the stored value. Auto-syncs from Hiro if state is missing or stale (>5 min). ``` bun run nonce-manager/nonce-manager.ts acquire --address SP... ``` Output: ```json { "nonce": 42, "address": "SP...", "source": "local" } ``` ### release Mark a nonce as confirmed or failed after transaction outcome is known. ``` bun run nonce-manager/nonce-manager.ts release --address SP... --nonce 42 bun run nonce-manager/nonce-manager.ts release --address SP... --nonce 42 --failed bun run nonce-manager/nonce-manager.ts release --address SP... --nonce 42 --failed --rejected ``` **Failure kinds** (critical distinction): - `--rejected` — tx never reached mempool (signing error, relay 409 nonce rejection). Nonce NOT consumed, safe to roll back and reuse. - `--broadcast` (default when `--failed`) — tx reached mempool. Nonce IS consumed even if the tx fails on-chain. Do NOT roll back. Only `--failed --rejected` triggers a rollback. Default `--failed` assumes broadcast (safer). Output: ```json { "address": "SP...", "nonce": 42, "action": "confirmed" } ``` ### sync Force re-sync nonce state from Hiro API. Use after manual intervention or mempool clearance. ``` bun run nonce-manager/nonce-manager.ts sync --address SP... ``` Output: ```json { "nonce": 42, "address": "SP...", "mempoolPending": 3, "lastExecuted": 41, "detectedMissing": [] } ``` ### status Show current nonce state for one or all tracked addresses. ``` bun run nonce-manager/nonce-manager.ts status bun run nonce-manager/nonce-manager.ts status --address SP... ``` ## Library Import Skills running in the same process can import directly: ```typescript import { acquireNonce, releaseNonce, syncNonce } from "../nonce-manager/nonce-store.js"; const { nonce } = await acquireNonce("SP..."); // ... send transaction ... await releaseNonce("SP...", nonce, true); // true = success ``` ## Nonce Strategy 1. **Acquire before send** — always get nonce from manager, never from Hiro directly 2. **Release after confirm/fail** — keeps state accurate for next caller 3. **Auto-sync on stale** — if last sync >5 min ago, re-fetch from Hiro before returning 4. **File lock for atomicity** — mkdir-based lock prevents concurrent reads returning same nonce 5. **Distinguish broadcast vs rejected** — only rejected nonces can be rolled back ## Integration with x402 Error Codes Use canonical payment status plus `terminalReason` first. When local nonce bookkeeping is still needed, map outcomes to release actions like this: | Relay Response | Release Action | |---------------|----------------| | `confirmed` | `release --address ... --nonce N` (success) | | `queued` / `broadcasting` / `mempool` | Keep polling the same `paymentId`; do not rebuild; keep nonce tracked as in-flight | | `failed` + `sender_nonce_duplicate` | `release --address ... --nonce N --failed --rejected` + re-sync and rebuild | | `409 SENDER_NONCE_STALE` | `release --address ... --nonce N --failed --rejected` + re-sync | | `409 SENDER_NONCE_GAP` | `release --address ... --nonce N --failed --rejected` + re-sync | | `failed` + relay/sponsor/internal reason | Do not treat as sender rebuild guidance; bounded retry or stop by tool policy | | `replaced` / `not_found` | Stop polling the old `paymentId`; start a new payment flow only if the higher-level action still needs to pay |
GitHub에서 보기