• Add IOTA blockchain specification with 100+ JSON-RPC APIs
• Support IOTA mainnet and testnet chain configurations
• Create generic shell script for chain setup automation
• Enable provider staking and consumer portal functionality

IOTA blockchain specification with full API coverage

• Comprehensive IOTA specification with mainnet (IOTA) and testnet (IOTAT) configurations
• 100+ JSON-RPC API definitions including core, transaction, object, and indexer methods
• Block parsing directives for checkpoint-based finality with 5-block proof requirement
• Verification rules for chain-id validation and pruning/archive extension support
• Subscription APIs for event and transaction monitoring with 1000 compute units

specs/testnet-2/specs/iota.json

Generic chain initialization and provider setup script

• Generic bash script accepting CSV specs, chain ID, API interface, and provider config
• Automated setup including binary installation, Lava node initialization, and screen sessions
• Governance proposal submission for specs and plans with voting
• Provider staking and consumer portal launch with configurable parameters
• Logging infrastructure with debug output to testutil/debugging/logs directory

scripts/pre_setups/init_chain_only_with_node.sh

Description

init_chain_only_with_node.sh submits multiple lavad tx ... from the same signer
(alice/user1/servicer1) without waiting for inclusion (and backgrounds the first submit), which can
fail with "account sequence mismatch" and leave the setup partially applied.

Code

scripts/pre_setups/init_chain_only_with_node.sh[R56-69]

+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,$EXTRA_SPECS"
+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
+

Evidence

The script sends sequential transactions from the same accounts without using the repo-provided
lavad_tx_and_wait helper, which explicitly exists to avoid sequence mismatches when using default
sync broadcast mode.

scripts/pre_setups/init_chain_only_with_node.sh[56-69]
scripts/useful_commands.sh[122-149]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`scripts/pre_setups/init_chain_only_with_node.sh` broadcasts multiple `lavad tx ...` operations from the same signers without waiting for block inclusion (and backgrounds the first submit), which can cause intermittent `account sequence mismatch` failures.

### Issue Context
The repo already provides `lavad_tx_and_wait` to avoid this exact race by waiting for the tx hash to be included.

### Fix Focus Areas
- scripts/pre_setups/init_chain_only_with_node.sh[56-80]
- scripts/useful_commands.sh[122-149]

### Expected fix
- Replace the direct `lavad tx ...` calls (spec-add submit, votes, plans-add submit, subscription buy, stake-provider) with `lavad_tx_and_wait tx ...`.
- Remove backgrounding (`&`) from the spec-add submit so ordering is deterministic.
- Ensure failures propagate (e.g., check return codes or enable stricter bash flags if appropriate for this script).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The setup script runs killall screen, which terminates all screen sessions on the machine
(including unrelated ones), causing disruptive and potentially destructive side effects on
shared/dev environments.

Code

scripts/pre_setups/init_chain_only_with_node.sh[R43-44]

+killall screen
+screen -wipe

Evidence

The script uses a global process kill rather than stopping only the named sessions it creates
(node/provider1/consumers), so it will impact unrelated screen sessions every run.

scripts/pre_setups/init_chain_only_with_node.sh[43-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`scripts/pre_setups/init_chain_only_with_node.sh` uses `killall screen`, which kills *all* `screen` processes on the machine, not just the ones created by this script.

### Issue Context
This script creates specific session names (`node`, `provider1`, `consumers`). Cleanup should target those sessions only.

### Fix Focus Areas
- scripts/pre_setups/init_chain_only_with_node.sh[43-45]

### Expected fix
- Replace `killall screen` with scoped termination, e.g.:
 - `screen -S node -X quit 2>/dev/null || true`
 - `screen -S provider1 -X quit 2>/dev/null || true`
 - `screen -S consumers -X quit 2>/dev/null || true`
- Keep `screen -wipe` if desired, but avoid killing unrelated sessions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In specs/testnet-2/specs/iota.json, the GET_BLOCK_BY_NUM digest parsing omits
result_parsing.encoding, so Lava will not normalize the digest for cross-provider comparisons
unless the digest is already in the expected format.

Code

specs/testnet-2/specs/iota.json[R1242-1251]

+              {
+                "function_tag": "GET_BLOCK_BY_NUM",
+                "function_template": "{\"jsonrpc\":\"2.0\",\"method\":\"iota_getCheckpoint\",\"params\":[\"%d\"],\"id\":1}",
+                "result_parsing": {
+                  "parser_arg": [
+                    "0",
+                    "digest"
+                  ],
+                  "parser_func": "PARSE_CANONICAL"
+                },

Evidence

Hash normalization depends on resultParser.Encoding; if unset, the parser returns the raw string.
The existing Sui spec sets encoding: base64 for the analogous digest field, while IOTA does not,
increasing the risk of inconsistent hash comparison behavior if IOTA digests differ in encoding.

specs/testnet-2/specs/iota.json[1242-1252]
protocol/parser/parser.go[209-242]
protocol/parser/parser.go[515-534]
specs/testnet-2/specs/sui.json[1043-1054]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The IOTA spec's `GET_BLOCK_BY_NUM` parse directive parses `digest` but does not specify `result_parsing.encoding`. When encoding is omitted, Lava won't normalize the hash representation for comparisons.

### Issue Context
`protocol/parser/parser.go` normalizes hashes only when `encoding` is set; otherwise it returns the raw string. The Sui spec explicitly sets `encoding: base64` for the equivalent `digest` field.

### Fix Focus Areas
- specs/testnet-2/specs/iota.json[1242-1252]
- protocol/parser/parser.go[515-534]
- specs/testnet-2/specs/sui.json[1043-1054]

### Expected fix
- Add an explicit `encoding` under the `result_parsing` for the `GET_BLOCK_BY_NUM` directive (likely `"base64"` to mirror `sui.json`), or set the correct encoding after confirming the IOTA node's digest format.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.