feat(bitsong): add BitSong (bitsong-2b) chain + BTSG warp route to Base - #1582
feat(bitsong): add BitSong (bitsong-2b) chain + BTSG warp route to Base#1582angelorc wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 53 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: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR adds BitSong chain support to the registry: new address and metadata YAML files for the ChangesAdd BitSong chain and BTSG warp route
Alright, no giant sequence diagram here — this whole swamp of a change is just some quiet config-adding, nothing with three ogres talking to each other in a fancy dance. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 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: 4
🧹 Nitpick comments (1)
chains/bitsong/metadata.yaml (1)
24-25: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winSingle RPC/REST/gRPC endpoint — no fallback
Only one URL is configured for
grpcUrls,restUrls, andrpcUrls. Ifpolkachu.comorexplorebitsong.comhas downtime, all Hyperlane relayers/agents depending on this registry lose connectivity to BitSong. Consider adding at least one backup provider for resilience, following the pattern used for most other chains in this registry.Also applies to: 36-39
🤖 Prompt for 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. In `@chains/bitsong/metadata.yaml` around lines 24 - 25, The BitSong metadata currently configures only a single endpoint for grpcUrls/restUrls/rpcUrls, creating a single point of failure. Update the BitSong chain entry in metadata.yaml to add at least one additional backup provider for each of the affected URL lists, following the redundancy pattern used by other chain entries, and keep the existing primary endpoints as-is.
🤖 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 `@chains/bitsong/addresses.yaml`:
- Around line 1-5: Add a provenance note for each address entry in the
addresses.yaml file so the source of the values is documented per the config
guidelines. Update the entries for interchainGasPaymaster,
interchainSecurityModule, mailbox, merkleTreeHook, and validatorAnnounce with a
brief comment or note indicating where each address came from (for example,
deployment transaction or monorepo PR), keeping the existing symbols intact and
making the source traceable.
- Line 3: The addresses mapping for bitsong currently assigns the same value to
both mailbox and validatorAnnounce, which should be distinct. Update the
addresses in the bitsong addresses config so validatorAnnounce uses its own
correct address, and verify the mailbox entry still points to the intended
module; use the mailbox and validatorAnnounce keys in the addresses YAML to
locate the fix.
In `@deployments/warp_routes/BTSG/base-bitsong-config.yaml`:
- Line 3: Update the addressOrDenom entry in the BTSG base config so the address
change includes its provenance source, as required by the coding guidelines. Add
a concise comment or annotation near the addressOrDenom setting (and the
collateral/router address in the same config) indicating whether the value came
from a monorepo PR or a deployment transaction, so the origin of the address
change is explicit and easy to trace.
In `@deployments/warp_routes/BTSG/base-bitsong-deploy.yaml`:
- Line 3: The custom address entries for interchainSecurityModule and
foreignDeployment need provenance notes. Update the BTSG base deployment YAML so
each referenced address includes a source annotation identifying where it came
from, such as the monorepo PR or deployment transaction, and keep the
identifiers tied to the existing interchainSecurityModule and foreignDeployment
entries for easy traceability.
---
Nitpick comments:
In `@chains/bitsong/metadata.yaml`:
- Around line 24-25: The BitSong metadata currently configures only a single
endpoint for grpcUrls/restUrls/rpcUrls, creating a single point of failure.
Update the BitSong chain entry in metadata.yaml to add at least one additional
backup provider for each of the affected URL lists, following the redundancy
pattern used by other chain entries, and keep the existing primary endpoints
as-is.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: cb1e41aa-d105-4bf3-9a49-8d145640b89b
⛔ Files ignored due to path filters (2)
chains/bitsong/logo.svgis excluded by!**/*.svgdeployments/warp_routes/BTSG/logo.svgis excluded by!**/*.svg
📒 Files selected for processing (5)
.changeset/add-bitsong-btsg.mdchains/bitsong/addresses.yamlchains/bitsong/metadata.yamldeployments/warp_routes/BTSG/base-bitsong-config.yamldeployments/warp_routes/BTSG/base-bitsong-deploy.yaml
| interchainGasPaymaster: "0x726f757465725f706f73745f6469737061746368000000040000000000000001" | ||
| interchainSecurityModule: "0x726f757465725f69736d00000000000000000000000000010000000000000001" | ||
| mailbox: "0x68797065726c616e650000000000000000000000000000000000000000000000" | ||
| merkleTreeHook: "0x726f757465725f706f73745f6469737061746368000000030000000000000000" | ||
| validatorAnnounce: "0x68797065726c616e650000000000000000000000000000000000000000000000" |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Missing address provenance note
None of the five address entries document where they come from (deployment tx, monorepo PR, etc.). As per coding guidelines, **/*.{sol,yaml,yml,json} should "Address provenance - Note source of address changes (monorepo PR, deployment tx)".
🤖 Prompt for 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.
In `@chains/bitsong/addresses.yaml` around lines 1 - 5, Add a provenance note for
each address entry in the addresses.yaml file so the source of the values is
documented per the config guidelines. Update the entries for
interchainGasPaymaster, interchainSecurityModule, mailbox, merkleTreeHook, and
validatorAnnounce with a brief comment or note indicating where each address
came from (for example, deployment transaction or monorepo PR), keeping the
existing symbols intact and making the source traceable.
Source: Coding guidelines
| @@ -0,0 +1,5 @@ | |||
| interchainGasPaymaster: "0x726f757465725f706f73745f6469737061746368000000040000000000000001" | |||
| interchainSecurityModule: "0x726f757465725f69736d00000000000000000000000000010000000000000001" | |||
| mailbox: "0x68797065726c616e650000000000000000000000000000000000000000000000" | |||
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
python3 - <<'EOF'
mailbox = "68797065726c616e650000000000000000000000000000000000000000000000"
validator = "68797065726c616e650000000000000000000000000000000000000000000000"
print("identical:", mailbox == validator)
print(bytes.fromhex(mailbox).decode(errors="replace"))
EOFRepository: hyperlane-xyz/hyperlane-registry
Length of output: 219
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- file outline ---\n'
ast-grep outline chains/bitsong/addresses.yaml --view expanded || true
printf '\n--- relevant lines ---\n'
cat -n chains/bitsong/addresses.yaml | sed -n '1,40p'
printf '\n--- search for validatorAnnounce and mailbox in bitsong config ---\n'
rg -n '^(mailbox|validatorAnnounce):' chains/bitsong/addresses.yaml chains/bitsong -g '*.yaml' -g '*.yml' || trueRepository: hyperlane-xyz/hyperlane-registry
Length of output: 261
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '--- chains/bitsong/addresses.yaml ---\n'
cat -n chains/bitsong/addresses.yaml
printf '\n--- other chain address files for comparison ---\n'
fd -a 'addresses.yaml' chains | sed -n '1,40p' | while read -r f; do
echo "### $f"
cat -n "$f" | sed -n '1,25p'
echo
doneRepository: hyperlane-xyz/hyperlane-registry
Length of output: 261
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- chains/bitsong/addresses.yaml ---'
cat -n chains/bitsong/addresses.yaml | sed -n '1,80p'
echo
echo '--- address keys in chains/bitsong/addresses.yaml ---'
rg -n '^(mailbox|validatorAnnounce):' chains/bitsong/addresses.yaml || true
echo
echo '--- similar address files under chains/ ---'
fd -a 'addresses.yaml' chains | while read -r f; do
echo "### $f"
cat -n "$f" | sed -n '1,40p'
echo
doneRepository: hyperlane-xyz/hyperlane-registry
Length of output: 50389
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo '--- chains/bitsong/addresses.yaml ---'
cat -n chains/bitsong/addresses.yaml | sed -n '1,20p'
echo
echo '--- matching keys ---'
rg -n '^(mailbox|merkleTreeHook|validatorAnnounce):' chains/bitsong/addresses.yamlRepository: hyperlane-xyz/hyperlane-registry
Length of output: 962
Mailbox and validatorAnnounce need different addresses
chains/bitsong/addresses.yaml maps both to 0x68797065726c616e650000000000000000000000000000000000000000000000. These are distinct modules, so this will break validator announcement discovery if left as-is.
🤖 Prompt for 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.
In `@chains/bitsong/addresses.yaml` at line 3, The addresses mapping for bitsong
currently assigns the same value to both mailbox and validatorAnnounce, which
should be distinct. Update the addresses in the bitsong addresses config so
validatorAnnounce uses its own correct address, and verify the mailbox entry
still points to the intended module; use the mailbox and validatorAnnounce keys
in the addresses YAML to locate the fix.
| @@ -0,0 +1,21 @@ | |||
| # yaml-language-server: $schema=../schema.json | |||
| tokens: | |||
| - addressOrDenom: "0x0357d61eDe1cbCB38981B11117cFcA1854CA28Ad" | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Note the address source for provenance
Neither the synthetic contract address (Line 3) nor the collateral/router address (Line 12) mention where they came from (deployment tx or monorepo PR). As per coding guidelines, address changes should note the "source of address changes (monorepo PR, deployment tx)".
Also applies to: 12-12
🤖 Prompt for 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.
In `@deployments/warp_routes/BTSG/base-bitsong-config.yaml` at line 3, Update the
addressOrDenom entry in the BTSG base config so the address change includes its
provenance source, as required by the coding guidelines. Add a concise comment
or annotation near the addressOrDenom setting (and the collateral/router address
in the same config) indicating whether the value came from a monorepo PR or a
deployment transaction, so the origin of the address change is explicit and easy
to trace.
Source: Coding guidelines
| @@ -0,0 +1,12 @@ | |||
| base: | |||
| decimals: 6 | |||
| interchainSecurityModule: "0x5aACdFDd332a44A6D13bF92406E2c868014cB98C" | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Note the address source for provenance
The custom ISM address (Line 3) and foreignDeployment (Line 10) don't reference their deployment source. As per coding guidelines, "Address provenance - Note source of address changes (monorepo PR, deployment tx)" applies here.
Also applies to: 10-10
🤖 Prompt for 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.
In `@deployments/warp_routes/BTSG/base-bitsong-deploy.yaml` at line 3, The custom
address entries for interchainSecurityModule and foreignDeployment need
provenance notes. Update the BTSG base deployment YAML so each referenced
address includes a source annotation identifying where it came from, such as the
monorepo PR or deployment transaction, and keep the identifiers tied to the
existing interchainSecurityModule and foreignDeployment entries for easy
traceability.
Source: Coding guidelines
b5ea5e6 to
ab1a83c
Compare
1 participant
Description
Add BitSong (
bitsong-2b, cosmos-native, Hyperlane domain 639639) and the BTSG warp route (Base ↔ BitSong).Files:
chains/bitsong/{metadata,addresses}.yaml+logo.svgdeployments/warp_routes/BTSG/{base-bitsong-config,base-bitsong-deploy}.yaml+logo.svgDeployment summary:
hyperlane-cosmosmodule): Mailbox, IGP (enforced fees), MerkleTreeHook, RoutingISM (default ISM).ubtsg(CosmosNativeHypCollateral); Base side is a syntheticHypERC20at0x0357d61eDe1cbCB38981B11117cFcA1854CA28Ad(6 decimals, no scaling).StaticMessageIdMultisigISMon Base (0x5aACdFDd332a44A6D13bF92406E2c868014cB98C, recorded in the deploy config).Backward compatibility
Yes — additions only (a new chain directory and a new warp route). No existing entries are modified.
Testing
pnpm run build(Zod schema parse of metadata/addresses/warp configs) andpnpm run test:unit— all auto-generatedbitsongchecks pass (metadata is valid,has name and domain defined,contains deployer details,valid reorgPeriod, block-explorer URL, etc.).Notes for reviewers:
base-bitsong-deploy.yamlare current operational keys (a Cosmos owner on BitSong and an EOA on Base). These will be moved to decentralized ownership — x/group or governance on BitSong, and a Safe on Base — in a follow-up; flagging so it's not a blocker.bitsong-2bhasfixed_min_gas_price: 0; thegasPrice: 0.025 ubtsgreflects our relayer's operational value.