mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
VerifyAgainst refuses a signature made by a key it was not told to expect, and a test proves it. Nothing proved the CALLER passes the right key. Handing it att.GroupPubKey instead of vm.mpcGroupPublicKey() -- the exact pre-fix shape, the one that let a self-consistent forgery through -- left the whole bridgevm suite green, because no test had ever entered releaseTransfer. Nothing could. releaseTransfer routes through evmByChainID, typed to *evmChainClient, and that type dials RPC endpoints in its constructor. The package already declares ChainClient and already asserts evmChainClient satisfies it; the sibling map chainClients is already typed to it. Only the id-keyed index reached past the interface to the implementation. Widening it and moving IsProcessed onto the contract leaves every object and every call unchanged and lets the funds path be given a double. Three refusals now hold: an attestation signed by a key it supplied itself, a genuine attestation on a chain whose custody keygen has not completed, and no attestation at all. Each asserts that the destination gateway received zero broadcasts, because broadcasting is the release. An already-processed transfer is the positive control, proving the rig reaches the gateway and the refusals are decided where they claim to be. Co-authored-by: Hanzo Dev <[email protected]>