Summary
The Ethereum bridge README currently documents the mint/withdraw messageHash format without the address(this) bridge contract field, while the actual contract source includes it.
A fix already exists on branch:
https://github.com/gonka-ai/gonka/tree/gl/eth-readme-quickfix
This ticket tracks merging that fix into the v0.2.14 line.
Current discrepancy
README currently documents mint as:
epochId,
GONKA_CHAIN_ID,
requestId,
ETHEREUM_CHAIN_ID,
MINT_OPERATION,
recipient,
amount
But the contract source uses:
epochId,
GONKA_CHAIN_ID,
requestId,
ETHEREUM_CHAIN_ID,
MINT_OPERATION,
recipient,
address(this),
amount
The same applies to withdraw, where address(this) is also part of the signed payload.
Impact
The chain-side implementation already matches the contract source, so this is not a production-safety issue.
However, third-party auditors or integrators using the README could construct an invalid message hash, causing signature verification failures.
Acceptance criteria
- README mint
messageHash includes address(this).
- README withdraw
messageHash includes address(this).
- Documentation matches
BridgeContract.sol.
- Fix is merged into v0.2.14.
Summary
The Ethereum bridge README currently documents the mint/withdraw
messageHashformat without theaddress(this)bridge contract field, while the actual contract source includes it.A fix already exists on branch:
https://github.com/gonka-ai/gonka/tree/gl/eth-readme-quickfix
This ticket tracks merging that fix into the v0.2.14 line.
Current discrepancy
README currently documents mint as:
But the contract source uses:
The same applies to
withdraw, whereaddress(this)is also part of the signed payload.Impact
The chain-side implementation already matches the contract source, so this is not a production-safety issue.
However, third-party auditors or integrators using the README could construct an invalid message hash, causing signature verification failures.
Acceptance criteria
messageHashincludesaddress(this).messageHashincludesaddress(this).BridgeContract.sol.