Account allowances - #1671
Merged
Merged
Account allowances#1671
Conversation
F-OBrien
force-pushed
the
account-allowances
branch
from
September 7, 2026 19:15
da7a27b to
0cf2cdd
Compare
prashantasdeveloper
previously approved these changes
Sep 8, 2026
`account.getAllowances()` returns every allowance the Account has
approved — the spender, the Asset, and what may be transferred.
`fungibleAsset.getAllowances({ owner })` narrows that to one Asset. Only
a single allowance could be read before, and only where the spender was
already known, which it usually is not.
`unlimited` marks an allowance of `Balance::MAX`, which the chain never
deducts from on spend. Without it a caller has 3.4e32 POLYX to render.
Allowances are keyed by owner, spender and Asset in that order, so the
Account-level read is one prefix scan and pages the chain honestly. The
Asset-level one can only filter after reading, so it returns the whole
set rather than short pages behind a cursor still claiming more.
Revoking an allowance removes its entry, so no zero filtering is needed
and every result is live.
`ApproveAllowanceParams.amount` documented `Balance::MAX = unlimited` and the chain honours it, but the value never reached the chain: it was converted as a balance, which is capped at `MAX_BALANCE`. `amount` and `unlimited` are now both optional and exactly one must be passed. `bigNumberToU128` was part of the same failure. It stringified with `toString`, which switches to exponential notation from 1e21 and the codec rejects — so no caller could pass a `u128` above that, not only this one. It now spells the digits out.
F-OBrien
force-pushed
the
account-allowances
branch
from
September 8, 2026 14:49
0cf2cdd to
4557ae9
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
prashantasdeveloper
previously approved these changes
Sep 8, 2026
polymesh-bot
dismissed
prashantasdeveloper’s stale review
September 8, 2026 15:15
The base branch was changed.
prashantasdeveloper
approved these changes
Sep 8, 2026
Contributor
Author
|
/fast-forward |
Collaborator
|
🎉 This PR is included in version 31.1.0-beta.12 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
3 participants
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.
Description
Two commits.
1. List the Asset allowances an Account has approved
Only a single allowance could be read before, and only where the spender was already known — which for "what have I approved, and to whom" it is not.
Only the Account-level read pages: allowances are keyed
(owner, spender, assetId), so an owner prefix scan is exact, while the Asset-level read can only filter after the scan and would otherwise return short pages behind a cursor still claiming more.No zero filtering —
approve(…, 0)and a spend that drains an allowance both callAllowances::remove, so every result is live.2. Allow an unlimited allowance to be set
ApproveAllowanceParams.amountdocumentedBalance::MAX = unlimitedand the chain honours it, but the value was rejected before it reached the chain — it was converted as a balance, which is capped atMAX_BALANCE.amountandunlimitedare now both optional, and exactly one must be passed.That surfaced a pre-existing bug in
bigNumberToU128: it stringified withtoString, which switches to exponential notation from 1e21, and the codec rejects that — so no caller could pass au128above 1e21, not only this one. Now usestoFixed().bigNumberToBalanceis hardened the same way; it is safe today only becauseMAX_BALANCEkeeps values three orders below the threshold.Verification
yarn build:ts,yarn lintandyarn test(209 suites / 2738 tests) pass, with 100% coverage on the touched files.api-snapshot:comparereports no breaking changes — run locally, because an earlier discriminated-union form ofApproveAllowanceParamswas flagged as breaking (interface→typereads as removal).Exercised against a local dev chain, since testnet has one allowance entry and mainnet none:
size: 10Balance::MAXunlimited: trueThe
u128bug was only found this way — the unit test mocksbigNumberToU128, so it encoded the same assumption as the code.Follow-up, not in this PR
fungibleAsset.getAllowance()returns a bareBigNumberwith nounlimited, so it disagrees with the new type. Changing it is a return-type break;getAllowances({ owner })already carries the flag in the meantime.Breaking Changes
None.
JIRA Link
Checklist