feat: added support for hyperevm, starknet and abstract chains#248
feat: added support for hyperevm, starknet and abstract chains#248
Conversation
There was a problem hiding this comment.
Pull request overview
Adds Starknet and HyperEVM chain support to the bridge SDK/CLI by introducing a new Starknet bridge client and wiring Starknet/HyperEVM into existing omni-connector flows.
Changes:
- Introduces a new
starknet-bridge-clientcrate (builder, error types, RPC + tx submission, event parsing). - Extends
OmniConnectorandbridge-cliwith Starknet deploy/init/finalize/is-finalised support. - Adds HyperEVM into several “EVM-like” paths (address handling, finality checks, CLI deploy flow) and updates workspace dependencies (
omni-typesrev bump,starknetcrate).
Reviewed changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| bridge-sdk/connectors/omni-connector/src/omni_connector.rs | Adds Starknet client wiring + Starknet transfer/deploy/finality helpers; extends chain/address matching for Starknet/HyperEVM |
| bridge-sdk/connectors/omni-connector/Cargo.toml | Adds starknet-bridge-client + starknet deps |
| bridge-sdk/connectors/bridge-connector-common/src/result.rs | Maps StarknetBridgeClientError into BridgeSdkError variants |
| bridge-sdk/connectors/bridge-connector-common/Cargo.toml | Adds starknet-bridge-client dependency |
| bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs | Implements Starknet OmniBridge interactions (tx send/wait, calldata encoding, receipt event extraction) |
| bridge-sdk/bridge-clients/starknet-bridge-client/src/builder.rs | Adds a builder for Starknet RPC/account/contract config |
| bridge-sdk/bridge-clients/starknet-bridge-client/src/error.rs | Defines Starknet bridge client error model |
| bridge-sdk/bridge-clients/starknet-bridge-client/Cargo.toml | New crate manifest |
| bridge-sdk/bridge-clients/evm-bridge-client/src/evm_bridge_client.rs | Extends EVM omni-address conversion to accept HyperEVM, rejects Starknet addresses |
| bridge-cli/src/omni_connector_command.rs | Adds Starknet CLI subcommands and includes HyperEVM in some CLI routing |
| bridge-cli/src/main.rs | Adds Starknet config flags/env/default wiring |
| bridge-cli/src/defaults.rs | Adds Starknet RPC + chain-id defaults |
| bridge-cli/Cargo.toml | Adds starknet-bridge-client dependency |
| Cargo.toml | Adds new workspace member + workspace dep on starknet, bumps omni-types rev |
| Cargo.lock | Updates lockfile for new deps |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Show resolved
Hide resolved
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Show resolved
Hide resolved
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Show resolved
Hide resolved
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Show resolved
Hide resolved
dc7c5bc to
d53833e
Compare
* feat: added support for abstract chain * chore: added `CLAUDE.md` and `AGENTS.md`
bridge-sdk/bridge-clients/starknet-bridge-client/src/builder.rs
Outdated
Show resolved
Hide resolved
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Outdated
Show resolved
Hide resolved
bridge-sdk/bridge-clients/starknet-bridge-client/src/starknet_bridge_client.rs
Outdated
Show resolved
Hide resolved
| })?; | ||
|
|
||
| let evm_log = EvmLog { | ||
| removed: rpc_log.removed, |
There was a problem hiding this comment.
There was a problem hiding this comment.
Well… technically it could be false. But then it means a reorg happened and this event no longer exists. If that happens, it’s bad. I would check just in case that it is true.
There was a problem hiding this comment.
Yes, when I say true, I mean false...
There was a problem hiding this comment.
I would suggest to move encoding/conversion functions to a separate module
| } | ||
| } | ||
| Err(StarknetBridgeClientError::TransactionError(format!( | ||
| "Transaction {tx_hash:#066x} was not confirmed after {MAX_RETRIES} seconds" |
There was a problem hiding this comment.
Isn't it going to be 300 seconds? I think we should limit it by 30-60 seconds rather than number of retries
There was a problem hiding this comment.
The error message is still wrong.
|
|
||
| let provider = Arc::new(JsonRpcClient::new(HttpTransport::new(url))); | ||
|
|
||
| let account = if let (Some(pk), Some(addr)) = (self.private_key, self.account_address) { |
There was a problem hiding this comment.
Should we error if one of the fields is missing?
There was a problem hiding this comment.
@copilot which parts of this file are useful and which are not?
| /// The `proof_kind` selects which event to look for: | ||
| /// - `InitTransfer` for `fin_transfer` | ||
| /// - `DeployToken` for `bind_token` | ||
| pub async fn build_abs_mpc_sign_payload( |
There was a problem hiding this comment.
I wonder if this is better as a part of a bridge client. The logic is fully contained to a single chain with lots of chain-specific concepts. Finalities then could also be configured at a client level.
omni_connector can orchestrate by pulling this payload from a bridge client and passing to the prover.
| .await | ||
| .map(|hash| hash.to_string()) | ||
| } | ||
| BindTokenArgs::BindTokenWithMpcProofTx { |
There was a problem hiding this comment.
Since we are matching by chain_kind do we need to have separate variants for different types of proofs or should we have a single BindTokenWithTx?
| transaction_options, | ||
| } => { | ||
| let sign_payload = match chain_kind { | ||
| ChainKind::Abs => { |
There was a problem hiding this comment.
Better would be to match on any EVM chain, not just Abstract
| transaction_options, | ||
| } => { | ||
| let sign_payload = match chain_kind { | ||
| ChainKind::Abs => { |
There was a problem hiding this comment.
This should be the variant for any EVM chain with ReadMPC

Uh oh!
There was an error while loading. Please reload this page.