Ninguna firma hecha desde una wallet siguiendo este README podia funcionar.

prepare_relayed_feedback() devuelve un digest que YA lleva el sobre EIP-191 --
el facilitador recupera contra el como prehash, sin agregar nada. Este README y
estos docstrings decian sign_message(prep.digest), y sign_message ES
personal_sign: aplica el sobre otra vez, envuelve el valor DOS VECES y recupera
una direccion que no es la de quien califica.

El fallo es silencioso por construccion: la firma es valida, el request es
valido, y el facilitador contesta relay_bad_signature -- que se lee como si
hubiera firmado el contenido equivocado, no como si el cliente lo hubiera
envuelto de mas.

Lo encontro Karma Kadabra leyendo el codigo antes de emitir nada. Las tres
superficies de Execution Market tenian el mismo bug, y este SDK tambien.

AGREGA signing_payload

El campo nuevo de PrepareRelayFeedbackResponse (facilitador v1.95.0+): el mismo
hash sin el sobre, que es lo que firma una wallet.

  llave cruda           -> firmar `digest` como prehash
  wallet personal_sign  -> firmar `signing_payload`
  personal_sign(digest) -> recupera a un desconocido

keccak256(prefijo + signing_payload) == digest, asi que el cliente puede
chequear uno contra el otro en vez de reconstruir el preimage desde `data`.

Contra un facilitador viejo el campo llega ausente. Hay un test que lo fija: no
debe caer de vuelta a `digest`, porque seria darle a la wallet justo el valor
que no puede firmar.

Quien firma con llave propia nunca estuvo afectado y no tiene que cambiar nada.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>