Amendment Idea: Spending Limits

[BraedonKlock]

Spending Limits

Update (November 1, 2026): I've updated the proposal based on feedback and further discussions with @dangell7

Names, fields, and rules are tentative. Anything marked Open is undecided, and feedback on those points is especially welcome. See Section 9: Open Questions.

1. Abstract

Spending Limits let an account owner control how a specific asset can be spent, by which transaction type, and by whom. A limit can restrict:

• the maximum amount of the asset per transaction,
• the maximum number of successful transactions, and
• the minimum time between successful transactions.

Limits are configured per asset and per transaction type. They apply to either the owner's own transactions (account-level) or to one delegate's transactions (delegate-specific). Only the limits belonging to whoever submits the transaction are enforced.

To stop limits from being bypassed through a different transaction type, once a scope has any limit, asset-moving transactions without their own limit for each asset they spend are rejected. Owners must explicitly configure every transaction type they want to allow.

A new SpendingLimitSet transaction manages limits, and each limit is stored in its own SpendingLimit ledger entry.

2. Motivation

My main motivation is autonomous agents, particularly AI agents.

An AI agent doesn't have to be compromised to make a mistake. It can hallucinate, misunderstand an instruction, or be confident in a decision that is wrong.

Today, if an owner gives an agent permission to submit payments through Permission Delegation, there's no way to restrict:

• how much of an asset the agent can spend per transaction,
• how many transactions it can submit, or
• how frequently it can submit them.

Any such limits have to live in the agent's own application logic, which is exactly the component we're trying to guard against. This proposal moves those limits into the protocol, where the agent can't skip them.

Agents also need to do more than send payments. An agent might pay invoices, trade on the DEX, and lock funds in escrow, and the owner will want different limits for each. A single limit per asset can't express that, so limits are configured per transaction type.

The feature is also useful without delegation, for example when an agent operates an account with the account's own keys and the owner wants a safety net against mistakes.

3. Specification

All names, field types, and values in this section are tentative.

3.1. Concepts

3.1.1. Scopes

Scope	Applies when	Configured with
Account-level	The owner submits a transaction directly	SpendingLimitSet without Delegate field
Delegate-specific	A specific delegate submits a transaction on the owner's behalf	SpendingLimitSet with Delegate field

Only the submitter's limits are enforced:

• Account-level limits don't apply to delegated transactions.
• Delegate-specific limits don't apply to the owner's direct transactions.
• One delegate's limits and usage never affect another delegate's.

This lets an owner restrict delegates without restricting themselves, and give each delegate different limits.

3.1.2. Limit identity

A limit is indexed by:

Scope	Key components
Account-level	Owner + Transaction type + Asset
Delegate-specific	Owner + Delegate + Transaction type + Asset

So Alice + Bob + Payment + XRP and Alice + Bob + EscrowCreate + XRP are two separate limits, each with its own restrictions and usage.

3.1.3. Restrictions

Each limit may specify any combination of:

Restriction	Meaning	Example
Maximum amount per transaction	Largest amount of the asset a single transaction may spend	1,000 XRP
Maximum successful transactions	Number of successful transactions allowed under this limit	5
Minimum interval	Minimum time between two successful transactions under this limit	24 hours

• Each limit has its own usage state: the number of successful transactions and the time of the last one.
• Usage state is updated only when a transaction succeeds, atomically with its other effects.
• As currently proposed, the transaction count is a lifetime cap. Once reached, further transactions under that limit are rejected until the owner modifies or removes it.

3.2. Enforcement

When a transaction is submitted:

1. Determine the submitter: the owner directly, or a delegate on the owner's behalf.
2. Delegated transactions: run the existing Permission Delegation checks first. If the delegate doesn't have permission, the transaction fails exactly as it does today, and limits are never consulted.
3. Identify what is spent: the transaction type determines which asset(s) it spends and how much (see Section 3.4).
4. For each spent asset, look up the submitter's limit for this transaction type and asset by its key:
   • A limit exists: check every restriction it specifies. If any is violated, the transaction is rejected.
   • No limit exists, and the submitter's scope has no limits at all: the transaction is processed normally, without restriction.
   • No limit exists, but the submitter's scope has at least one limit (for any asset or transaction type): the transaction is rejected (see Section 3.3).
5. On success, update the usage state of every limit that was checked.

Transaction types that don't spend an asset (for example AccountSet, SignerListSet, or SpendingLimitSet itself) are never affected by limits.

