Skip to content

CHANGELOG.md

Latest commit

 

History

History
146 lines (123 loc) · 8.86 KB

CHANGELOG.md

File metadata and controls

146 lines (123 loc) · 8.86 KB
Raw

0.5.0 — 2026-08-10

Публичная поверхность приведена к фактам — по двум независимым прогонам пути клиента с нуля 2026-08-10 (внутренний client-zero и внешний аудит «чужого»); зеркалит правки @usenami/signer-mcp@0.6.0, контракт гейтвея общий.

  • 🔴 Дефолтный SIGNER_GATEWAY_URL сменён: https://signer.usenami.io → https://signer-demo.usenami.io:8443. Старый хост 301-редиректит каждый путь на маркетинговый лендинг — все сетевые действия падали из коробки с «Unexpected token '<'». HTML-ответ гейтвея теперь распознаётся и называется своим именем: «the gateway returned HTML, not JSON — check SIGNER_GATEWAY_URL».
  • Версия берётся из манифеста, а не константой: 0.4.0 слала User-Agent «@usenami/plugin-signer@0.2.0» (та же болезнь, что чинил signer-mcp#11).
  • Доступ назван инвайтным в README (self-serve выдачи токенов нет); из ошибки об отсутствии токена убрана ссылка «Issue tokens at…», ведшая на страницу без выдачи.
  • Таблица венью: 7 записей — добавлен hyperliquid_testnet (единственный подписывающий путь Hyperliquid), hyperliquid_main помечен denied (запрет внутри энклава); документирован per-venue status.
  • Служебные самокоррекции убраны из notes манифеста (место им здесь): (1) binance: формулировка «limited to testnet» была ложной с 2026-07-27 — mainnet-подписи идут в проде средствами самого оператора, внешние design-партнёры остаются на testnet-политиках; (2) okx: прежняя формулировка подразумевала, что testnet работает, — на деле в хостед-деплое OKX-ключ не провижнён и OKX там не подписывает нигде.
  • Адрес сверки PCR0 приведён к одному источнику: usenami.io/signer/attestations.

Changelog

All notable changes to @usenami/plugin-signer are documented here. Format follows Keep a Changelog; versioning is SemVer.

[0.4.0] — 2026-08-06 (venue notes brought to the facts)

Fixed

  • binance claimed "v0 limited to testnet until pilot graduates". That has been false since 2026-07-27, when the signer began signing real orders with real money on Binance mainnet. Anyone reading the manifest to decide whether mainnet was usable got the wrong answer for over a week.

    The replacement states whose mainnet, because a blanket "mainnet-live" reads as "clients are trading live" and that is not true: it is founder dogfood on our own funds, and external design partners remain on testnet. The note also says USD-M futures only — spot order signing is not implemented, and "spot routes merged" is not the same claim.

  • okx said "v0 limited to testnet", which implies testnet works. No OKX key is provisioned in the reference deployment, so it signs nowhere today — mainnet or testnet. Stated plainly instead.

Changed

  • VenueEntry.status is documented as a statement about the signer's rules, not about any deployment's provisioning, and deliberately gains no unavailable state. "No key here" differs per operator: encoding it would make the manifest wrong for everyone but one deployment and would drift the moment a key is added — the exact failure this field exists to prevent. The okx note is reworded the same way: what the enclave does, plus what Usenami's hosted deployment happens to have, clearly separated.

Notes

  • Five entries remain after binance and okx, and they split in two: asterdex, kucoin and bybit carry no deployment-state claims — auth scheme and symbol format only, which is what a venue manifest should assert. The two hyperliquid_* entries do carry status, deliberately: that was the point of the previous release, and hyperliquid_main being denied is a property of the enclave, not of any one deployment. Every venue listed has a real handler in the enclave — checked against venue_for_action, not assumed.

[0.3.0] — 2026-08-06 (Hyperliquid mainnet status corrected)

Fixed

  • hyperliquid_main was listed as an ordinary, usable venue. It is not. The enclave refuses sign_hyperliquid_main_order / _cancel before it loads or decrypts any key material, and has done so since 2026-06-26. Anyone building against the old manifest produced a call that could only come back as a policy denial. This was a functional bug, not a documentation nit.

Added

  • status: "live" | "denied" on every venue entry. The correction is data, not prose: a caller that reads a machine-readable manifest and ignores free text is behaving reasonably, and would still have tried.
  • hyperliquid_testnet, status live, listed ahead of the denied mainnet entry. Saying only "Hyperliquid is denied" would be its own inaccuracy in the other direction — testnet signs through the same EIP-712 code path, differing only in the phantom-agent source byte.

Changed

  • denied means the signature is refused inside the enclave, not that configuration is missing. Supplying credentials does not change it. The venue notes now say so explicitly.
  • LIST_SIGNER_VENUES now carries the status in its rendered text, not only in data. The summary is what a human and an LLM actually read; omitting the denial there presented a refused venue as usable — the same bug one layer up.

Upgrading

VenueEntry gained a required status field, so TypeScript consumers that construct or implement the interface must add it. Consumers that only READ the manifest are unaffected apart from seeing one more venue and the new field.

[0.2.0] — 2026-06-07 (all 6 venues)

Brings the plugin's venue manifest to all six venues the Signer gateway signs for (was 3), in lockstep with @usenami/signer-mcp v0.2.0. The plugin is unpublished prior to this, so 0.2.0 is the first npm release.

Added

  • LIST_SIGNER_VENUES now reports six venues — adds kucoin (KuCoin Futures, HMAC + v2 encrypted passphrase, symbol XBTUSDTM), bybit (Bybit V5 linear, HMAC, symbol BTCUSDT), and hyperliquid_main (Hyperliquid L1, EIP-712, symbol BTC).
  • PLACE_SIGNER_ORDER / GET_SIGNER_ACCOUNT / CANCEL_SIGNER_ORDER accept the three new venue ids (validated against the shared STATIC_VENUES manifest).

Changed

  • Action descriptions + "venue required" / "need a venue" error messages now list all six venues (error messages derive the list from the manifest to avoid drift).
  • PLUGIN_VERSION 0.1.0 → 0.2.0 (surfaces in the gateway User-Agent).
  • README venue table + status line updated for 6 venues.

Notes

  • Order signing works for all six at the gateway (verify-all-blobs 6/6). The plugin returns the venue's raw response for account/order calls (no client-side normalization — unlike signer-mcp's parsers); live get_account activates per venue as the gateway enables each account-read endpoint.

