feat: Avalanche C and P chains specs#2247
Merged
Merged
Conversation
Review Summary by QodoSeparate Avalanche C and P chain specs to testnet-2
WalkthroughsDescription• Separated Avalanche C and P chain specifications into testnet-2 • Removed mainnet-1 Avalanche specs, consolidating to testnet • Updated setup scripts to use separate chain IDs (AVAXCT, AVAXPT) • Added provider configuration examples for both chains • Enhanced C-chain spec with Warp APIs and atomic transaction support Diagramflowchart LR
A["mainnet-1 Avalanche specs"] -->|removed| B["Consolidated specs"]
C["testnet-2 Avalanche C spec"] -->|added| B
D["testnet-2 Avalanche P spec"] -->|added| B
E["Setup scripts"] -->|updated chain IDs| F["AVAXCT/AVAXPT"]
G["Provider configs"] -->|added examples| H["C-chain & P-chain"]
File Changes1. scripts/pre_setups/init_avax_c_only_with_node.sh
|
Code Review by Qodo
1. Missing variables.sh file
|
Comment on lines
+1
to
+47
| #!/bin/bash | ||
| __dir=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd ) | ||
| source "$__dir"/../useful_commands.sh | ||
| . "${__dir}"/../vars/variables.sh | ||
|
|
||
| LOGS_DIR=${__dir}/../../testutil/debugging/logs | ||
| mkdir -p $LOGS_DIR | ||
| rm $LOGS_DIR/*.log | ||
|
|
||
| killall screen | ||
| screen -wipe | ||
|
|
||
| echo "[Test Setup] installing all binaries" | ||
| make install-all | ||
|
|
||
| echo "[Test Setup] setting up a new lava node" | ||
| screen -d -m -S node bash -c "./scripts/start_env_dev.sh" | ||
| screen -ls | ||
| echo "[Test Setup] sleeping 20 seconds for node to finish setup (if its not enough increase timeout)" | ||
| sleep 5 | ||
| wait_for_lava_node_to_start | ||
|
|
||
| GASPRICE="0.00002ulava" | ||
| specs="specs/mainnet-1/specs/ibc.json,specs/mainnet-1/specs/tendermint.json,specs/mainnet-1/specs/cosmossdk.json,specs/testnet-2/specs/lava.json,specs/testnet-2/specs/avalanche_p.json" | ||
| lavad tx gov submit-legacy-proposal spec-add $specs --lava-dev-test -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE & | ||
| wait_next_block | ||
| wait_next_block | ||
| lavad tx gov vote 1 yes -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE | ||
| sleep 4 | ||
|
|
||
| # Plans proposal | ||
| lavad tx gov submit-legacy-proposal plans-add ./cookbook/plans/test_plans/default.json,./cookbook/plans/test_plans/temporary-add.json -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE | ||
| wait_next_block | ||
| wait_next_block | ||
| lavad tx gov vote 2 yes -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE | ||
|
|
||
| sleep 4 | ||
|
|
||
| CLIENTSTAKE="500000000000ulava" | ||
| PROVIDERSTAKE="500000000000ulava" | ||
|
|
||
| PROVIDER1_LISTENER="127.0.0.1:2221" | ||
|
|
||
| if [ -z "$AVA_BASE_URL" ]; then | ||
| echo "ERROR: Avalanche P-Chain endpoint is empty. Set AVA_BASE_URL in scripts/vars/variables.sh or environment. for example, 'api.avax-test.network/ext/bc'" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
1. Missing variables.sh file 🐞 Bug ✓ Correctness
The new/modified Avalanche pre-setup scripts source "../vars/variables.sh" and require AVA_BASE_URL, but the repository contains no scripts/vars/variables.sh, so the scripts will fail immediately when executed on a fresh checkout.
Agent Prompt
### Issue description
The Avalanche pre-setup scripts source a non-existent `scripts/vars/variables.sh` and instruct users to set `AVA_BASE_URL` in that file. This makes the scripts fail immediately on fresh checkouts.
### Issue Context
- `init_avax_c_only_with_node.sh` and `init_avax_p_only_with_node.sh` both `source`/dot-include `../vars/variables.sh` and hard-require `AVA_BASE_URL`.
- The repository currently has no `scripts/vars/variables.sh` (and no `scripts/vars` directory).
### Fix Focus Areas
- scripts/pre_setups/init_avax_c_only_with_node.sh[1-47]
- scripts/pre_setups/init_avax_p_only_with_node.sh[1-47]
### Suggested fix
Either:
1) Add `scripts/vars/variables.sh` (and directory) with documented defaults including `AVA_BASE_URL`, or
2) Stop sourcing that file and rely solely on environment variables / CLI flags, and update the error message accordingly.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Comment on lines
+1
to
+5
| { | ||
| "proposal": { | ||
| "title": "Add Specs: Avalanche C Chain", | ||
| "description": "Adding new specification support for relaying Avalanche C Chain data on Lava. Note: Warp APIs (warp_getMessage, etc.) require the node to be configured with warp-api-enabled=true", | ||
| "specs": [ |
There was a problem hiding this comment.
specs/testnet-2/specs/avalanche_c.json adds /C/rpc, /C/avax, and Warp/atomic APIs but the repo lacks a specs/*_test.md behavior doc required by AGENTS.md — should we add/update it for Avalanche C or record an approved exemption?
Finding type: AI Coding Guidelines | Severity: 🟢 Low
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
Before applying, verify this suggestion against the current code. In
specs/testnet-2/specs/avalanche_c.json around lines 1-5, the change adds large API
surface area (collections /C/rpc and /C/avax plus Warp and atomic APIs) but no
specs/*_test.md behavioral document was added. Create a new file
specs/testnet-2/specs/avalanche_c_test.md that follows the repo's AGENTS.md Testing
Guidelines and contains clear GIVEN–WHEN–THEN scenarios covering: (1) basic /C/rpc
JSON-RPC calls (eth_blockNumber, eth_getBlockByNumber) including expected parsing and
chain-id verification, (2) Warp APIs (warp_getMessage, warp_getMessageSignature, etc.)
including node config dependency (warp-api-enabled=true), and (3) /C/avax atomic tx
endpoints (avax.getAtomicTx, avax.issueTx) including stateful/hanging behavior and
expected success/failure cases. If you intentionally will not add tests, add a short
approved-exemption note file (e.g. specs/testnet-2/specs/avalanche_c_test_exemption.md)
referencing AGENTS.md and the approval rationale and approver name.
Comment on lines
+31
to
+35
| # Plans proposal | ||
| lavad tx gov submit-legacy-proposal plans-add ./cookbook/plans/test_plans/default.json,./cookbook/plans/test_plans/temporary-add.json -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE | ||
| wait_next_block | ||
| wait_next_block | ||
| lavad tx gov vote 2 yes -y --from alice --gas-adjustment "1.5" --gas "auto" --gas-prices $GASPRICE |
There was a problem hiding this comment.
The plan proposal block is copied verbatim from init_avax_c_only_with_node.sh into the P setup, should we extract the shared flow into a single parameterized script/helper like init_avax_common.sh --chain-id?
Finding type: Code Dedup and Conventions | Severity: 🟢 Low
Want Baz to fix this for you? Activate Fixer
Comment on lines
+1
to
+5
| { | ||
| "proposal": { | ||
| "title": "Add Specs: Avalanche P Chain", | ||
| "description": "Adding new specification support for relaying Avalanche P Chain data on Lava", | ||
| "specs": [ |
There was a problem hiding this comment.
specs/testnet-2/specs/avalanche_p.json defines /P but there's no specs/*_test.md GIVEN–WHEN–THEN write-up required by AGENTS.md, should we add the behavior doc or document an exemption?
Finding type: AI Coding Guidelines | Severity: 🟢 Low
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
Before applying, verify this suggestion against the current code. In
specs/testnet-2/specs/avalanche_p.json around lines 1-5, the commit adds a new Avalanche
P spec but no corresponding behavioral test write-up as required by AGENTS.md (Testing
Guidelines lines 17-19). Add a new file specs/testnet-2/specs/avalanche_p_test.md
containing clear GIVEN–WHEN–THEN narratives that cover the /P collection, the key
platform.* APIs (e.g., getBlock, getBlockByHeight, getHeight), and the
verification/parse_directives flow (happy path and at least one failure case).
Alternatively, if this spec should be exempt, update AGENTS.md (or add a
CONTRIBUTORS_EXEMPTIONS.md) with an explicit exemption entry referencing this file and
explaining why the GIVEN–WHEN–THEN doc is not applicable.
Comment on lines
+240
to
+244
| { | ||
| "function_template": "{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":1}", | ||
| "function_tag": "GET_BLOCKNUM", | ||
| "result_parsing": { | ||
| "parser_arg": [ |
There was a problem hiding this comment.
parse_directives is duplicated across specs, should we factor it into a shared helper/import like ETH1?
Finding type: Code Dedup and Conventions | Severity: 🟢 Low
Want Baz to fix this for you? Activate Fixer
Comment on lines
+511
to
+514
| "inheritance_apis": [], | ||
| "parse_directives": [], | ||
| "verifications": [] | ||
| } |
There was a problem hiding this comment.
warp_* add-on's verifications is empty so providers can register even if the node lacks warp-api-enabled=true, should we add a minimal verification like warp_getMessage?
Finding type: Logical Bugs | Severity: 🔴 High
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
Before applying, verify this suggestion against the current code. In
specs/testnet-2/specs/avalanche_c.json around lines 411 to 514, the warp add-on
collection (the JSON object with "collection_data" internal_path "/C/rpc" and "add_on":
"warp") has an empty "verifications" array. Add a minimal verification object to that
collection that calls a warp API (for example `warp_getMessage`) via a function_template
JSON-RPC request, sets a suitable function_tag (e.g. "VERIFICATION"), and specifies
result_parsing to assert a non-empty or present result (e.g. parser_func: "PARSE_BY_ARG"
or "DEFAULT" with parser_arg pointing to the result field). This will ensure
chain_fetcher.Validate detects lack of warp support at startup rather than at runtime.
Tomelia1999
approved these changes
Mar 30, 2026
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
3 participants
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.
User description
Description
Closes: #XXXX
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!in the type prefix if API or client breaking changemainbranchReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Enable Avalanche C- and P-chain flows by adding detailed mainnet and testnet specifications that enumerate the supported API collections, verifications, and imports for Lava providers. Adjust the provider examples and initialization scripts so test setups reference the new chain IDs, endpoints, and internal paths required by Avalanche nodes.
AVALANCHECT/AVALANCHEPTchain IDs, required internal paths, andAVA_BASE_URLendpoint variables when spinning up C- or P-chain providers and consumers.Modified files (4)
Latest Contributors(1)
specs/mainnet-1/specs/avalanche_*andspecs/testnet-2/specs/avalanche_*JSON proposals.Modified files (4)
Latest Contributors(1)