auth.ts: keypair format incompatible with BitRouter v0.6.1 (web3/SOL_EDDSA)

[openclaw-bitrouterai]

Problem

The plugin's auth.ts generates Ed25519 keypairs in BitRouter's legacy v0.4.x format and signs JWTs with the EdDSA algorithm. BitRouter v0.6.1 changed to a web3 (Solana-compatible) keypair format and SOL_EDDSA JWT signing. Every authenticated API call — /v1/metrics, /admin/routes, /accounts, and proxied LLM calls — returns 401: invalid JWT signature when the installed binary is v0.6.1+.

Format diff

master.json (v0.4.x):

{ "algorithm": "eddsa", "secret_key": "<base64url(seed || pubkey)>" }

master.json (v0.6.1):

{ "algorithm": "web3", "seed": "<base64url(32-byte seed)>" }

JWT header (v0.4.x): { "alg": "EdDSA", "typ": "JWT" }
JWT header (v0.6.1): { "alg": "SOL_EDDSA", "typ": "JWT" }

iss claim (v0.4.x): <base64url pubkey>
iss claim (v0.6.1): solana:<chain-id>:<base58 pubkey>

Impact

Any environment with BitRouter v0.6.1 binary installed: plugin tools (bitrouter_status, bitrouter_add_route, bitrouter_list_routes, bitrouter_remove_route, bitrouter_account, bitrouter_keygen) all fail, metrics are unavailable, and LLM calls via the bitrouter provider return 401.

Fix

Tracked in PR #11. auth.ts rewritten to generate web3 keypairs and SOL_EDDSA JWTs. Legacy eddsa keys are detected on load and auto-migrated to web3 on the next ensureAuth call.

Notes

• The --chain flag added to bitrouter keygen in v0.6.1 suggests multi-chain support is coming. The SOLANA_CHAIN_ID constant in the fix (5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) is Solana mainnet genesis hash. It would be worth confirming whether the plugin should pin this or read it from a BitRouter API response.
• binary.ts already targets BITROUTER_VERSION = "0.6.1" for auto-download, so any fresh install would have hit this on first startup.