Skip to content

docs: fix transferFrom() spending limits inconsistency (TMPO2-39) #93

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gakonst wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: fix transferFrom() spending limits inconsistency (TMPO2-39) #93

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions src/pages/protocol/transactions/AccountKeychain.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -273,8 +273,9 @@ Access Keys cannot escalate their own privileges because:
- Keys with `enforceLimits == false` have unlimited spending (no limits checked)
- Spending limits are enforced by the protocol internally calling `verify_and_update_spending()` during execution
- Limits are per-TIP20 token and deplete as TIP20 tokens are spent
- Spending limits only track TIP20 token transfers (via `transfer` and `transferWithMemo`) and approvals (via `approve`)
- For approvals: only increases in approval amount count against the spending limit. This means approvals indirectly control `transferFrom` spending, since `transferFrom` requires a prior approval
- Spending limits only track TIP20 `transfer()`, `transferWithMemo()`, `approve()`, and `startReward()` calls
- `transferFrom()` is NOT subject to spending limits (it is gated only by the ERC-20 allowance mechanism)
- For approvals: only increases in approval amount count against the spending limit
- Non-TIP20 asset movements (ETH, NFTs) are not subject to spending limits
- Root keys (`keyId == address(0)`) have no spending limits - the function returns immediately
- Failed limit checks revert the entire transaction with `SpendingLimitExceeded`
Expand Down