Chain support: Cardano and Midnight Network

[alba-press]

Chain Support: Cardano and Midnight Network

Hi — I'm building Ura finance , a cross-chain bridge and exchange stack that moves assets from Cardano, Solana, Ethereum, and BNB into Midnight Network (a privacy-focused L2 launched by IOG/Charles Hoskinson in March 2026).

OWS currently lists first-class support for EVM, Solana, XRPL, Sui, Bitcoin, Cosmos, Tron, TON, Spark, and Filecoin. Two ecosystems that are not yet represented:

Cardano

• Uses Ed25519 signing (not secp256k1)
• • UTXO-based, not account-based
• • • CAIP-2 identifier: cardano:mainnet / cardano:preview
• • • • BIP-44 derivation: m/1852'/1815'/0'
• • • • • Native multi-asset support
          Midnight Network
• Privacy-focused L2 to Cardano (and eventually all chains)
• • ZK-attested claim flows for cross-chain settlement
• • • NIGHT/DUST dual tokenomics
• • • • Capacity Exchange for fee abstraction
• • • • • AI agents on Midnight would benefit directly from OWS integration — the combination of private settlement + standardized agent wallet access is a natural fit
          We are actively building the bridge infrastructure between these ecosystems and would like to contribute Cardano and Midnight chain implementations to OWS if there is a path to do so.

Questions:

1. Is there a contribution path for new chain implementations?
2. 2. Is there a CAIP-2 identifier already registered for Midnight Network?
3. 3. Would the Ed25519 signing path needed for Cardano require changes to the core signing interface, or can it be handled as a chain-specific adapter?
      Happy to share our existing Ed25519 implementation and Cardano address encoding work from the zero-onev1 codebase as a starting point.

Repo: https://github.com/alba-press/zero-onev1

[alba-press]

Chain Support: Cardano and Midnight Network

Hi — I'm building zero-onev1, a cross-chain bridge and exchange stack that moves assets from Cardano, Solana, Ethereum, and BNB into Midnight Network (a privacy-focused L2 launched by IOG/Charles Hoskinson in March 2026).

OWS currently lists first-class support for EVM, Solana, XRPL, Sui, Bitcoin, Cosmos, Tron, TON, Spark, and Filecoin. Two ecosystems that are not yet represented:

Cardano

• Uses Ed25519 signing (not secp256k1)
• • UTXO-based, not account-based
• • • CAIP-2 identifier: cardano:mainnet / cardano:preview
• • • • BIP-44 derivation: m/1852'/1815'/0'
• • • • • Native multi-asset support
          Midnight Network
• Privacy-focused L2 to Cardano (and eventually all chains)
• • ZK-attested claim flows for cross-chain settlement
• • • NIGHT/DUST dual tokenomics
• • • • Capacity Exchange for fee abstraction
• • • • • AI agents on Midnight would benefit directly from OWS integration — the combination of private settlement + standardized agent wallet access is a natural fit
          We are actively building the bridge infrastructure between these ecosystems and would like to contribute Cardano and Midnight chain implementations to OWS if there is a path to do so.

Questions:

1. Is there a contribution path for new chain implementations?
2. 2. Is there a CAIP-2 identifier already registered for Midnight Network?
3. 3. Would the Ed25519 signing path needed for Cardano require changes to the core signing interface, or can it be handled as a chain-specific adapter?
      Happy to share our existing Ed25519 implementation and Cardano address encoding work from the zero-onev1 codebase as a starting point.

Repo: https://github.com/alba-press/zero-onev1

[ygd58]

Good news on Cardano — PR #186 already implements CIP-1852, Ed25519-BIP32 signing, and bech32 address encoding. It is currently open for review, so Cardano support is on the way.

On your three questions:

1. Contribution path for new chains — yes, the pattern is well-established. Add a ChainType variant in ows-core, implement the ChainSigner trait in ows-signer/src/chains/, and register the chain in KNOWN_CHAINS. PR feat(ows-signer): add Cardano chain support (CIP-1852, Ed25519-BIP32, bech32) #186 is a good reference implementation for Ed25519-based chains.