[0.1.0] — 2026-06-06 (initial release)

First publish. Thin ElizaOS wrapper around the Usenami Signer gateway, mirroring the same v0 contract as @usenami/signer-mcp.

Added

  • Actions:
    • GET_SIGNER_ATTESTATION — Nitro PCR0 + on-chain registration proof (read-only, no auth).
    • LIST_SIGNER_VENUES — static venue manifest (read-only, no auth).
    • GET_SIGNER_ACCOUNT — equity / free margin / positions via Option-A signed read.
    • PLACE_SIGNER_ORDER — market / limit orders on binance / okx / asterdex.
    • CANCEL_SIGNER_ORDER — cancel by venue order_id (+ symbol for binance / okx routes).
  • Provider:
    • SIGNER_ATTESTATION_PROVIDER — surfaces the running enclave's PCR0 to the agent every turn, 60-second cached. Soft-fails to a "gateway unreachable" line so the agent stays usable if the signer is down.
  • Env contract (same as signer-mcp): SIGNER_GATEWAY_URL, SIGNER_API_TOKEN, SIGNER_FETCH_TIMEOUT_MS.
  • Re-exports callGateway / submitSignedBundle / STATIC_VENUES for custom agents that want to compose their own actions on top of the shared gateway layer.

Known limits (deliberate)

  • Single account per venue per SIGNER_API_TOKEN.
  • No withdrawals / transfers / leverage configuration / multi-venue routing / streaming.
  • Static venue manifest — refreshes on package release, not at runtime.