Repository navigation
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #456.
RewardAccountparsing was looser thanAddressparsing for the same class of input:FromBytesaccepted any CIP-19 header type whose low bit matched, so a 29-byte enterprise address (type 6, header0x61…) or a pointer address (type 4) parsed successfully as a reward account, andFromBech32never checked the human-readable prefix, so anaddr…/addr_test…string — or astake…string whose prefix disagreed with the header's network id — decoded as aRewardAccount. This is theRewardAccount-side counterpart to #391, which added the equivalent checks onAddress.Fix
In
packages/evolution/src/RewardAccount.ts, mirroring the checks already present inAddress:FromBytes: the header type nibble must be a reward type —14(stake key) or15(script) — anything else fails withInvalid reward address type: <type>. This also coversFromHex, which composes overFromBytes.FromBech32: the decoded prefix is now retained and must bestake/stake_test(Invalid reward account prefix: <prefix>otherwise), and it must agree with the network id decoded from the header (Prefix <prefix> does not match network <id>), exactly asAddress.FromBech32does.No encoder changes: encoding already writes header types 14/15 and the
stake/stake_testprefix from the network id.Tests
New file
packages/evolution/test/RewardAccount.HeaderValidation.test.ts(6 tests), each rejection verified failing onmainfirst (run one at a time, since this repo's vitest bails a file after the first failure):0x61…), pointer (0x41…) and base (0x01…) headers rejected from hex, with the type named in the error;addrandaddr_testprefixes rejected from bech32;stakeand a mainnet payload understake_testboth rejected for prefix/network mismatch;stake/stake_testround-trips for a key credential (headers0xe1/0xe0), and a script-credential account (type 15, header0xf1) round-tripping through hex and bech32.Full package suite: 1684 passed / 75 skipped / 0 failed, test files 102 passed / 1 skipped of 103 — exactly main's 1678 baseline + the 6 new tests.
tsc --noEmitandeslintclean; both touched files are prettier-clean (the source file is prettier-clean onmaintoo). A patch changeset is included.Independent builder — not affiliated with the Cardano Foundation, IOG or Intersect.
@Kshot9000 (https://x.com/kshot9000) · ADA: addr1q8hnl6vl5a6k3rw3n5g3jtte696zcl76kfatzv7gpswa9r0dj7fma6klq55y4ffm7tf0em09udnyhuk4ah92pl5x9jpqjae44v
cc @cardano-foundation @IntersectMBO