2. CAIP-2 for Midnight Network — there is no registered CAIP-2 namespace for Midnight yet as far as I can tell. You would likely need to propose one through the CAIP process (https://github.com/ChainAgnostic/CAIPs) before it could be added to OWS.

3. Ed25519 for Cardano — the signing interface already supports Ed25519 (used by Solana, TON, and the incoming Cardano support). No core interface changes needed for Cardano. Midnight would depend on what signing primitive it uses for agent-facing operations.

Happy to help if you want to open a Midnight Network chain PR once the CAIP-2 question is resolved.

[alba-press]

Thanks @ygd58 — quick update now that I’ve connected with the Midnight team.

On Cardano: we’ll use PR #186 as the reference for the Ed25519-BIP32 / CIP-1852 pattern and won’t duplicate that work.

On Midnight: the missing CAIP-2 identifier is a known gap on the Midnight side, tracked as MPS-0003: CAIP-2 Compliant Network Identifiers. Rather than guessing at a canonical ID, I’m preparing a draft MIP through Midnight’s MIP process after guidance from the team.

The leading direction in MPS-0003 appears to be network-name references following the Cosmos-style pattern, for example midnight:mainnet and midnight:preprod, but I don’t want to lock OWS to anything before the MIP is reviewed and accepted.

My current understanding of the dependency path is:

1. Midnight MIP defines the canonical CAIP-2 namespace/reference format.
2. The midnight namespace is registered through the ChainAgnostic process.
3. OWS can then consume the accepted identifier in KNOWN_CHAINS and any Midnight-specific signer implementation.

A few things I’d like to align on from the OWS side so the path is clean once the identifier lands:

• For KNOWN_CHAINS, is a shape like Chain { name: "midnight", chain_id: "midnight:mainnet" } what you would expect, or is there a convention for multi-network chains that I should mirror?
• Does OWS require the namespace to be formally registered at ChainAgnostic before adding it, or would an accepted Midnight MIP be enough to start integration work?
• For the actual Midnight chain implementation in ows-signer, would you prefer that to be opened in parallel, or sequenced after the CAIP-2 identifier is locked?

I’ll share the MIP draft/PR here once it exists so the OWS side has visibility into the identifier decision.

[ygd58]

Looking at KNOWN_CHAINS in ows-core, the pattern for non-EVM chains is consistently namespace:network-reference:

Chain { name: "cosmos",        chain_id: "cosmos:cosmoshub-4" }
Chain { name: "ton",           chain_id: "ton:mainnet"       }
Chain { name: "xrpl",          chain_id: "xrpl:mainnet"      }
Chain { name: "nano",          chain_id: "nano:mainnet"      }
Chain { name: "xrpl-testnet",  chain_id: "xrpl:testnet"      }

So Chain { name: "midnight", chain_id: "midnight:mainnet" } and Chain { name: "midnight-preprod", chain_id: "midnight:preprod" } would fit the existing convention exactly.

On the three questions:

1. KNOWN_CHAINS shape — yes, Chain { name: "midnight", chain_id: "midnight:mainnet" } matches the convention. Multi-network chains follow the xrpl pattern with separate entries per network (xrpl, xrpl-testnet, xrpl-devnet).

2. ChainAgnostic registration requirement — looking at the codebase, spark:mainnet and nano:mainnet are already in KNOWN_CHAINS without a formal ChainAgnostic registration, so an accepted Midnight MIP appears to be sufficient to start integration work.

3. Sequencing — based on how xrpl and other chains were added, the typical pattern is: chain entry in KNOWN_CHAINS first, then the signer implementation in ows-signer. These can be opened in parallel PRs. The KNOWN_CHAINS entry is trivial once the identifier is locked; the signer work can start in a draft PR against a placeholder chain_id and be updated once the MIP lands.

[alba-press]

Thanks this is very helpful.

That confirms the OWS side clearly: midnight:mainnet and midnight:preprod fit the existing KNOWN_CHAINS convention, and the chain entry / signer sequencing can be handled once the Midnight identifier is locked.

I’ll keep the Midnight MIP draft focused on that identifier decision and share the PR here once it exists so OWS has a clean reference point.

[TechRiderWR]

Hello, we’re currently working on adding support for both Cardano and Midnight in OWS and will share updates as the implementation progresses.

[alba-press]

Small update from the Midnight side: I opened a Draft PR for a Midnight CAIP-2 network identifier proposal.

It is still provisional and leaves the final identifier decision to Midnight core review, but it gives OWS a clean reference point for the expected shape of identifiers such as midnight:mainnet and midnight:preprod.

PR: midnightntwrk/midnight-improvement-proposals#186

[alba-press]

Small closing update: the Midnight CAIP-2 identifier draft has now been merged as MIP-0008.

I’ll treat MIP-0008 as the Midnight-side reference point and keep any OWS implementation discussion separate from the MIP itself.

Merged PR: midnightntwrk/midnight-improvement-proposals#186

[adacapo21]

Update on the Cardano side: I've rebased PR #186 onto the latest main — conflicts with the recently added NEAR/Nano chains are resolved, and the full workspace test suite passes. The HIGH-severity finding raised by the automated review (predictable fallback key for legacy wallets) has also been fixed, with a regression test.

The PR now covers everything raised here for Cardano:

• CIP-1852 derivation (m/1852'/1815'/0') with Ed25519-BIP32 signing — implemented as a chain-specific signer, so no changes to the core signing interface were needed (re: question 3)
• bech32 address encoding
• CAIP-2 identifiers cardano:mainnet, cardano:preprod, and cardano:preview registered in KNOWN_CHAINS
• Transaction broadcast via the Koios API

On sequencing: I'd suggest reviewing and merging #186 first — a Midnight implementation (now unblocked on the identifier side thanks to MIP-0008) can then follow the same Ed25519 signer pattern on top of it, rather than duplicating that groundwork.

@njdawn the PR is ready for review whenever you have a moment — it's mergeable and CI-green.

[alba-press]

Thanks for the update: this sequencing makes sense. We won’t duplicate the Cardano work and will treat PR #186 as the foundation. Once it is merged, I’m happy to test the Cardano implementation against Ura’s Preprod flows and share any bounded interoperability findings.

For Midnight, we’ll build on the same Ed25519 signer pattern where applicable, aligned with MIP-0008 for the network identifier, while keeping Midnight-specific signing requirements separate until those are confirmed.