Flare, Base settings for v5. #2284
Conversation
WalkthroughConfiguration and network addresses updated across the project: registry and remote settings URLs are updated to new commit hashes in webapp and Tauri app constants, two new networks ("base" and "flare") are added to subgraph configuration with OrderBook contracts, and corresponding decimal float addresses are updated for these networks. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (4)
packages/webapp/src/lib/constants.ts(1 hunks)subgraph/networks.json(1 hunks)subgraph/src/float.ts(1 hunks)tauri-app/src/lib/services/loadRemoteSettings.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
packages/webapp/**/*.{svelte,ts}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Webapp must pass Svelte lint/format checks (npm run svelte-lint-format-check -w @rainlanguage/webapp)
Files:
packages/webapp/src/lib/constants.ts
packages/{webapp,ui-components}/**/*.{svelte,ts}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
If you modify frontend code, you must include a screenshot of the built webapp reflecting the change
Files:
packages/webapp/src/lib/constants.ts
packages/**
📄 CodeRabbit inference engine (AGENTS.md)
JavaScript/Svelte projects live under packages/* (webapp, ui-components, orderbook)
Files:
packages/webapp/src/lib/constants.ts
subgraph/**
📄 CodeRabbit inference engine (AGENTS.md)
Subgraph and related tooling live under subgraph/
Files:
subgraph/src/float.tssubgraph/networks.json
tauri-app/**
📄 CodeRabbit inference engine (AGENTS.md)
Desktop app code is in tauri-app (Rust + Svelte); src-tauri is not part of the Cargo workspace
Files:
tauri-app/src/lib/services/loadRemoteSettings.ts
🧠 Learnings (9)
📓 Common learnings
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2278
File: packages/webapp/src/lib/services/startLocalDbSync.ts:23-29
Timestamp: 2025-10-29T13:29:29.578Z
Learning: In packages/webapp/src/lib/services/startLocalDbSync.ts, the hard-coded default orderbook address '0x2f209e5b67A33B8fE96E28f24628dF6Da301c8eB' is a temporary placeholder that will be removed when new sync logic is introduced in the Raindex client, as documented in the NOTE comment.
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1925
File: packages/ui-components/src/lib/components/deployment/DeploymentSteps.svelte:87-104
Timestamp: 2025-06-18T16:42:40.608Z
Learning: In the orderbook UI components, changing deployments or networks requires page navigation, which automatically remounts components and refreshes data like available tokens. No additional refresh logic is needed for deployment/network changes.
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1916
File: packages/webapp/src/lib/services/resetActiveNetworkRef.ts:18-20
Timestamp: 2025-06-10T12:08:23.128Z
Learning: In the new NewConfig system that replaced ConfigSource in the rain.orderbook project, the settings store guarantees that $settings.orderbook.networks (and similar nested fields) will always be defined, so null/undefined safety checks are not needed when accessing these fields.
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1917
File: tauri-app/src/routes/orders/[network]-[orderHash]/+page.svelte:26-37
Timestamp: 2025-06-11T11:22:24.903Z
Learning: In the tauri-app codebase, the `settings` Svelte store is always initialized with a complete `Config` object whose `orderbook` field (and nested maps such as `orderbooks`, `subgraphs`, and `networks`) is guaranteed to exist, so optional chaining on those paths is unnecessary.
📚 Learning: 2025-04-09T12:58:03.399Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/lib/services/loadRegistryUrl.ts:5-19
Timestamp: 2025-04-09T12:58:03.399Z
Learning: In the rain.orderbook application, URL validation for registry URLs is handled at the frontend/component level before the `loadRegistryUrl` function is called, so additional validation within this function is not necessary.
Applied to files:
packages/webapp/src/lib/constants.ts
📚 Learning: 2025-04-09T13:00:24.640Z
Learnt from: hardingjam
Repo: rainlanguage/rain.orderbook PR: 1565
File: packages/webapp/src/__tests__/registryManager.test.ts:227-238
Timestamp: 2025-04-09T13:00:24.640Z
Learning: In the rain.orderbook project, error handling was added to the RegistryManager to handle localStorage exceptions, addressing part of the verification agent's suggestions. The team should also consider testing extremely long URLs that might approach browser limits.
Applied to files:
packages/webapp/src/lib/constants.ts
📚 Learning: 2025-07-21T16:34:31.193Z
Learnt from: 0xgleb
Repo: rainlanguage/rain.orderbook PR: 1911
File: crates/subgraph/src/types/impls.rs:7-15
Timestamp: 2025-07-21T16:34:31.193Z
Learning: In the rainlanguage/rain.orderbook codebase, user 0xgleb considers breaking changes that remove unsafe default behaviors to be intentional and acceptable. Specifically, the get_decimals() method in crates/subgraph/src/types/impls.rs was intentionally changed to return MissingDecimals error instead of defaulting to 18 decimals, as defaulting to 18 is considered unsafe and should never have been done.
Applied to files:
subgraph/src/float.ts
📚 Learning: 2025-08-04T09:07:00.160Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2048
File: packages/webapp/src/__tests__/WithdrawModal.test.ts:36-37
Timestamp: 2025-08-04T09:07:00.160Z
Learning: In packages/webapp/src/__tests__/WithdrawModal.test.ts and similar test files, findolor considers it acceptable to directly unwrap .value from Float.fromFixedDecimal() and Float.parse() calls without explicit error handling, preferring to keep test fixtures simple rather than adding comprehensive error checking.
Applied to files:
subgraph/src/float.ts
📚 Learning: 2025-07-16T14:33:03.454Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2001
File: packages/ui-components/src/lib/services/historicalOrderCharts.ts:18-21
Timestamp: 2025-07-16T14:33:03.454Z
Learning: User findolor is comfortable with potential precision loss when converting formatted decimal strings to JavaScript Number type in historicalOrderCharts.ts, preferring the simpler implementation over using decimal arithmetic libraries like decimal.js.
Applied to files:
subgraph/src/float.ts
📚 Learning: 2025-10-29T13:29:29.578Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2278
File: packages/webapp/src/lib/services/startLocalDbSync.ts:23-29
Timestamp: 2025-10-29T13:29:29.578Z
Learning: In packages/webapp/src/lib/services/startLocalDbSync.ts, the hard-coded default orderbook address '0x2f209e5b67A33B8fE96E28f24628dF6Da301c8eB' is a temporary placeholder that will be removed when new sync logic is introduced in the Raindex client, as documented in the NOTE comment.
Applied to files:
subgraph/src/float.tssubgraph/networks.json
📚 Learning: 2025-10-06T11:28:30.692Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 2145
File: crates/common/src/raindex_client/local_db/query/fetch_orders/query.sql:6-7
Timestamp: 2025-10-06T11:28:30.692Z
Learning: In `crates/common/src/raindex_client/local_db/query/fetch_orders/query.sql`, the orderbook_address is currently hardcoded to '0x2f209e5b67A33B8fE96E28f24628dF6Da301c8eB' because the system only supports a single orderbook at the moment. Multiorderbook logic is not yet implemented and will be added in the future.
Applied to files:
subgraph/src/float.tssubgraph/networks.json
📚 Learning: 2025-06-10T12:04:54.107Z
Learnt from: findolor
Repo: rainlanguage/rain.orderbook PR: 1916
File: packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json:182-195
Timestamp: 2025-06-10T12:04:54.107Z
Learning: In test fixture files like `packages/ui-components/src/lib/__fixtures__/settings-12-11-24.json`, network configuration inconsistencies (such as matchain using Polygon's RPC, chainId, and currency while having its own network key) are acceptable since they are used for testing purposes only.
Applied to files:
subgraph/networks.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-tauri (ubuntu-22.04, true)
- GitHub Check: Deploy-Docs-Preview
- GitHub Check: Deploy-Preview-Push
🔇 Additional comments (3)
tauri-app/src/lib/services/loadRemoteSettings.ts (1)
1-2: Commit hash verified and settings file is valid.The remote settings URL referencing commit
d57c3aa77b63f90535957947d15146c0182367dcis accessible and returns valid YAML configuration. The settings.yaml file exists at the specified commit and contains the expected structure with network configurations for v5.packages/webapp/src/lib/constants.ts (1)
1-4: Screenshots required per coding guidelines; URLs verified as accessible.Both URLs are accessible and return valid content:
- Registry URL contains expected strategy entries for the referenced commit
- Settings URL contains valid YAML configuration with base and flare network definitions (version 3)
However, per coding guidelines for frontend code changes (
packages/{webapp,ui-components}/**/*.{svelte,ts}), please provide a screenshot of the built webapp showing the application correctly loads with the new settings. This is required to confirm the changes work as intended in the application.subgraph/networks.json (1)
14-25: Verify OrderBook addresses and startBlocks through blockchain explorers.The addresses and startBlocks for the new Base and Flare networks are only present in
subgraph/networks.jsonwith no supporting documentation in the codebase. These specific contract deployments cannot be verified through general web search or code analysis.To confirm:
- Base OrderBook
0x52CEB8eBEf648744fFDDE89F7Bc9C3aC35944775on Base mainnet (chain ID 8453)- Flare OrderBook
0x8Dbc50485e7C6994923B9A2c603a2B6b2d8Eef64on Flare mainnet (chain ID 14)- The corresponding startBlock values match the actual deployment transaction blocks
Please verify these against the respective block explorers and deployment records.
| if (network == "flare") { | ||
| return Address.fromString("0xDbcb964760d021e18A31C9A731d8589c361E0E20"); | ||
| return Address.fromString("0x2F665EcE3345bF09197DAd22A50dFB623BD310A7"); | ||
| } else if (network == "base") { | ||
| return Address.fromString("0x83e4c7732e715b5E7310796A4A2a21d89f3FB59A"); | ||
| return Address.fromString("0x2F665EcE3345bF09197DAd22A50dFB623BD310A7"); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
Verify that both networks use the same DecimalFloat address.
Both "flare" and "base" networks are now configured to use the identical DecimalFloat address (0x2F665EcE3345bF09197DAd22A50dFB623BD310A7). Please confirm this is intentional, as:
- The same address on different networks could indicate a deterministic deployment (e.g., CREATE2) or a shared contract design.
- Using an incorrect DecimalFloat address would cause calculation errors in the subgraph indexing.
🏁 Script executed:
#!/bin/bash
# Description: Search for any documentation or configuration about this DecimalFloat address
# Search for the address in the codebase
rg -n "0x2F665EcE3345bF09197DAd22A50dFB623BD310A7" --type ts --type rust --type json -C 2
# Search for any comments or docs about DecimalFloat deployment
rg -n -i "decimalfloat.*deploy" --type ts --type md -C 2Length of output: 538
🏁 Script executed:
#!/bin/bash
# Get full context of the function containing the address usage
rg -n "DecimalFloat\|getDecimalFloat" subgraph/src/float.ts -A 30 -B 5
# Search for any deployment or configuration documentation
fd -e md -e txt -e json | xargs grep -l -i "decimalfloat\|0x2F665EcE" 2>/dev/null || echo "No docs found"
# Look for deployment or configuration JSON files
fd -e json . | xargs grep -l -i "flare\|base" 2>/dev/null | head -5Length of output: 81
🏁 Script executed:
#!/bin/bash
# Search for DecimalFloat contract on common block explorers to verify if it's a deterministic deployment
echo "Searching for DecimalFloat contract information..."
# This would typically use curl to check public blockchain data, but we'll rely on codebase analysisLength of output: 50
🏁 Script executed:
#!/bin/bash
# Get full context of the function containing the address usage
rg -n "getDecimalFloat\|function.*float\|DecimalFloat" subgraph/src/float.ts -A 30 -B 5
# Search for any comments or documentation in the file itself
cat subgraph/src/float.ts | head -50
# Look for deployment or network configuration files
fd . -type f -name "*config*" -o -name "*deploy*" -o -name "*network*" | grep -E "\.(ts|json|yaml|yml)$" | head -10Length of output: 1473
🌐 Web query:
DecimalFloat contract Ethereum Flare Base deterministic deployment CREATE2
💡 Result:
Short answer: use a CREATE2 factory (or the chain’s predeploy/Create2 system contract) to deploy the DecimalFloat bytecode with the same salt, identical compiled bytecode (including metadata hash) and identical deployer address across Ethereum and Flare Base. That guarantees the same deterministic address: address = keccak256(0xff ++ deployer ++ salt ++ keccak256(bytecode))[12:]. Use identical compiler version/optimizer settings and identical constructor calldata so bytecodeHash matches on both chains. [1][2][6]
Steps (concise):
- Compile DecimalFloat with the exact same Solidity version, optimizer settings and any metadata/settings that affect bytecode. Include constructor args in the init code.
- Compute bytecodeHash = keccak256(init_code).
- Choose a bytes32 salt (same on both chains).
- Deploy a CREATE2 factory at the same deployer address on both chains (either deploy your factory at the same EOA address or use a predeploy/system Create2 factory if the chain provides one). Chains like Flare/other EVMs sometimes ship a CREATE2 factory/predeploy; EIP‑7997 proposes a standard deterministic factory predeploy to make this easier. [3][7][2]
- Call factory.create2(salt, init_code) (or new Contract{salt: salt}() where supported) and verify the computed address matches the keccak formula above. Use tooling (Hardhat/Foundry/Alchemy/OpenZeppelin Defender) that supports CREATE2 workflows. [1][6][3]
Chain-specific notes:
- Flare is an EVM-compatible chain; follow Flare dev docs for deployment RPC and toolchain, and you can deploy via the same CREATE2 approach. If Flare exposes a built-in Create2 factory/predeploy, you can use that to avoid having different deployer addresses. Check Flare docs for the RPC/explorer and any Create2 system contract status. [0][4][5]
References:
- CREATE2 explanation and factory examples (Alchemy/OpenZeppelin). [1][6]
- EIP-7997 (Deterministic Factory Predeploy) — standard for a shared CREATE2 factory predeploy. [2]
- Tutorials and chain docs (Foundry/ZK & Flare developer docs) showing factory/create2 usage and Flare deployment info. [3][4]
If you want, I can:
- compute the CREATE2 address for a given compiled DecimalFloat bytecode + salt, or
- produce a minimal Create2Factory.sol + deploy script (Hardhat/Foundry) targeting Ethereum and Flare Base.
🏁 Script executed:
#!/bin/bash
# Check networks.json for any deployment configuration or comments
cat subgraph/networks.json
# Search for any git history or commit messages mentioning DecimalFloat or these addresses
git log --all --oneline --grep="DecimalFloat\|0x2F665EcE" 2>/dev/null || echo "Git history not available"
# Look for any deployment scripts or hardhat config
fd . -type f \( -name "*.deploy.ts" -o -name "hardhat.config.*" -o -name "foundry.toml" \) 2>/dev/null | head -5Length of output: 675
🏁 Script executed:
#!/bin/bash
# Get details of the DecimalFloat deployment commit
git show a04ceff4b --stat 2>/dev/null || echo "Cannot access commit details"
# Search for any README or documentation about network deployments
find . -name "README*" -o -name "DEPLOY*" -o -name "NETWORKS*" | head -5 | xargs cat 2>/dev/null | grep -i "decimal\|flare\|base" || echo "No relevant deployment docs"
# Check if there are any comments in related files about address selection
rg -n "0x2F665EcE\|CREATE2\|deterministic" --type ts -B 3 -A 3 subgraph/src/ 2>/dev/null || echo "No deployment pattern comments found"Length of output: 2366
Add an inline comment documenting the CREATE2 deterministic deployment strategy for shared addresses.
The identical DecimalFloat address on both flare and base (0x2F665EcE3345bF09197DAd22A50dFB623BD310A7) appears intentional based on code patterns—flare and base share one address, while linea and mainnet share another, with remaining networks having unique addresses. This pattern strongly suggests deterministic deployment (e.g., CREATE2 with identical bytecode/salt/deployer on compatible chains). However, this design is completely undocumented in the code.
Add a comment above the getDecimalFloatAddress() function explaining that shared addresses across networks use CREATE2 deterministic deployment:
// DecimalFloat is deployed deterministically (CREATE2) on compatible EVM chains,
// so the same address is used across chains with identical deployment configurations.
// Flare and Base share one address; Linea and Mainnet share another; others are unique.
🤖 Prompt for AI Agents
In subgraph/src/float.ts around lines 16 to 19, add an inline comment above the
getDecimalFloatAddress() function stating that DecimalFloat is deployed
deterministically via CREATE2 on compatible EVM chains so identical deployment
configs yield the same address across chains (e.g., Flare and Base share
0x2F665EcE3345bF09197DAd22A50dFB623BD310A7; Linea and Mainnet share another;
others are unique), using the suggested three-line comment text to document the
CREATE2 deterministic deployment strategy.
Motivation
Update flare, base settings for v5.
Checks
By submitting this for review, I'm confirming I've done the following:
Summary by CodeRabbit
New Features
Chores