fix: binance note said "limited to testnet" nine days after mainnet went live - #3
Merged
Merged
Conversation
Minor, not patch: VenueEntry gained a REQUIRED field, the manifest gained an entry, and the meaning of the list changed materially. A patch bump would understate what a consumer is picking up. Not published from here — the publish step is Alex's.
…nt live on mainnet Alex caught it in the 0.4.0 release candidate, before publication. The manifest told anyone deciding whether Binance mainnet was usable that it was not. It has been since 2026-07-27, when the signer signed real orders with real money. A user reading this to plan an integration got the wrong answer, and the package that was about to ship carried the mistake forward. The replacement says WHOSE mainnet, deliberately. A blanket "mainnet-live" reads as "clients are trading live", and that is a different and untrue claim: this is founder dogfood on our own funds, external design partners remain on testnet. It also states USD-M futures only — spot order signing is not implemented, and "spot routes merged" is not the same sentence. okx said "limited to testnet" too. That one is not stale so much as imprecise in the same direction: it implies testnet works. No OKX key is provisioned in the reference deployment, so it signs nowhere today — mainnet or testnet. Said plainly. The other four entries were re-read for the same defect. They carry no deployment-state claims at all: auth scheme and symbol format only, which is what a venue manifest should assert. Every venue listed also has a real handler in the enclave — checked against venue_for_action rather than assumed. The pattern is the one that keeps recurring: a claim about DEPLOYMENT STATE written into an artefact that ships independently of the deployment. It goes stale the moment production moves, and nothing makes a noise when it does.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 16 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe change corrects Binance and OKX deployment notes, updates the package version to 0.4.0, and adds changelog entries for versions 0.4.0 and 0.3.0. ChangesVenue deployment notes release
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CHANGELOG.md`:
- Around line 24-25: Update the remaining-entry description in the changelog to
accurately reflect the five IDs left after binance and okx, including
deployment-state claims for the hyperliquid_* entries, or restrict the wording
to only the entries that describe auth scheme and symbol format.
In `@package.json`:
- Line 3: Synchronize the root package version in package-lock.json with the
0.4.0 version declared in package.json, updating the lockfile before publishing
while preserving all other dependency metadata.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: bfe41521-1275-4e2d-93d7-a21280390483
📒 Files selected for processing (3)
CHANGELOG.mdpackage.jsonsrc/venues.ts
The lockfile had never been bumped: package.json said 0.4.0 while package-lock.json still declared 0.2.0, through two releases. Publishing that way ships a tarball whose two version records disagree, and npm does not stop you. Regenerated with --package-lock-only, so no dependency was resolved differently. The changelog said "the remaining four entries". Five remain after binance and okx, and lumping them together was wrong in substance as well as arithmetic: the two hyperliquid_* entries DO carry deployment status, deliberately — that was the whole point of the previous release. Split into the three that carry no status claim and the two that carry one on purpose. Merge conflict was package.json (0.4.0 vs 0.3.0 — ours, the newer) and the changelog insertion point; both entries kept, newest first.
…s nowhere CodeRabbit caught a contradiction inside my own fix, and it is the same defect inverted: last release I made the manifest honest as DATA rather than prose, and here I left okx as status "live" while rewriting its note to say it signs nowhere. Prose honest, machine-readable field lying. The proposed remedy — a third `unavailable` state — is where I disagree, because it would make the root problem worse. "No key here" is a property of a DEPLOYMENT. Encoding it in a constant shipped inside a package makes the manifest wrong for every operator except one, and drifts the moment a key is provisioned. That is precisely the failure this field was introduced to stop: a claim about deployment state written into an artefact that ships independently of the deployment. So the contract stays two-state and is now documented as what it always should have said: `status` describes the SIGNER RULES — `denied` means the enclave refuses regardless of keys, `live` means it will sign given a provisioned key. Whether a key exists is a question for the gateway, not for a constant. The okx note is reworded on the same principle: what the enclave does, and separately what Usenami hosted happens to have today, named as such rather than stated as a property of the venue. Also corrected: "the remaining four entries" — five remain after binance and okx, and lumping them was wrong in substance too, since both hyperliquid_* entries do carry status deliberately. And the lockfile was still declaring an old version while package.json had moved; regenerated with --package-lock-only so no dependency resolves differently.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caught by Alex in the 0.4.0 release candidate, before publication.
The claim was nine days stale in the wrong direction
binancesaid "v0 limited to testnet until pilot graduates". That has been false since 2026-07-27, when the signer signed real orders with real money on Binance mainnet. Anyone reading this manifest to decide whether mainnet was usable got the wrong answer — and the release about to ship carried it forward.The replacement says whose mainnet, deliberately:
A blanket "mainnet-live" reads as "clients are trading live", which is a different and untrue claim. The spot clause is there for the same reason: "spot routes merged" is not "spot works".
okx: not stale, imprecise in the same direction
"v0 limited to testnet"implies testnet works. No OKX key is provisioned in the reference deployment, so it signs nowhere today — mainnet or testnet. Now stated plainly rather than implied away.The other four were re-read, not assumed
asterdex,kucoin,bybit, and the two Hyperliquid entries carry no deployment-state claims — auth scheme and symbol format only, which is what a venue manifest should assert. Every venue listed also has a real handler in the enclave, checked againstvenue_for_actionrather than taken on trust.The pattern worth naming
Both defects are the same shape: a claim about deployment state written into an artefact that ships independently of the deployment. It goes stale the moment production moves, and nothing makes a noise when it does. That is the third instance this week — the Hyperliquid status, the published PCR0, and now this.
tscclean · signer-mcp 90/90 · plugin-signer 31/31.Publication is Alex's step, after merge.
Summary by CodeRabbit
Documentation
Updates