chore(defaults): consensus-based audit, drop stale fallbacks (2026-05-02)#29
Merged
Sentinel-Bluebuilder merged 1 commit intomasterfrom May 2, 2026
Merged
Conversation
…-02) The 2026-05-02 follow-up to PR #28 surfaced two issues with the audit: 1. The previous script hardcoded EXPECTED_UDVPN as a constant. The audited wallet had a small outflow between PR authoring and merge, so re-running the script declared 0/22 healthy when in fact 12 endpoints all agreed on the new (correct) balance and only rpc.sentinel.co was actually broken. 2. defaults.js still listed rpc.sentinel.co / lcd.sentinel.co as a "stale fallback" entry. Today's audit confirms both are still ~22k blocks behind tip and return 0 for funded addresses while reporting catching_up=false. Keeping them in the array meant a tryWithFallback() call could still hit them after every other endpoint failed and silently return wrong data. Changes: - tools/audit-rpc-endpoints.mjs — replace hardcoded EXPECTED_UDVPN with a consensus check (modal balance across responding candidates, within 50 blocks of tip). Survives any future outflow from the audit address. Also audits LCD endpoints in the same run; the previous script only covered RPC. - defaults.js — drop rpc.sentinel.co and lcd.sentinel.co. Re-sort RPC list by today's measured latency. Expand LCD list 6 -> 9 entries (Roomit, ChainTools, ChainVibes, Validatus all newly verified). Audit results (2026-05-02, consensus mode): - RPC: 12/22 healthy, 12/13 responding agree on balance - LCD: 9/12 healthy, 9/10 responding agree on balance Run: node tools/audit-rpc-endpoints.mjs Test plan - node -e "import('./defaults.js').then(d => console.log(d.DEFAULT_RPC, d.DEFAULT_LCD))" -> Busurnode for both - Audit script exits 0 with both RPC and LCD tier-1 lists populated
Merged
2 tasks
Sentinel-Bluebuilder
added a commit
that referenced
this pull request
May 2, 2026
Patch release shipping the consensus-audited RPC + LCD endpoint defaults from #28 and #29 to npm consumers. - package.json: 2.7.0 -> 2.7.1 - defaults.js: SDK_VERSION 2.4.0 -> 2.7.1 (was lagging package.json) No API surface changes. Defaults-only update -- consumers calling createRpcQueryClientWithFallback() / SentinelClient with no overrides will now skip the stale rpc.sentinel.co / lcd.sentinel.co endpoints that were returning balance=0 for funded addresses. Co-authored-by: Sentinel-Autonomybuilder <[email protected]>
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.
Why
Follow-up to #28 (merged earlier today). Re-running the audit immediately surfaced two issues:
Hardcoded balance constant goes stale. The previous
audit-rpc-endpoints.mjsassertedEXPECTED_UDVPN === '10000000000'. The audit wallet had a small outflow (98923 udvpn) between PR authoring and merge, so re-running flagged 0/22 healthy when in fact 12 endpoints all agreed on the new correct balance and onlyrpc.sentinel.cowas actually broken. Health-check by hardcoded value is brittle by construction.rpc.sentinel.co/lcd.sentinel.costill indefaults.jsas 'stale fallback'. Today's audit confirms both are still ~22k blocks behind tip and return0for funded addresses while reportingcatching_up=falseon/status. Keeping them in the array means atryWithFallback()call could still hit them after every other endpoint fails and silently return wrong data — exactly the failure mode chore(defaults): refresh RPC/LCD endpoints (2026-05-02) #28 was supposed to fix.What
tools/audit-rpc-endpoints.mjs— replace hardcodedEXPECTED_UDVPNwith a consensus check: health =(height, balance)matches the modal answer across responding candidates, within 50 blocks of tip. Survives any future outflow from the audit address. The script also now audits LCD endpoints in the same run (the previous script was RPC-only).defaults.js— droprpc.sentinel.coandlcd.sentinel.coentirely. Re-sort RPC list by today's measured latency. Expand LCD list 6 -> 9 entries (Roomit, ChainTools, ChainVibes, Validatus all newly verified).Audit results (2026-05-02, consensus mode)
RPC: 12/22 healthy -- 12/13 responding agree on balance, only
rpc.sentinel.codisagrees.LCD: 9/12 healthy -- 9/10 responding agree, only
lcd.sentinel.codisagrees (balance=0);lcd.sentineldao.comandapi.mathnodes.comare DNS-NXDOMAIN.Removed
https://rpc.sentinel.co:443--catching_up=true,balance=0(22k blocks behind tip)https://lcd.sentinel.co-- same pattern, returned0for the funded addressConsumers that hardcode these can re-add them at runtime via
addRpcEndpoint()/addLcdEndpoint().Test plan
node tools/audit-rpc-endpoints.mjs-- exits 0, prints both RPC + LCD tier-1 listsnode -e "import('./defaults.js').then(d => console.log(d.DEFAULT_RPC, d.DEFAULT_LCD))"-- both resolve to Busurnode (fastest)node tools/audit-rpc-endpoints.mjson a fresh checkout