WebisoftMidnight ↔ Cosmos Bridge
A scope of work for a trustless bridge from Midnight into the Cosmos / IBC ecosystem. The one-way Midnight → Cosmos deposit path verifies real GRANDPA finality on-chain today; this proposal hardens it to production and makes it bidirectional.
Prepared by Utkarsh Varma, Webisoft Technologie Inc.
Overview
Midnight is a Substrate chain with GRANDPA finality; the Cosmos ecosystem speaks IBC. A purpose-built Cosmos SDK chain — the interop chain — can verify Midnight's consensus and state proofs entirely on-chain and then relay assets to 189+ IBC networks. That makes a trustless bridge feasible without oracles or a multisig committee in the deposit path.
This document has two parts. Engineering explains how the bridge is made possible, what runs today, and how each step is cryptographically grounded in the real IBC, Cosmos and Midnight specifications. Breakdown of Work turns that into two fixed milestones — $40,000 to harden the proven one-way path into a production, IBC-native light client, and $30,000 to make it bidirectional and roll it out across the ecosystem.
The starting point is real, not a slide. We brought the demo stack up locally — a live Midnight node and the Cosmos interop chain, both producing blocks, with the bridge module active and the demo app connected to both. The honest status of every link — proven, partial, and planned — is laid out in section 02.
Total
$70,000USD
Milestones
$40K + $30K
Timeline
~13 weeks
One-way deposit
Working
How the bridge is made possible
Engineering
Midnight is a Substrate chain that finalizes blocks with GRANDPA — ed25519 authorities reaching a 2/3+1 weighted supermajority over blake2b-256 block headers — with global state committed in a base-16 Patricia-Merkle trie and encoded with SCALE. The interop chain is a standard Cosmos SDK / ibc-go v8 application. The bridge is possible because a Cosmos chain can run a light client that re-derives Midnight's finality and state proofs entirely on-chain: verify the GRANDPA justification's ed25519 signatures and supermajority, anchor the justification to the blake2b-256 hash of the SCALE-encoded header, store that header's state root, then verify a Patricia-Merkle membership proof of a bridge deposit against that GRANDPA-verified root before minting. No oracle and no external committee sits in that deposit path.
What works today is the cryptographic core of this one-way deposit path, running in the native Go x/midnightbridge keeper. The GRANDPA verifier is wire-correct: it reconstructs the 53-byte precommit message with a u32 block number, verifies each precommit with ed25519, binds every vote to the justification target, rejects duplicates, and enforces the (2·total)/3+1 threshold. It checks that the justification target equals blake2b-256(SCALE(header)), and a mint requires a state root previously stored by a GRANDPA-verified client update. We brought this stack up locally — a real Midnight node and the Cosmos interop chain both producing blocks, with the bridge module active and the demo app connected to both.
What we will do is harden this proven core into a production, IBC-native bridge and then make it bidirectional. M1 ports the verifier into a governance-deployable ICS-08 08-wasm client with the correct ibc-go ABI, upgrades the trie proof from key-existence to key-and-value binding against a real Midnight bridge pallet, pins the GRANDPA authority set, opens a real ICS-20 channel, hardens the relayer, and validates against a non-dev multi-validator node. M2 adds the Cosmos-to-Midnight return path as a 3-of-5 BIP-340 attestor committee with a documented migration toward trust-minimized verification, a real ZK privacy gateway, multi-chain rollout, and an independent security review on a public testnet.
GRANDPA finality verified on-chain, wire-correct
VerifyGrandpaJustification performs per-precommit ed25519 verification over the reconstructed 53-byte message (1-byte tag, target hash, u32 target number LE, u64 round LE, u64 set id LE). It rejects unknown authorities and duplicate votes, binds each precommit to the justification target hash and number, and enforces a (2·total)/3+1 weighted supermajority. This is the on-chain verifier; it matches real Substrate GRANDPA for the deposit path.
Header anchoring with blake2b-256
The keeper computes blake2b-256 over the SCALE-encoded Midnight header and requires the GRANDPA justification target hash to equal it. This binds the finality proof to a concrete header whose state_root field becomes the trusted commitment root. The end-to-end test independently recomputes this hash against the live node and asserts equality.
State-root provenance gates every mint
ConfirmDeposit calls LoadVerifiedStateRoot for the deposit height, which only returns a root previously stored by a GRANDPA-verified client update. No verified root means no mint. This separates consensus verification from the state-proof step while keeping both trustless.
Substrate Patricia-Merkle trie proof verification
The proof decoder parses the SCALE Vec<Vec<u8>> read proof into trie nodes, and the verifier walks the base-16 Patricia-Merkle trie by nibbles, re-hashing nodes with blake2b-256 and checking they chain back to the GRANDPA-verified state root. The current working tree requires the specific bridge-transfer storage key derived with twox128 and blake2_128_concat.
Deduplication, caps and circuit breakers
A deposit commitment blake2b256(txHash, receiver, amount, denom) plus the raw txHash are checked and marked, preventing replay. Per-transaction and per-epoch mint caps, a circuit breaker, staleness bounds, strictly increasing height, and an equivocation freeze on conflicting state roots protect the mint path.
Inherited IBC stack and ICS-20 onward transfer
The Cosmos app wires real ibc-go v8: core IBC, the ICS-20 transfer keeper composed with erc20, rate-limit, fee and packet-forward middleware, 07-tendermint, and 08-wasm backed by a real WasmVM with the gov account as authority. Bridge-minted tokens are standard bank coins (denom midnight/DUST in the demo), so they can in principle be sent through this generic ICS-20 stack like any native denom — but the mint path and the transfer stack are separate code paths today; wiring them and opening a real channel are scoped work. The hard, chain-specific work is the Midnight light client, not the transport.
What the deposit proves, and the honest gap
As committed at HEAD the trie-to-mint link is satisfied by a structural-integrity fallback that binds no key and no amount, and the authority set can fall back to trust-on-first-use, all against a single-validator dev node with a mocked Cardano follower. Uncommitted working-tree changes remove the fallback, but value-binding against a real bridge pallet and a pinned multi-validator authority set are M1 deliverables. The bridge proves Midnight reached finality on a state root; binding the mint to a specific deposit value is the hardening target.
Bidirectional return path and privacy
Cosmos-to-Midnight today only burns the wrapped asset and emits a burn event; nothing yet credits Midnight. M2 adds a 3-of-5 BIP-340 attestor committee verified by Midnight's native signature checks, then a migration toward real CometBFT light-client verification. The privacy gateway, today a stub, gains real Groth16 verification and nullifier dedup so value unshields only at the boundary and re-shields on return.
Midnight → Cosmos, step by step
The One-Way Transaction
A deposit from Midnight to Cosmos follows one finality-bound path. The relayer only carries proofs; every check happens on the interop chain.
Unshields and locks DUST into the bridge pallet, emitting an UnshieldedTokens event recorded in bridge storage. (Per the Midnight ledger NIGHT is the transferable asset; correcting the bridged asset from DUST to NIGHT is M1 work.)
ZSwap eUTXO: Pedersen value commitments, SHA-256 coin commitment and nullifier; value moves from the shielded sets into the public UTXO set.
Finalizes the block containing the deposit and produces a justification.
ed25519 precommit signatures from the authority set over the 53-byte message; 2/3+1 weighted supermajority; blake2b-256 header hash.
Subscribes to GRANDPA justifications, fetches the header and a state read proof for the bridge deposit key.
SCALE decoding of header and justification; state_getReadProof returns Patricia-Merkle trie nodes; storage key derived via twox128 and blake2_128_concat.
Processes MsgUpdateMidnightClient: verifies the justification and stores the header state root for that height.
per-precommit ed25519 verify, duplicate-vote rejection, target binding, (2·total)/3+1 threshold, blake2b-256 header match.
Processes MsgConfirmDeposit: verifies the trie membership proof against the stored state root, then mints.
Patricia-Merkle-16 trie walk with blake2b-256 node hashing against the verified root; bridge-transfer key membership; dedup commitment; per-tx and epoch caps.
Mints the wrapped token (denom midnight/DUST in the demo) to the receiver and emits a mint event.
bank MintCoins then send to account under the midnight/ denom prefix; supply bounded by the epoch mint cap.
Onward transfer (scoped, not yet wired): the wrapped coin can be sent over an IBC channel to a counterparty chain as a separate ICS-20 transfer once a channel is opened.
ICS-20 ics20-1 unordered channel; packet commitment sha256(timeoutTimestamp ‖ timeoutHeight ‖ sha256(data)); per-channel escrow; timeout and ack refund.
Security model
Cryptographic Chain of Trust
Deposit path trust assumption
A mint requires a GRANDPA justification finalized by 2/3+1 of Midnight's authority set — the same honest-supermajority assumption Midnight itself relies on. The relayer cannot forge finality or state.
State-proof binding
The mint is gated on a Patricia-Merkle membership proof against a GRANDPA-verified state root. In the working tree this is key-bound to the bridge transfer key; full value-binding (amount, recipient, denom) against a real bridge pallet is the M1 target so the minted amount is not relayer-asserted.
Authority-set anchor
Today the first update can bootstrap the authority set from the justification's own signers (trust-on-first-use); signatures are real but the canonical set is not independently pinned. M1 pins the set at genesis or governance and implements delayed rotation.
Relayer is permissionless and untrusted
Like every IBC relayer, a malicious relayer can delay or censor but cannot mint without valid GRANDPA and trie proofs. A default-deny relayer whitelist additionally gates ConfirmDeposit.
Misbehaviour and circuit breakers
Conflicting state roots at one height freeze the client (equivocation freeze), and per-tx, epoch-mint-cap and staleness checks plus a circuit breaker bound damage from any single bad input.
Return-path trust (M2)
The Cosmos-to-Midnight return path begins as a 3-of-5 BIP-340 attestor committee: safety requires m-of-n collusion, liveness tolerates n-m offline, with nonce replay protection. This is explicitly a trusted-committee step with a documented migration toward CometBFT verification.
Privacy boundary
Value is exposed only at the bridge boundary: unshielded on deposit and re-shielded on return. The M2 privacy gateway enforces this with real Groth16 verification and nullifier dedup.
Dev-environment caveat
The bridge demo and e2e run against a single-validator Midnight dev node with a mocked main-chain follower, so 2/3+ of validators is 2/3 of one. M1 validates against a multi-validator node following a real Cardano main chain.
Grounded in real IBC, Cosmos and Midnight specs
Compatibility & Specifications
Every Midnight primitive maps to a concrete IBC / Cosmos requirement. The matrix below is the engineering contract for the bridge, with an honest status on each row.
| Midnight property | Cosmos / IBC requirement | Bridging mechanism | Status |
|---|---|---|---|
| GRANDPA finality, ed25519 authorities, 2/3+1 supermajority | ICS-02 client validity predicate | On-chain GRANDPA justification verification in the keeper today; ported to ICS-08 08-wasm in M1 | Working |
| ed25519 precommit signatures over 53-byte message, u32 block number | ICS-02 signature verification | Precommit message encoder plus ed25519 verify per precommit, wire-correct | Working |
| BlakeTwo256 header hashing over SCALE-encoded header | ConsensusState commitment root anchoring | blake2b-256(SCALE(header)) matched to target; header state_root stored as the root | Working |
| Patricia-Merkle-16 state trie and state_root | ICS-23 verifyMembership | Trie walker against the GRANDPA-verified root; key-bound today, value-bound in M1 | Partial |
| SCALE codec for headers, justifications and proofs | 08-wasm encoding-agnostic client message | SCALE decoders rewrapped behind the ibc-go client_message Binary ABI in M1 | Partial |
| Unshielding into the public UTXO set as bridge entry | ICS-20 source-zone lock then mint | Bridge pallet UnshieldedTokens event becomes the deposit record proven by the trie proof | Partial |
| GRANDPA ScheduledChange authority-set rotation | ICS-02 handling of validator-set changes | ScheduledChange digest parsing; delay-zero today, delayed rotation in M1 | Partial |
| Authority set as the trust anchor | ICS-02 trusted client state validator set | Pin the set at genesis or governance, removing trust-on-first-use | Planned |
| Block timestamp for client status and timeouts | ICS-02 getTimestampAtHeight, ICS-04 timeouts | Read the real header timestamp, enabling trusting-period and packet timeouts | Planned |
| 08-wasm light client deployable by governance | ICS-08 MsgStoreCode, checksum allowlist, MsgCreateClient | Rewrite contract to the real ibc-go ABI and run the governance deploy | Planned |
| midnight wrapped token onward transfer | ICS-20 fungible token transfer over a real channel | Open an ics20-1 channel via Hermes or Hyperspace and route the minted bank coin through the transfer stack | Planned |
| Cosmos-to-Midnight return with CometBFT proof | 07-tendermint commit and IAVL proof on Midnight | 3-of-5 BIP-340 attestor committee first, migrating toward a real light client | Planned |
Specification grounding
Defines ClientState, ConsensusState, verifyClientMessage, checkForMisbehaviour, updateState and verifyMembership the Midnight client must implement.
cosmos/ibc · ics-002-client-semantics
08-wasm hosts client logic as governance-deployed Wasm with sudo VerifyMembership and UpdateState; deploy via MsgStoreCode and a checksum allowlist.
cosmos/ibc · ics-008-wasm-client
verifyMembership and verifyNonMembership against a CommitmentRoot with position-binding; the Substrate base-16 trie must satisfy completeness and soundness.
cosmos/ibc · ics-023 · cosmos/ics23
ics20-1 unordered channels, source-zone escrow and sink-zone burn, denom trace port/channel/baseDenom, timeout and failed-ack refunds.
cosmos/ibc · ics-020-fungible-token-transfer
Packet commitment sha256(timeoutTimestamp ‖ timeoutHeight ‖ sha256(data)), acknowledgement and receipt proofs, timeouts requiring getTimestampAtHeight.
cosmos/ibc · ics-004-channel-and-packet-semantics
MsgStoreCode signer must equal the gov authority, checksum added to the on-chain allowlist, upgrades via gov-gated MsgMigrateContract.
ibc.cosmos.network · v8 wasm light-clients
Instant deterministic finality with greater-than-2/3 voting power and ed25519 consensus keys, so a Cosmos header at height H is final for the counterparty client.
docs.cometbft.com · spec/consensus
Return-path verification of Cosmos into Midnight needs ed25519 commit-signature and validator-set checks within the trusting period plus IAVL proofs against app_hash.
cosmos/ibc-go · 07-tendermint
AURA block production with sr25519 and GRANDPA finality with ed25519, BlakeTwo256 header hashing, SCALE encoding, BEEFY over Keccak-256 MMR.
docs.midnight.network · network-architecture
Shielded ZSwap eUTXO with SHA-256 coin commitments and nullifiers and Pedersen value commitments; UnshieldedOffer moves value into the public UTXO set as the bridge entry point.
midnight-ledger · zswap, intents-transactions
NIGHT is the transferable unshielded capital asset; DUST is the non-transferable fee token, so NIGHT is the bridgeable asset.
midnight-ledger · night, dust
A production GRANDPA Wasm light client deployed by governance via 08-wasm — the reference path for a Substrate chain into Cosmos.
ibcprotocol.dev · wasm-client
Honest status + local reproduction
What Works Today
We hold a hard line between what is cryptographically proven, what is partial, and what is scoped next. No overclaiming — the value of this engagement depends on knowing exactly where the line sits.
Proven today
- The Go GRANDPA verifier in the x/midnightbridge keeper is real and wire-correct: per-precommit ed25519 verify over the 53-byte message with a u32 block number, duplicate-vote rejection, target binding, and a (2·total)/3+1 weighted supermajority.
- blake2b-256 header anchoring is enforced on-chain: the justification target hash must equal blake2b-256 of the SCALE-encoded header, and the end-to-end test recomputes and asserts this against the live Midnight node.
- A mint requires a state root previously stored by a GRANDPA-verified client update; with no verified root there is no mint.
- The Substrate Patricia-Merkle-16 trie proof walker is genuine: it decodes the SCALE read proof and re-hashes nodes with blake2b-256 to chain back to the verified state root.
- The IBC stack is real and inherited: ibc-go v8 core, ICS-20 transfer with erc20, rate-limit, fee and packet-forward middleware, 07-tendermint, and 08-wasm backed by a real WasmVM.
- Safety controls are present in the keeper: txHash replay protection, proof-staleness and strictly-increasing-height checks, and an equivocation freeze on conflicting state roots are part of the committed bridge; deposit-commitment value binding, per-transaction and per-epoch mint caps, a circuit breaker, a denom whitelist and a default-deny relayer whitelist were added in the current working tree.
- The repo ships a pre-compiled Compact bridge contract with real per-circuit ZK prover and verifier artifacts, plus a lock script that — run against a local Midnight node and proof server — calls lock_funds to generate a real ZK proof. The Compact source is not included and the demo's validation witnesses are stubbed.
Current limitations
- The bridge demo runs against a single-validator Midnight dev node with a mocked Cardano follower, so 2/3+ of validators is effectively 2/3 of one — real finality, but not mainnet consensus.
- As committed at HEAD the mint binds neither amount nor sender to an on-chain lock: ConfirmDeposit tries the bridge key then a system-events key (key existence only, no value check), and because the e2e proof is for a fixed system key it falls through to a structural trie-integrity check that only proves the proof hashes to the verified state root — the test passes an arbitrary amount and sender.
- The canonical Midnight validator set is not pinned by default genesis, and a dev-mode fallback can bootstrap the authority set from the justification's own signers (trust-on-first-use) whenever no set is pinned — reachable in the default and e2e configurations.
- The relayer hardcodes account and sequence numbers and anchors every state proof on a fixed well-known storage key rather than the specific deposit key, though it does scan and relay real unshielded bridge-pallet events.
- The Rust 08-wasm contract is non-conformant to the ibc-go 08-wasm ABI and lacks migrate, upgrade and metadata handlers; the deploy script compiles the contract but its on-chain store and instantiate steps are commented out, and the channel-setup script is a placeholder — so no client is stored and no channel is opened.
- A separate IBC packet path (the bridge module's OnRecvPacket) can mint from a JSON packet with no GRANDPA or trie verification — a trusted-relayer side door that must be removed or gated so every mint goes through the verified ConfirmDeposit path.
- The privacy gateway does not yet verify ZK proofs — it checks a boolean — and nullifier dedup is deferred.
- The bridge currently wraps DUST; per the Midnight ledger the transferable asset is NIGHT (DUST is the non-transferable fee resource), so the bridged-asset model must be corrected.
Scoped next
- A conformant ICS-08 08-wasm GRANDPA light client deployable by governance via MsgStoreCode, checksum allowlist and MsgCreateClient, with MsgMigrateContract upgrades.
- Key-and-value-bound trie membership proofs against a real Midnight bridge pallet so the minted amount, recipient and denom are bound to a proven storage value.
- A pinned GRANDPA authority set with delayed rotation and a real header timestamp for getTimestampAtHeight and ICS-04 timeouts.
- A real ICS-20 channel to a first counterparty plus a hardened, durable relayer that syncs account/sequence and anchors proofs on the bridge key.
- End-to-end validation against a multi-validator Midnight node following a real Cardano main chain, with an operational metrics and alerting dashboard.
- The Cosmos-to-Midnight return path as a 3-of-5 BIP-340 attestor committee, with a documented migration toward trust-minimized CometBFT verification.
- A real privacy gateway with Groth16 verification and nullifier dedup, multi-chain rollout to Osmosis, Celestia and Noble, an independent security review and a public testnet.
We ran the bridge demo on a workstation: a real Midnight node and the Cosmos interop chain, both producing blocks, with the relay server and bridge module active. The dashboard below is the project's own demo app connected to those live local chains.
Cosmos interop chain
localchain_9000-1
CometBFT 0.38.17 · height 48 and advancing · validator power 10
Midnight node
0.22.0-d31d1d5e
block 0x6c (108) and advancing · state root 0xc37dda5b…17dee2
Relay server
active
midnight1k8ezt0pf0ugyc7j9p2q3y4dmnjt58xz2exsddu
Two fixed milestones · $40,000 + $30,000
Breakdown of Work
The work is split into two milestones. Each is a fixed price and a shippable, demoable outcome: M1 makes the proven one-way path production-trustless and IBC-native; M2 makes the bridge bidirectional and rolls it out across the ecosystem.
Harden the Trustless One-Way Deposit Path into an IBC-Native Light Client
Weeks 1–7
ObjectiveTake the deposit path that verifies real GRANDPA finality on-chain today and turn it into a production-grade, governance-deployable IBC 08-wasm light client with key-and-value-bound state proofs — removing every dev-only shortcut so a mint is provably gated on a specific Midnight deposit record rather than test constants. End state: a real ICS-20 channel to a first counterparty carrying midnight wrapped assets, a hardened relayer, and full observability, validated end-to-end against a real Midnight node.
Work order items
Port the GRANDPA verifier into a conformant ICS-08 08-wasm light client
Repackage the already-real Go GRANDPA verification logic into a Rust 08-wasm contract whose sudo and query messages match the ibc-go v8 ABI exactly: client_message as Binary, Height with revision number and height, MerklePath with key_path, and the delay periods. Add the missing migrate, VerifyUpgradeAndUpdateState, CheckSubstituteAndUpdateState and ExportMetadata handlers.
Deliverable. A WasmVM-loadable client the stock ibc-go 08-wasm keeper can drive through createClient, updateState, verifyMembership and misbehaviour, with a passing ABI conformance suite.
Replace key-existence proofs with key-and-value-bound membership
Verify the actual bridge-transfer storage value (receiver, amount, denom) and bind the minted amount, recipient and denom to the proven storage value, against a Midnight runtime that carries the bridge pallet. Remove the structural-integrity fallback.
Deliverable. ConfirmDeposit that mints only the exact amount and recipient committed in a GRANDPA-verified storage value, with negative tests proving an arbitrary or unbound amount is rejected.
Pin the GRANDPA authority set, ship governance deploy and rotation
Remove the trust-on-first-use bootstrap and pin Midnight's canonical authority set at genesis or via governance. Implement delayed authority-set rotation from ScheduledChange digests, wire a real header timestamp, and execute the MsgStoreCode proposal, checksum allowlist and MsgCreateClient.
Deliverable. A governance-deployed, checksum-allowlisted Midnight 08-wasm client instantiated on-chain with a pinned validator set and working rotation.
Open an ICS-20 channel and route wrapped assets
Stand up a Hermes or Hyperspace relayer, run a real connection and ics20-1 channel handshake against a first counterparty, and route the minted wrapped token through the existing transfer and packet-forward stack with refund-on-timeout.
Deliverable. An open, named ICS-20 channel and a test that transfers a wrapped Midnight asset to the counterparty and back with correct escrow and timeout behavior.
Harden the relayer into a reliable IBC messenger
Anchor state proofs on the real bridge storage slot, sync account and sequence numbers from chain, populate the authority set id and sender, wire the real proof path, add submit retries and inclusion waits, and persist last-relayed state.
Deliverable. A relayer that submits messages both chains accept, recovers from restarts without replay gaps, and passes a soak test against a live node.
End-to-end validation against a real node plus observability
Run the full deposit path against a multi-validator Midnight node following a real Cardano main chain, drop the dev mocks, and ship a metrics and alerting dashboard covering client height, proof verification, mint volume, caps and freezes.
Deliverable. A green end-to-end suite against a non-dev Midnight node plus a live operational dashboard with alert rules for client staleness and circuit-breaker trips.
Bidirectional Bridge, Privacy Gateway and Multi-Chain Rollout
Weeks 8–13
ObjectiveBuild the Cosmos-to-Midnight return path, preserve Midnight's privacy across the boundary, roll the bridge out to the broader IBC ecosystem, and validate the whole system under independent security review on a public testnet. The return path starts as an attestor committee with a defined migration toward a trust-minimized light-client or ZK design.
Work order items
Ship the Cosmos-to-Midnight return path as a threshold attestor committee
Implement the 3-of-5 BIP-340 Schnorr attestor committee. Each attestor runs a Cosmos full node, observes the finalized burn event, and signs (receiver, amount, cosmos_tx_hash, height). Midnight verifies the threshold via native signature checks and an m-of-n maintenance authority with a nonce counter for replay protection, then re-shields.
Deliverable. A working withdrawal: burn the wrapped asset on Cosmos, collect 3-of-5 attestations, and credit the unlocked asset on Midnight, with replay and offline-attestor tests.
Define and prototype the trust-minimized return-path migration
Because the Compact ZK VM cannot verify CometBFT in-circuit, document and prototype the migration toward real Tendermint verification: either a Substrate 07-tendermint pallet with real ed25519 and IAVL verification or a ZK attestation light client.
Deliverable. An architecture decision record plus a prototype that performs real CometBFT commit-signature and IAVL proof verification.
Build the privacy gateway for shielded transfers
Replace the stub with real Groth16 proof verification and nullifier dedup. Ensure value unshields only at the boundary on deposit and re-shields on return, and correct the asset model so the bridgeable capital asset is NIGHT.
Deliverable. A privacy gateway that verifies real ZK proofs, enforces replay protection, and demonstrates a shielded-to-shielded round trip that never exposes amounts off-boundary.
Multi-chain rollout to Osmosis, Celestia and Noble
Open governance-gated ICS-20 channels and run relayers to three additional ecosystems, register denom traces and packet-forward routes, and configure per-channel rate limits and escrow monitoring.
Deliverable. Live channels to at least three additional ecosystems with verified transfers, denom-trace registration and per-channel rate limits.
Independent security review and remediation
Commission an independent review of the GRANDPA light client, trie-proof verifier, attestor threshold and replay logic, and IBC middleware composition. Triage, remediate criticals and highs, and re-test, including economic and liveness analysis of the attestor model.
Deliverable. A published review report, a remediation log closing all critical and high findings, and a regression suite for each fix.
Public testnet launch and operations runbook
Deploy the full bidirectional bridge to a public testnet with the governance-deployed light client, attestor committee, privacy gateway and multi-chain channels, and publish an operations runbook covering key management, rotation and incident response.
Deliverable. A live public testnet bridge with a documented operations runbook and a monitored attestor and relayer fleet.
Sequencing across ~13 weeks
Delivery Roadmap
Fixed price · USD
Investment
| Milestone | Price |
|---|---|
| M1Harden one-way deposit into IBC-native light client | $40,000 |
| M2Bidirectional, privacy gateway and multi-chain rollout | $30,000 |
| Total | $70,000 USD |
Fixed price per milestone
M1 is $40,000, M2 is $30,000. Scope per milestone is locked at kickoff; changes are handled as a short written addendum.
Milestone-based billing
M1 is invoiced at kickoff to begin; M2 is invoiced on acceptance of M1. Each milestone ends in a demoable outcome.
Full IP ownership
All code and deliverables transfer to the client on payment of each milestone.
What we rely on, what's excluded
Assumptions & Scope
Assumptions
- Midnight exposes a real bridge pallet that records deposits as queryable, GRANDPA-verifiable storage values; M1 value-binding depends on the final on-chain storage layout.
- A non-dev, multi-validator Midnight network following a real Cardano main chain is available for M1 end-to-end validation; otherwise validation runs against the best available staging network.
- The Cosmos interop chain remains on ibc-go v8 with 08-wasm, transfer, packet-forward and rate-limit wired in; counterparty chains run compatible ibc-go versions.
- Governance access is available to pass MsgStoreCode, allowlist the client checksum, instantiate via MsgCreateClient and later MsgMigrateContract.
- Midnight's runtime supports the threshold signature and m-of-n maintenance-authority semantics the M2 return path relies on.
- The bridgeable capital asset is NIGHT, not the non-transferable DUST fee token; wrapped denoms and supply invariants are modeled on NIGHT.
- Client provides Midnight and Cosmos testnet endpoints, funded relayer signing keys, and the runtime metadata needed for SCALE storage-key derivation.
Out of scope
- Mainnet launch, custody of real user funds, and any token-economic or liquidity provisioning for wrapped assets.
- Changes to Midnight's core consensus, ledger or Compact toolchain beyond the bridge pallet and integration points.
- A fully in-circuit ZK verification of CometBFT on Midnight, which the specs establish as currently infeasible; M2 delivers the attestor committee plus a migration prototype only.
- Formal verification or audit certification beyond the single independent security review scoped in M2.
- Consumer wallet or end-user UX beyond the operational monitoring dashboard.
- Indexer, explorer or analytics infrastructure beyond the operations dashboard.
- Legal, regulatory and compliance review of cross-chain asset transfers.
Next Steps
From here to a production-bound bridge, in three steps.
Review this scope
Confirm the engineering plan and milestone breakdown, and flag anything to add, cut or re-sequence.
Sign the letter of engagement
Sent on your confirmation — covers the fixed price, milestone terms and IP ownership.
Kick off Milestone 1
We confirm node and governance access, pin the authority set, and begin the 08-wasm light client.
Direct contact: utkarsh@webisoft.com
Webisoft · Montreal, QC · webisoft.com
Confidential — Midnight ↔ Cosmos Bridge Scope of Work