RewardAccount: validate header type bits and bech32 prefix
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- api
Research direction
Start in packages/evolution/src/RewardAccount.ts at FromBech32 and FromBytes, then compare the existing checks in Address.FromBech32 and the related changes from #391. Add coverage for rejecting non-reward headers and non-stake prefixes while preserving valid stake and stake_test round trips; done means these cases parse or fail as specified.
Written by the indexing model from the issue text.
Description
Summary
RewardAccount parsing is looser than Address parsing for the same class of input. RewardAccount.FromBech32 does not check the bech32 human-readable prefix, and RewardAccount.FromBytes does not validate the CIP-19 header type nibble. As a result, a non-stake prefix and a non-reward header type can still parse into a RewardAccount. This is the RewardAccount-side counterpart to #391, which added the equivalent checks on Address / EnterpriseAddress / BaseAddress.
Affected
- packages/evolution/src/RewardAccount.ts — FromBech32 (prefix not checked)
- packages/evolution/src/RewardAccount.ts — FromBytes (header type nibble not validated)
Fix
FromBytes: require the header type to be a reward type (14/15); reject others.FromBech32: require the prefix to bestake/stake_testand to agree with the header networkId.
Mirror the checks already present in Address.FromBech32.
Test
Add coverage asserting that a non-reward header and a non-stake prefix both fail to parse as a RewardAccount, and that valid stake / stake_test inputs still round-trip.
- Dominant language
- TypeScript
- Stars
- 22
- Forks
- 31
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 27
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from IntersectMBO/evolution-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
IntersectMBO/evolution-sdk#579 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
IntersectMBO/evolution-sdk#559 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
IntersectMBO/evolution-sdk#557 ·
Maintainers usually reply within 1 day
-
dependencies good first issue
Difficulty 1/5 Under an hour Newbie friendliness 93/100
IntersectMBO/evolution-sdk#541 ·
Maintainers usually reply within 1 day
-
bug external-review
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
IntersectMBO/evolution-sdk#530 ·
Maintainers usually reply within 1 day
All issues in IntersectMBO/evolution-sdk
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
betagouv/mon-entreprise#4699 ·
Maintainers usually reply within 3 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
jaegertracing/jaeger-ui#4547 · 3 comments ·
Maintainers usually reply within 1 day
-
ai-driven-qa
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
linagora/twake-calendar-frontend#1467 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
need4deed-org/sdk#267 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
auth0/universal-login#414 ·
Maintainers usually reply within 1 day