HIP-1342: Ignore Trailing Calldata for System Contracts - #1342
Conversation
|
Thank you @Neurone. I believe this will satisfy Squid's (and others) needs, and make our EVM more compatible with others |
|
adding self for tracking - @lukelee-sl |
|
I think this would be a great addition to bring HTS system contracts into being more EVM compliant. |
Ferparishuertas
left a comment
There was a problem hiding this comment.
Please add @gkozyryatskyy instea Luke
thanks
gkozyryatskyy
left a comment
There was a problem hiding this comment.
After discussion within the SC team we are proposing next updates:
- Apply
Trailing Calldatato otherSystem Contractsto ensure full, non-surprising EVM consistency across all precompiles/system contracts. - Remove from HIP
Mitigations:paragraph. - Propose Show trailing data on [HashScan](https://hashscan.io/testnet/home)
c3ea421 to
99f352e
Compare
gkozyryatskyy
left a comment
There was a problem hiding this comment.
LGTM! Thank you @Neurone !
99f352e to
cf347aa
Compare
|
This HIP appears to have been inactive for 60 days. If there is no activity or response within 14 days, it will be marked as Stagnant and closed. To prevent automatic closure, simply add a comment with an update, make a commit, or react to this message. Maintainers can also add a 'keep-open' label to exempt this HIP. |
Signed-off-by: Michael Garber <michael.garber@hashgraph.com>
ad018a4 to
a08aa72
Compare
Up to standards ✅🟢 Issues
|
This PR introduces a proposal for the HIP Ignore Trailing Calldata for System Contracts.
This HIP proposes enabling system contract to accept and ignore trailing calldata beyond the ABI-defined parameters of a function. This restores EVM-parity behavior where contracts typically ignore additional bytes in calldata, allowing applications to append small "memo" or order identifiers to standard ERC-20-like calls (e.g.,
transfer,approve) without causing transaction failure. The change is implemented by updating the parameter decoding used by system contract so that decoding succeeds when extra bytes remain after all expected parameters are parsed. The extra bytes are ignored by the system contract and preserved in the underlying Ethereum transaction/record for off-chain consumption.