3.3. Preventing Bypass: Deny by Default

The problem: if Alice gives Bob both Payment and OfferCreate permissions but limits only his XRP payments, Bob could move XRP through an offer instead. The payment limit works, but it doesn't give Alice the protection she expects.

The rule: once a scope (the owner, or a specific delegate) has at least one limit (for any asset), every asset-moving transaction in that scope must have its own limit for its transaction type and each asset it spends, or it is rejected.

Example: Alice gives Bob Payment, EscrowCreate, and OfferCreate permissions, and configures XRP limits for Bob's Payment and EscrowCreate only.

Bob submits	Limit for Bob + type + asset?	Bob has any other limits?	Result
Payment of 50 XRP	Yes (max 100)	—	✅ Allowed, usage updated
EscrowCreate of 800 XRP	Yes (max 1,000)	—	✅ Allowed, usage updated
OfferCreate spending XRP	No	Yes	❌ Rejected
Payment of 50 RLUSD	No	Yes (XRP limits)	❌ Rejected

The only way to bypass a limit is for the owner to explicitly configure a limit for another transaction type.

3.3.1. Tracking whether a scope has limits

Limits are keyed by transaction type, so a single lookup can't distinguish "no limits anywhere in this scope" from "this transaction type and asset aren't configured, but other limits exist." Checking every possible transaction type and asset would be expensive.

The proposed solution is an active-limit indicator: a counter, maintained by SpendingLimitSet as limits are created and removed, recording how many limits a scope has. Enforcement then needs at most two direct lookups: the indicator and the specific limit.

• The indicator is per scope: limiting any asset locks down all asset-moving transactions in that scope that have no limit of their own. This needs only one indicator per scope, rather than one per scope and asset.
• Open: where the indicator is stored. See Q1.

3.3.2. Allowing a transaction type without restrictions

Under deny-by-default, once a scope has any limit, every transaction type and asset combination without its own limit is rejected. An owner therefore needs a way to allow a combination without limiting it.

The proposed approach is a limit that specifies no restrictions: none of MaxAmount, MaxTransactions, or MinInterval. Such a limit means "this transaction type and asset are explicitly allowed, with no restrictions."

Example: Alice wants to limit Bob's XRP payments to 100 XRP, but let him pay RLUSD freely.

1. Alice creates Bob + Payment + XRP with MaxAmount of 100 XRP.
2. Bob now has a limit, so his RLUSD payments are rejected: there is no Bob + Payment + RLUSD limit.
3. Alice creates Bob + Payment + RLUSD with no restrictions.
4. Bob's RLUSD payments are now allowed without restriction, while his XRP payments remain capped at 100 XRP.

3.4. Measuring Spending

Transaction types don't share a single amount field. Payment uses Amount (and SendMax for cross-currency payments), OfferCreate uses TakerGets and TakerPays, and others have their own fields and logic.

The proposed approach:

• Each supported transaction type determines which asset(s) it spends and how much, the same way each transaction type already has its own doApply() logic.
• It then calls one shared function that looks up, checks, and updates the limits. The validation logic lives in one place.

3.5. Ledger Entry: SpendingLimit

3.5.1. Object Identifier

A SpendingLimit is indexed by:

• Account-level: Owner, LimitedTransactionType, and Asset.
• Delegate-specific: Owner, Delegate, LimitedTransactionType, and Asset.

The two forms must be separated so they can never collide.

3.5.2. Fields

Field Name	Required	Internal Type	Description
Owner	Yes	ACCOUNT	The account whose spending is limited
Delegate	No	ACCOUNT	Present for delegate-specific limits, absent for account-level limits
LimitedTransactionType	Yes	UINT16	The transaction type this limit applies to
Asset	Yes	ISSUE	The limited asset (XRP, issued currency, or MPT)
MaxAmount	No	AMOUNT	Maximum amount per transaction
MaxTransactions	No	UINT32	Maximum number of successful transactions
MinInterval	No	UINT32	Minimum seconds between successful transactions
TransactionCount	Yes	UINT32	Successful transactions used so far
LastTransactionTime	No	UINT32	Time of the last successful transaction
OwnerNode	Yes	UINT64	Page hint in the owner's directory
PreviousTxnID	Yes	HASH256	Previous transaction that modified this entry
PreviousTxnLgrSeq	Yes	UINT32	Ledger sequence of that transaction

A limit with none of MaxAmount, MaxTransactions, or MinInterval means "allowed, unlimited" (Section 3.3.2).

