Skip to content

feat: added support for hyperevm, starknet and abstract chains#248

Open
frolvanya wants to merge 19 commits intomainfrom
feat/hyperevm-and-starknet
Open

feat: added support for hyperevm, starknet and abstract chains#248
frolvanya wants to merge 19 commits intomainfrom
feat/hyperevm-and-starknet

Conversation

@frolvanya
Copy link
Contributor

@frolvanya frolvanya commented Feb 10, 2026

image

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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-client crate (builder, error types, RPC + tx submission, event parsing).
  • Extends OmniConnector and bridge-cli with 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-types rev bump, starknet crate).

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.

@frolvanya frolvanya force-pushed the feat/hyperevm-and-starknet branch from dc7c5bc to d53833e Compare February 10, 2026 16:16
@frolvanya frolvanya requested a review from a team February 13, 2026 02:52
@frolvanya frolvanya marked this pull request as ready for review February 13, 2026 02:53
frolvanya and others added 2 commits February 13, 2026 15:56
* feat: added support for abstract chain

* chore: added `CLAUDE.md` and `AGENTS.md`
@frolvanya frolvanya changed the title feat: added support for hyperevm and starknet chains feat: added support for hyperevm, starknet and abstract chains Mar 10, 2026
})?;

let evm_log = EvmLog {
removed: rpc_log.removed,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should always be true

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It defaults to false:
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, when I say true, I mean false...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see😅
Fixed in 878eddf

@frolvanya frolvanya requested a review from olga24912 March 11, 2026 19:12
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it going to be 300 seconds? I think we should limit it by 30-60 seconds rather than number of retries

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in c73d843

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message is still wrong.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in ed7dde7


let provider = Arc::new(JsonRpcClient::new(HttpTransport::new(url)));

let account = if let (Some(pk), Some(addr)) = (self.private_key, self.account_address) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we error if one of the fields is missing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better would be to match on any EVM chain, not just Abstract

transaction_options,
} => {
let sign_payload = match chain_kind {
ChainKind::Abs => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the variant for any EVM chain with ReadMPC

Copy link
Contributor

Copilot AI commented Mar 14, 2026

@kiseln I've opened a new pull request, #251, to work on those changes. Once the pull request is ready, I'll request review from you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants