Priors agent finance functions classified several post-broadcast RPC or receipt failures as if the transaction had never been sent. The user needs an agent-controlled borrow or bridge flow subject to a spending cap and an ambiguous remote chain response after broadcast. Releasing the budget too early could permit a second transaction even when the first…
Inspect the ClaimsCase · DiggingBeagle record
Priors agent finance caps could be released despite a broadcast transaction
Priors agent finance functions classified several post-broadcast RPC or receipt failures as if the transaction had never been sent. Releasing the budget too early could permit a second transaction even when the first later settled, defeating the intended cap.
The user needs an agent-controlled borrow or bridge flow subject to a spending cap and an ambiguous remote chain response after broadcast. This is a controlled mocked chain scenario, not evidence that a real user incurred two loans.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The cited primary technical report or advisory supports the stated mechanism within its reported scope. The assessment does not infer a production breach, a victim count or a comparable impact score from a laboratory result. A maintainer or advisory names a patched release; that does not prove every deployed instance has updated. Boundary: A transaction broadcast and the receipt of its confirmation are different events.
Assessed Oct 29, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CP23-PRIORS-BROADCAST-RECEIPT-1 · CLM-ENRICH-20261029-28 · Priors ambiguous transaction-receipt spending cap advisory
At a glance
Releasing the budget too early could permit a second transaction even when the first later settled, defeating the intended cap.
Read the implicationsThis is a controlled mocked chain scenario, not evidence that a real user incurred two loans.
Limits and uncertaintyFull account
Priors agent finance functions classified several post-broadcast RPC or receipt failures as if the transaction had never been sent.
The user needs an agent-controlled borrow or bridge flow subject to a spending cap and an ambiguous remote chain response after broadcast. Releasing the budget too early could permit a second transaction even when the first later settled, defeating the intended cap.
This is a controlled mocked chain scenario, not evidence that a real user incurred two loans. Keep cap reservations pending until verified chain settlement or an explicit reconciled failure and use patched Priors MCP/x402 releases.
Evidence interpretation and control boundary. A transaction broadcast and the receipt of its confirmation are different events. The affected wallet tool interpreted a post-broadcast RPC or receipt error as a pre-send refusal and restored borrowing or bridging quota even when an on-chain effect could already be pending. A safe cap ledger holds the reservation until a chain receipt or reliable reconciliation identifies the actual outcome; retry error labels are not transaction finality evidence.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Timeline
- Oct 26, 2026disclosure
Public disclosure
Claims & evidence
CLM-ENRICH-20261029-28The Priors advisory demonstrates a borrow or bridge spend-cap accounting bypass when a transaction had already been broadcast but a later receipt or RPC retry failure was classified as a pre-send refusal.supported
Basis: reported finding
- supportsPriors ambiguous transaction-receipt spending cap advisoryprimary disclosure
GHSA-rh27-m4c4-p2c7: sendBorrow, fundBase, ambiguous receipt and cap-release reproduction
CLM-CP23-PRIORS-BROADCAST-RECEIPT-1Priors agent finance functions classified several post-broadcast RPC or receipt failures as if the transaction had never been sent. The user needs an agent-controlled borrow or bridge flow subject to a spending cap and an ambiguous remote chain response after broadcast. Releasing the budget too early could permit a second transaction even when the first later settled, defeating the intended cap.supported
Basis: reported finding
- supportsPriors ambiguous transaction-receipt spending cap advisoryprimary disclosure
GHSA-rh27-m4c4-p2c7: sendBorrow, fundBase, ambiguous receipt and cap-release reproduction
Implications
Releasing the budget too early could permit a second transaction even when the first later settled, defeating the intended cap.
Controls and mitigations
- Keep cap reservations pending until verified chain settlement or an explicit reconciled failure and use patched Priors MCP/x402 releases.
Unknowns and contradictions
- This is a controlled mocked chain scenario, not evidence that a real user incurred two loans.
Sources and citation
Material revision history
- Oct 29, 2026 · Canonical change recorded · new in release · revision 202