3.5.3. Ownership and Reserves

• Owner: Owner. The entry is placed in the owner's directory.
• Reserve: standard owner reserve, one increment per SpendingLimit.

The delegate does not own the entry and pays no reserve.

3.5.4. Deletion

• Deletion transactions: SpendingLimitSet (removal operation).
• Account deletion blocker: No. SpendingLimit entries hold no funds and only restrict the owner's own account, so, like Delegate and DepositPreauth entries, they are deleted along with the owner's account.

3.5.5. Invariants

• TransactionCount never decreases, except through an explicit owner update (if editing resets usage, see Q6).
• If MaxTransactions is present, it is greater than 0, and TransactionCount <= MaxTransactions.
• Owner != Delegate.
• MaxAmount, if present, is positive and denominated in Asset.

3.5.6. Example JSON

{
  "LedgerEntryType": "SpendingLimit",
  "Flags": 0,
  "Owner": "rAlice...",
  "Delegate": "rBob...",
  "LimitedTransactionType": "Payment",
  "Asset": { "currency": "XRP" },
  "MaxAmount": "100000000",
  "MaxTransactions": 5,
  "MinInterval": 86400,
  "TransactionCount": 2,
  "LastTransactionTime": 815097600,
  "OwnerNode": "0000000000000000",
  "PreviousTxnID": "...",
  "PreviousTxnLgrSeq": 12345678
}

3.6. Transaction: SpendingLimitSet

Creates, modifies, or removes a single limit.

3.6.1. Fields

Field Name	Required	JSON Type	Internal Type	Description
TransactionType	Yes	string	UINT16	SpendingLimitSet
Account	Yes	string	ACCOUNT	The owner
Delegate	No	string	ACCOUNT	If present, the limit is delegate-specific for this account. If absent, it is account-level
LimitedTransactionType	Yes	string	UINT16	Transaction type the limit applies to
Asset	Yes	object	ISSUE	Limited asset
MaxAmount	No	string or object	AMOUNT	Maximum amount per transaction
MaxTransactions	No	number	UINT32	Maximum successful transactions
MinInterval	No	number	UINT32	Minimum seconds between successful transactions

The limit's transaction type uses its own field, LimitedTransactionType, because TransactionType identifies the transaction itself (SpendingLimitSet).

Behavior:

