unionlabs/union · error

not implemented

Error message

not implemented

What it means

The Movement 08-wasm light client implements the union IBC client trait, but verify_non_membership is left as unimplemented!(). The trait requires the method, so any submitted proof-of-absence against a Movement client traps with "not implemented" inside the cosmwasm contract, reverting that message.

Source

Thrown at cosmwasm/lightclient/movement/src/client.rs:71

        // let consensus_state = ctx.read_self_consensus_state(height)?;
        // verify_membership(
        //     &key,
        //     consensus_state.state_root,
        //     client_state.table_handle,
        //     storage_proof,
        //     &value,
        // )
        // .map_err(Into::into)
        Ok(())
    }

    fn verify_non_membership(
        _ctx: IbcClientCtx<Self>,
        _height: u64,
        _key: Vec<u8>,
        _storage_proof: Self::StorageProof,
    ) -> Result<(), IbcClientError<Self>> {
        unimplemented!()
    }

    fn get_timestamp(consensus_state: &Self::ConsensusState) -> Timestamp {
        consensus_state.timestamp
    }

    fn get_latest_height(client_state: &Self::ClientState) -> u64 {
        client_state.latest_block_num
    }

    fn get_counterparty_chain_id(client_state: &Self::ClientState) -> String {
        client_state.chain_id.clone()
    }

    fn status(ctx: IbcClientCtx<Self>, client_state: &Self::ClientState) -> Status {
        let _ = ctx;

        if client_state.frozen_height.height() != 0 {

View on GitHub (pinned to 031785bb6d)

Solutions

  1. Do not submit non-membership proofs for Movement clients — configure the relayer to skip absence-proof flows for this client type
  2. Upgrade the deployed movement light-client wasm once an implementation lands (SMT/Move-state absence proof)
  3. If you need it now, implement verify_non_membership in the contract and redeploy
  4. Check the union IBC spec version the deployed contract targets to confirm the method is expected to be supported
Defensive patterns

Strategy: validation

Validate before calling

// Relayer-side gate before submitting proofs
const NO_NON_MEMBERSHIP = new Set(["movement", "state-lens-ics23-smt", "sui"])
export function canSubmitNonMembershipProof(clientType: string): boolean {
  return !NO_NON_MEMBERSHIP.has(clientType)
}
// usage:
if (!canSubmitNonMembershipProof(counterpartyClientType)) {
  throw new Error(`${counterpartyClientType} does not implement verify_non_membership`)
}

Type guard

const supportsNonMembership = (clientType: string) =>
  !new Set(["movement", "state-lens-ics23-smt", "sui"]).has(clientType)

Prevention

When it happens

Trigger: A relayer submits a non-membership proof (proof that a counterparty key/value is absent — used in some channel/client handshake error paths and absence-based flows) to a union light client of the Movement type. The wasm host calls the stub and the panic aborts execution.

Common situations: Relayer configurations or flows written for client types that do support absence proofs reused against Movement clients; newer relayer versions emitting non-membership messages; test suites exercising the full trait surface.

Related errors

AI-assisted analysis of unionlabs/union@031785bb6d (2026-08-16). Data as JSON: /api/errors/90d053a955d00f92. Report an issue: GitHub.