Assessment reports>Mina Token Bridge>High findings>No domain separation for validator signatures
Category: Coding Mistakes

No domain separation for validator signatures

High Severity
Low Impact
Low Likelihood

Description

In both directions of the bridge, validator signatures are needed to unlock funds. On the Mina side, the message signed by the validator consists of the receiver address (two field elements), the amount (one field element), and the token address (two field elements):

  @method async unlock(
    amount: UInt64,
    receiver: PublicKey,
    id: UInt64,
    tokenAddr: PublicKey,
    useSig1: Bool,
    validator1: PublicKey,
    sig1: Signature,
    useSig2: Bool,
    validator2: PublicKey,
    sig2: Signature,
    useSig3: Bool,
    validator3: PublicKey,
    sig3: Signature,
  ) {
    // ...

    const msg = [
      ...receiver.toFields(),
      ...amount.toFields(),
      ...tokenAddr.toFields(),
    ]

    // ...

    this.validateSig(msg, sig1, validator1, useSig1);
    this.validateSig(msg, sig2, validator2, useSig2);
    this.validateSig(msg, sig3, validator3, useSig3);

    // ...
}

  public async validateSig(msg: Field[], signature: Signature, validator: PublicKey, useSig: Bool) {
    let isValidSig = signature.verify(validator, msg);
    const isValid = Provable.if(useSig, isValidSig, Bool(true));
    isValid.assertTrue("Invalid signature");
  }

This message has no domain separation.

Impact

The risk with no domain separation is that validators may produce signatures that are not intended for the bridge contract but can nevertheless be used there.

Concretely, another contract on Mina may exist, also not using any domain separation, which also asks for signatures of messages consisting of five field elements. If validators use the same key to sign messages for both contracts, it may happen that the same signed message is usable for both contracts. In this case, a validator may sign a message intended for the other contract that can also be used for the bridge contract.

Note that on the Ethereum side, proper domain separation is used, following the EIP-712 standard.

Recommendations

We recommend prefixing the signed message by a field element used for domain separation. For example, such a field element could be obtained from a string such as "MinaBridge" as well as possibly the chain ID and the address of the bridge contract.

Remediation

Sotatek acknowledged the finding and provided the following comment:

Mina Bridge is currently operating centrally. The owner is responsible for managing minters, senders, and admins. Therefore, the impact of this issue cannot be externally affected, unless the owner discloses the information. Beside it, we need to fix both the SC and BE, and we need to go to production soon, we will temporarily not fix it.

Zellic © 2025Back to top ↑