• Account (which becomes the limit's Owner), Delegate, LimitedTransactionType, and Asset identify the limit (Section 3.5.1). If it doesn't exist, it is created. If it exists, its restrictions are updated.
• Only that limit changes. Updating Bob + Payment + XRP doesn't touch Bob + EscrowCreate + XRP or any RLUSD limit.
• To configure several limits atomically, submit several SpendingLimitSet transactions in a Batch. This avoids a window where the first limit is active (so deny-by-default applies) but the others don't exist yet.
• Open: how removal is expressed, for example a flag on the transaction. It must be explicit and unambiguous.

SpendingLimitSet is not delegable. Only the owner can manage limits (see Section 8).

3.6.2. Example JSON

Alice configures Bob's XRP limits for Payment and EscrowCreate with two transactions. They can be submitted together in a Batch so both take effect atomically.

{
  "TransactionType": "SpendingLimitSet",
  "Account": "rAlice...",
  "Delegate": "rBob...",
  "LimitedTransactionType": "Payment",
  "Asset": { "currency": "XRP" },
  "MaxAmount": "100000000",
  "MaxTransactions": 5,
  "MinInterval": 86400
}

{
  "TransactionType": "SpendingLimitSet",
  "Account": "rAlice...",
  "Delegate": "rBob...",
  "LimitedTransactionType": "EscrowCreate",
  "Asset": { "currency": "XRP" },
  "MaxAmount": "1000000000"
}

3.7. Interaction with Permission Delegation

Permission Delegation stays responsible for granting and revoking permissions. Limits are managed independently, and DelegateSet and the Delegate ledger entry are unchanged.

• Permission checks come first. A delegate without permission is rejected before limits are consulted.
• Revoking a permission doesn't delete limits. Bob immediately loses the ability to submit the transaction type. His SpendingLimit entries stay until Alice removes them with SpendingLimitSet and recovers her reserve. This avoids deleting potentially thousands of entries in one revocation.
• Re-granting a permission reactivates surviving limits, including their usage. (Open: whether this is the desired behavior. See Q7.)

3.8. Full Example

Alice has two AI agents, Bob and Charlie.

Scope	Transaction type	Asset	Max per tx	Max txs	Interval
Alice (account-level)	Payment	XRP	1,000 XRP	5	24 h
Alice → Bob	Payment	XRP	100 XRP	5	24 h
Alice → Bob	EscrowCreate	XRP	1,000 XRP	—	—
Alice → Bob	Payment	RLUSD	250 RLUSD	10	—
Alice → Charlie	Payment	RLUSD	10,000 RLUSD	—	—

• Bob pays 50 XRP: checked against Bob + Payment + XRP. He has 4 payments left. His EscrowCreate and RLUSD limits are unchanged.
• Bob pays 50 XRP again an hour later: rejected because the 24-hour interval hasn't passed.
• Bob pays 100 RLUSD an hour later: allowed. The XRP interval doesn't affect RLUSD.
• Bob creates an 800 XRP escrow: checked against Bob + EscrowCreate + XRP and allowed.
• Bob submits an OfferCreate selling XRP: rejected. Bob has XRP limits, but none for OfferCreate.
• Charlie pays 5,000 RLUSD: checked against Charlie's limit only and allowed. Bob's usage is unaffected.
• Alice pays 500 XRP directly: checked against her account-level Payment XRP limit only.

4. Rationale

4.1. Why limits per transaction type?

Agents need to do more than send payments, and an owner will want different limits for different operations. For example, Alice might allow Bob to pay 100 XRP but lock 1,000 XRP in escrow. A single asset-wide limit can't express that.

4.2. Why deny by default?

Per-transaction-type limits on their own leave unconfigured transaction types unrestricted, which is the bypass described in Section 3.3. Denying unconfigured types once limits exist means:

• Limits can't be bypassed by switching transaction types.
• Owners who never configure limits see no change at all.
• Every allowed operation is an explicit decision by the owner.

4.3. Why only the submitter's limits?

• It lets owners restrict agents without restricting themselves.
• Each delegate can have different limits suited to its role.
• It matches how Permission Delegation already treats each delegate independently.

The trade-off is that there is no single combined cap: an owner's total exposure is the sum of what all their limits allow, across all scopes and transaction types. An optional account-wide cap could be added later without changing this model.

4.4. Why separate ledger entries instead of an array?

Storing limits as an array on AccountRoot or Delegate would mean scanning a potentially large array on every transaction and rewriting it on every update. A separate entry per limit allows:

• direct lookup by key,
• independent updates, and
• revocation without bulk deletion.

The design follows patterns from AccountSet, DepositPreauth, and TrustSet.

4.5. Why a separate transaction from DelegateSet?

• Limits also apply to accounts that don't use delegation.
• Keeping them separate leaves Permission Delegation unchanged.
• Limits can be updated without re-specifying permissions.

4.6. Alternatives considered

Alternative	Why not chosen
Asset-wide limits (one limit per asset, shared by all transaction types)	Simple and bypass-proof, but can't set different limits per operation
Per-type limits without deny-by-default	Flexible, but unconfigured types remain a bypass
Smart Features / Hooks (programmable limits)	Still being explored. Spending limits are a basic safety feature that benefits from being native and predictable

4.7. Related work: XLS-86 (Firewall)

XLS-86 (Firewall) by @dangell7 overlaps with this proposal. Firewall's handling of multiple transaction types to prevent bypass is relevant to Section 3.3.

	Firewall (XLS-86)	Spending Limits
Restricts	Destinations, transaction fees	Amount and frequency of spending, per asset and transaction type
Applies to	The account	The owner, or individual delegates

Per-delegate, per-asset limits matter when an owner runs several agents with different responsibilities. One agent may only need to send 100 RLUSD per transaction, while another needs 10,000.

5. Backwards Compatibility

This is a new amendment. It adds a new transaction type and a new ledger entry type.

• No change for accounts without limits. Existing transactions behave exactly as before.
• Accounts that configure limits can have transactions rejected that would previously have succeeded. This is the intended effect.
• DelegateSet and the Delegate ledger entry are unchanged.

6. Test Plan

Planned test coverage, in outline:

• SpendingLimitSet: create, modify, and remove; account-level and delegate-specific; reserve; non-existent delegate; not delegable; several limits configured atomically in a Batch.
• Restrictions: each restriction individually and combined; at, below, and above each threshold; interval boundaries.
• Scope isolation: account-level limits don't affect delegates; delegates don't affect each other; assets don't affect each other; transaction types don't affect each other.
• Deny by default: an unconfigured transaction type and asset is rejected only when the scope has at least one limit; an unrestricted limit allows the type; the indicator stays consistent as limits are added and removed.
• Delegation: permission checks happen before limits; revoking and re-granting; stale limits.
• Per transaction type: spending is measured correctly for each supported type, including partial fills, locks, multiple assets, and cross-currency payments.
• Usage state: updated only on success; unchanged on failure; correct within Batch transactions.

7. Reference Implementation

Not yet available. Early work on the transaction and ledger entry definitions has started.

8. Security Considerations

8.1. What limits protect against

Threat	Delegate-specific limits	Account-level limits
Agent mistakes (hallucination, misunderstanding)	✅ Protected	✅ Protected
Compromised delegate key	✅ Protected	—
Compromised owner key	❌ Not protected	❌ Not protected

• Delegate-specific limits withstand delegate compromise, because a delegate can't change its own limits. This depends on SpendingLimitSet never being delegable. If it were, a delegate could remove its own limits.
• Account-level limits protect against mistakes, not compromise. Anyone who can sign SpendingLimitSet for the account can also loosen or remove its account-level limits. They're intended as a safety net, not a substitute for key security or multisigning. (Open: whether loosening or removing a limit should require more than creating one. See Q9.)
• Delegates must also never be granted transactions that change account control, such as SetRegularKey, SignerListSet, or AccountDelete. Permission Delegation already prevents delegating these.

8.2. Bypass

• Other transaction types: handled by deny-by-default (Section 3.3).
• Deferred effects: Some transactions commit funds that move later, through a transaction someone else submits. For example, an OfferCreate that rests on the order book is filled by another trader, a check is cashed by its recipient, and an NFT buy offer is accepted by the NFT's owner. Limits only see the submitter's transaction, so the proposed approach is to check them once, when the commitment is created, against the full committed amount. The later transaction that moves the funds isn't checked. A commitment that is never filled still counts toward the limit, because limits restrict what the submitter does, not the eventual fund movements. (Open, see Q3.)

9. Open Questions

#	Question
Q1	Where is the active-limit counter stored: on the AccountRoot (account-level) and the Delegate entry (delegate-specific)?
Q2	Should limits be keyed by transaction type or by permission value?
Q3	How is spending measured for partial fills, deferred effects (Section 8.2), transactions that spend multiple assets, and transaction fees?
Q4	Which transaction types are asset-moving and therefore covered by deny-by-default?
Q5	How is removal expressed in SpendingLimitSet?
Q6	Does editing a limit reset its usage state or preserve it?
Q7	Should re-granting a permission reactivate surviving limits and their usage, or start fresh?
Q8	How is the minimum interval measured?
Q9	Should loosening or removing a limit require more than creating one (for example a separate signer)?
Q10	Is native enforcement the right long-term approach, or would Smart Features / Hooks be a better fit?

Appendix

Appendix A: FAQ

A.1: If I limit Bob's XRP payments, can Bob still trade XRP on the DEX?

No, unless you also configure an OfferCreate limit for Bob and XRP. Once Bob has any limit, every asset-moving transaction type needs its own limit for each asset it spends.

A.2: If I never create any limits, does anything change?

No. Transactions behave exactly as they do today.

A.3: Do my account-level limits also apply to my delegates?

No. Only the limits of whoever submits the transaction apply. A delegate with no limits at all is unrestricted, subject to its permissions.

A.4: What happens to limits when I revoke a delegate's permission?

They stay in the ledger and are no longer used, because the delegate can't submit the transaction. You can remove them with SpendingLimitSet to recover your reserve.

A.5: Can a delegate change its own limits?

No. SpendingLimitSet can only be submitted by the owner and can't be delegated.

A.6: Why not just enforce limits in the agent's software?

The agent's software is what we're guarding against. An agent that hallucinates or misunderstands an instruction can also bypass its own checks. Protocol-level limits apply no matter what the agent does.

[dangell7]

I would think about moving it from "Delegate" because one could just delegate and add this in a batch. That way those who don't delegate can still use the feature. I think thats why we put it on firewall.

[BraedonKlock]

I agree, that makes more sense. Any other thoughts or concerns are appreciated!

How should account-level and delegate-specific bounds interact when both exist for the same asset?

For example, if Alice has an account-level XRP bound and Bob has a separate XRP bound, should a payment submitted by Bob be subject to both restrictions, or should his delegate-specific bounds take precedence?

Thanks!