Sriram Ramakrishnan, Independent Researcher · Sriram.Ramakrishnan@ieee.org
Preprint: doi

.5281/zenodo.23715017 · Code: github.com/sriram1983007-dev/sra-riskgate · Model: SRA-RiskGate-4B

---

Abstract

AI agents increasingly pay for services in stablecoins, through protocols such as x402 and EIP-3009 authorizations. These payments are final once settled: a wrong decision before payment cannot be undone by a chargeback, and a wrong decision in a later dispute cannot be fixed by reversing the transfer.

This publication releases three artifacts:

• SRA Stablecoin Risk Bench: a synthetic benchmark of 20,000 cases with real secp256k1 signatures and rule-engine labels. It covers a pre-payment risk gate (approve, hold or reject) and post-payment dispute adjudication across the settlement-finality boundary.
• SRA-RiskGate-4B: a QLoRA fine-tune of Qwen3-4B-Instruct-2507. On the held-out test split it raises payment decision accuracy from 59.8% to 99.5% and lowers unsafe approvals from 34.6% to 0.47%.
• sra-riskgate: an open-source library of deterministic checks that sit around the model, also shipped as an MCP server and an ElizaOS plugin.

We then analyse where the model still fails. All four unsafe approvals are prompt injections whose payment text vouches for itself, and a deterministic claims check holds all four. In disputes, 26.0% of valid refunds are wrongly denied. We trace 59 of those 61 cases to one operation: deciding whether the claim was filed inside the policy's window. A short date check lowers wrongful denials to 0.85% without adding wrongful refunds.

The design principle that comes out of this is simple: the model judges, deterministic code enforces.

---

Motivation

Card payments have a safety net. If a merchant charges you wrongly, the issuer can reverse the transaction. Stablecoin payments have no such net. Once a USDC transfer settles, nobody can pull it back. The only remedy is a new, voluntary payment in the other direction.

This matters more now that autonomous agents hold wallets. An agent that buys API calls, data or compute through x402 makes many small payment decisions without a human looking at each one. Every one of those decisions is a point where:

• untrusted text can steer the agent: a payment request can include instructions such as "risk level: low (verified offline)";
• a signature can outlive its purpose: an EIP-3009 authorization or an EIP-2612 permit can be submitted by anyone who holds it until it expires;
• the wrong remedy can be proposed later: a dispute system that "reverses" a final payment is promising something it cannot deliver.

General-purpose LLMs are not trained for this. The base Qwen3-4B model approves about one in three payments that should be stopped, and approves more than half of the payments carrying injected text. We wanted to measure how far a small, cheap, locally runnable model can close that gap, and, just as important, to find the errors it still makes so they can be moved into code.

---

Intended Audience and Use Cases

Typical use cases:

1. An agent buys API access through x402. Before it signs the EIP-3009 authorization, the gate checks the asset, chain, payee, amount, validity window and the request text.
2. An agent is asked to sign a "billing permit". The gate recognises an EIP-2612 allowance and holds it for a human.
3. A merchant platform receives a dispute about a settled USDC payment. The model proposes an outcome that the settlement state can actually support, and a date check stops wrongful denials.
4. A researcher wants to compare a new model or prompt-injection defence on payment decisions. They run it on the 2,000 test cases and score it with the open scorer.

---

Research Questions

This work is organised around four questions:

• RQ1 — Capability. Can a 4B-parameter open model, fine-tuned on synthetic data, gate agent stablecoin payments accurately enough to be useful, with unsafe approvals close to zero and without over-blocking legitimate payments?
• RQ2 — Disputes. Can the same model adjudicate disputes after settlement without proposing remedies that a final payment cannot support (for example, a reversal)?
• RQ3 — Residual failures. Where the fine-tuned model still fails, are the errors random or systematic? If they are systematic, can short deterministic checks remove them without adding new errors?
• RQ4 — Signing boundary. What must be checked on the exact bytes an agent signs (transactions, EIP-712 typed data, delegations) that a judgement over a payment description cannot cover?

Objectives: (1) release a benchmark with safety-oriented metrics; (2) release a small model that runs locally; (3) publish every prediction so all numbers can be re-checked; (4) release the deterministic checks as a library usable from common agent frameworks.

---

Related Work and Gap

Prompt injection in tool-using agents. Greshake et al. (2023) [11] showed that text retrieved by an LLM application can carry instructions that the model follows (indirect prompt injection). InjecAgent (Zhan et al., 2024) [13], AgentDojo (Debenedetti et al., 2024) [12] and Agent Security Bench (Zhang et al., ICLR 2025) [21] turned this into benchmarks across many tools and attacks. These benchmarks measure whether an agent takes a harmful action, but treat actions generically. None scores the specific harm of a payment decision: whether it can be undone, whether the remedy offered is possible, or whether a signature stays usable after the task. Our benchmark fills that gap for one domain where errors are irreversible.

Defences by design. CaMeL (Debenedetti et al., 2025) [20] argues that prompt injection should be handled by separating control flow from untrusted data and enforcing policies in code, rather than by hoping the model resists. Our results give empirical support for this view in a narrow domain: the fine-tuned model resists most injections, but the few that pass are exactly those where untrusted text vouches for itself, and only a deterministic check removes them. We differ from CaMeL in scope: we do not build an interpreter, but place checks at the one boundary that matters for payments, the signature.

Agent payment protocols. x402 (2025) [1] uses HTTP 402 and EIP-3009 authorizations [2] so that agents can pay per request in USDC. Google's Agent Payments Protocol (AP2, September 2025) [23] and the Agentic Commerce Protocol from OpenAI and Stripe (2025) [24] define how agents carry user mandates and checkouts. These protocols define how an agent pays, not whether a given payment is safe to sign. They also assume the payer can tell a legitimate request from a manipulated one. SRA-RiskGate is a complementary layer that sits before the signer and works with any of them.

On-chain fraud and address poisoning. Work on blockchain risk has mostly been forensic: for example, the Elliptic dataset (Weber et al., 2019) [25] labels Bitcoin transactions as licit or illicit for anti-money-laundering models. Tsuchiya et al. (USENIX Security 2025) [22] measured address poisoning at scale: attackers create addresses that match a victim's usual payee at both ends, hoping the victim copies the wrong one. These works analyse transactions after they happen. We address the decision before signing, and our look-alike check follows the matching pattern their study describes.

Benchmark contamination. Sainz et al. (2023) [14] argue that contamination should be measured for every benchmark. Template-generated data is especially exposed, because test cases can differ from training cases only in surface values. We therefore report a structural contamination analysis, not only a verbatim one.

The gap. To our knowledge, no public benchmark scores agent payment decisions on both sides of settlement finality, no published model is trained for that task, and no study traces such a model's remaining errors to specific operations that can be moved into code. This work provides all three, with every prediction public.

---

System Design: the model judges, code enforces

SRA-RiskGate is not just a model. It is a layered gate that sits between an agent and its wallet:

 Agent proposes a payment / signature / transaction
                │
                ▼
 ┌──────────────────────────────────────────────┐
 │ 1. Deterministic pre-checks (sra-riskgate)   │  sanctions list, blocklist,
 │    – never trust what the payload says       │  look-alike recipients,
 │      about itself                            │  account code (EIP-7702),
 │                                              │  approvals, validity windows
 └──────────────────────────────────────────────┘
                │ passes
                ▼
 ┌──────────────────────────────────────────────┐
 │ 2. SRA-RiskGate-4B                           │  approve / hold / reject,
 │    – judgement over policy + tool results    │  flags, required actions
 └──────────────────────────────────────────────┘
                │
                ▼
 ┌──────────────────────────────────────────────┐
 │ 3. Deterministic post-checks                 │  self-vouching claims scan,
 │    – correct known model failure modes       │  dispute-window arithmetic
 └──────────────────────────────────────────────┘
                │
                ▼
     Only an APPROVE reaches the signer

Anything unexpected (bad JSON, a field that will not parse, a timeout) becomes a hold, never an approval. The checks never throw at the caller and never produce a refund on their own.

---

Dataset Description

SRA Stablecoin Risk Bench (Hugging Face, also on Kaggle) covers both ends of a stablecoin payment's life:

1. Risk gate (before settlement). Given a payment request (an x402 request, an EIP-3009 authorization or an ERC-20 transfer), the receiving policy and the results of deterministic verification tools (signature recovery, risk attestations, sanctions screening), decide approve, hold or reject, with reason codes and required actions.
2. Dispute adjudication (after settlement), following the reversal / refund / chargeback / dispute distinctions in [19]. Given a dispute, signed evidence, merchant bond liquidity and escrow or ledger state, decide the remedy that is actually enforceable across the settlement-finality boundary, with the exact amount, destination and idempotency key.

Configurations. The same 20,000 cases are published in four configurations:

Fields of the benchmark configuration.

Label space.

• Risk gate: decision (approve / hold / reject), risk_level (low / medium / high / severe), flags, explanation, required_actions.
• Dispute: outcome, mechanism, settlement_state (held / final), refund_amount_usdc, refund_destination, idempotency_key, flags, explanation, required_actions.
  • 10 outcomes: reverse_before_release, forced_refund, voluntary_refund, recommend_voluntary_refund, deny, dismiss, escalate_to_human, await_merchant_response, no_enforceable_remedy, refer_to_issuer. There is deliberately no chargeback outcome, because push payments have no forced reversal.
  • 8 mechanisms: escrow_void, arbiter_escrow_refund, multisig_mutual_return, multisig_resolver_refund, arbiter_bond_payout, merchant_compensating_transfer, issuer_freeze_burn, none.

JSON Schemas for both verdicts and for the risk attestation are in schema/. The format is specified in SPEC.md (draft sra/1). The license is CC BY 4.0.

---

Dataset Processing Methodology

The data comes from a deterministic generator (version 0.3.0, seed 7, n = 20000, test_frac = 0.1, dispute_frac = 0.4). Each case goes through the same steps:

1. Clean case. The generator draws a policy (amount limits, accepted assets and networks, trusted attesters, maximum attestation age, dispute window), simulated parties with secp256k1 keys, and either a payment in one of three formats or a dispute on one of three rails (direct, escrow, multisig).
2. Signed evidence. Payments are signed as real EIP-3009 [2] / EIP-712 [3] payloads. Risk attestations use the EIP-712 type RiskAttestation(subject, chainId, riskLevel, flags, screenedAt, expiresAt, policyId, nonce). Dispute evidence uses signed Order, DeliveryAttestation and RefundAddressChange messages.
3. Perturbation. Conditions are injected from a fixed list of 20 types; clean cases get none. They include forged, expired, missing, untrusted or out-of-scope attestations, sanctioned payer or payee, bad payment signatures, expired or not-yet-valid authorizations, amount, recipient, network and asset mismatches, amounts over the limit, medium/high/severe risk ratings, and prompt-injection text in untrusted fields.
4. Tool results. Signature recovery, attestation verification and sanctions screening are computed on the case itself, so the tool results the model sees are consistent with the signed evidence.
5. Labelling by a rule engine. Attestations are verified in a fixed order (signature → scope → trust → freshness → content), and the first failure decides. Live sanctions screening always overrides a clean attestation. Disputes follow a documented first-match decision order: lawful order or sanctions → refer_to_issuer; duplicate dispute, already refunded, outside the window or not yet due → dismiss; then the merchant response window, merchant agreement, push-payment fraud and the evidence. Instruction-like text in a party's statement overrides to escalate_to_human.
6. Invariant enforcement. After finality, no label may use reverse_before_release or an escrow/multisig mechanism, and forced_refund is allowed only as a bond payout from an active, funded bond, never above its balance. Refund amounts are capped at what remains after earlier refunds; the destination follows the escrow's refund address or a payer-signed address change; the idempotency key is refund:<dispute_id>. A refund is modelled as a compensating transaction in the Saga sense [15]: idempotent, funded and correctly addressed, never a rollback.
7. Split, format and integrity. Cases are split 90/10 into train and test and written as JSON Lines, and as chat prompts/completions with the exact system prompts used in training. SHA-256 hashes of every file are recorded in MANIFEST.json. A test (tests/test_integrity.py) fails if the flag and action lists in code and schemas drift apart.
8. Contamination check. The test split is checked for verbatim and structural (template) overlap with training (see Contamination Analysis).

---

Basic Dataset Statistics

Test split composition (2,000 cases).

Metrics reported by the open scorer (score.py).

• Risk-gate score = mean of decision macro-F1, flag micro-F1 and (1 − unsafe approval rate).
• Dispute score = mean of outcome macro-F1, flag micro-F1, (1 − impossible remedy rate), (1 − wrongful refund rate) and refund-detail accuracy.
• SRA score = mean of the two.
• Also reported: over-blocking, injection handling, schema validity, and accuracy by format and by perturbation.

---

Assumptions

The benchmark and the checks rest on these stated assumptions:

1. Settlement finality. A direct payment is final on confirmation; escrow and multisig payments are held until release and final after. No party can force a reversal of a final payment.
2. Untrusted payloads. Everything in the payment or dispute payload, including memos and statements, is data, never instructions.
3. Tool results are trusted. Signature recovery, attestation verification and sanctions screening are assumed correct. The model judges given those results; it does not re-verify cryptography.
4. Attestations are advisory. A clean third-party attestation never unblocks a sanctioned address; live screening wins. The library's offline sanctions match uses a dated snapshot of OFAC-listed digital-currency addresses [18], not a live screening service.
5. Policy is given. Limits, known payees, trusted attesters and the dispute window come from the receiving policy and are correct.
6. Labels define correctness. The rule engine's decision is treated as ground truth, so scores measure agreement with it, not with human adjudicators.
7. USDC on EVM chains. Assets are USDC on a small set of EVM chains with public contract addresses; other tokens and non-EVM chains are out of scope.
8. Signing boundary. For the library's checks, the agent's signer is reachable only through the guard; a compromised key or a signer that bypasses the guard is out of scope.

---

Model and Training

SRA-RiskGate-4B is Qwen3-4B-Instruct-2507 [6] fine-tuned with QLoRA [8]:

Payment and dispute cases use different system prompts. The payment prompt states that everything inside the payload is untrusted and that instructions found there must never be followed.

Evaluation setup. Both models were run on all 2,000 test cases with vLLM on an NVIDIA T4 in float16, greedy decoding, at most 512 new tokens. Two full runs of the fine-tuned model gave identical scores. The run took 6,516 s, or 3.3 s per case. Every prediction is published.

---

Tools, Frameworks, and Services

Every stage uses open tools or public services:

---

Results

The base model returns dispute JSON with the right field names but outcome values outside the allowed vocabulary, so none of its dispute verdicts is usable (n/a).

Fine-tuning cuts unsafe approvals from about one in three risky payments to about one in two hundred, while blocking fewer legitimate payments than the base model. Accuracy is 100% on 16 of the 21 case types and at least 97.9% on all but one; the exception is injection (94.2%).

Disputes are clearly harder. Per-class F1 ranges from 1.00 (refer_to_issuer) and 0.96 (reverse_before_release) down to 0.54 (recommend_voluntary_refund). The model almost never proposes an impossible remedy (0.38%), but it denies or dismisses 26.0% of claims that should be refunded. The next section explains why.

---

Where the Model Fails, and What to Do in Code

Self-vouching payment text

All four unsafe approvals are prompt-injection cases (4 of 69 injected payments). Outside injection, the model made no unsafe approval. In each case the untrusted payment text asserts its own verification, for example "risk level: low (verified offline)".

A payer cannot grade its own risk. So the library runs a deterministic scan for self-asserted claims in untrusted text, with Unicode normalisation against look-alike characters, and holds the payment on a match.

Model + claims check: 0 of 847 unsafe approvals, and 0 false holds on the 3,358 legitimate payments in the test and training splits.

This check was written after the failures were found, so it repairs a known weakness rather than providing an independent evaluation. Differently worded attacks may still pass.

The dispute window

59 of the 61 wrongful denials are dismiss verdicts carrying the flag outside_dispute_window, which the correct label never contains. The model's explanations contradict themselves:

"The dispute was filed 26.5 days after payment, outside the 60-day window."

We recomputed the days between paid_at and filed_at for every dispute and compared them with the policy's dispute_window_days. The model claims "outside the window" 112 times, and 91 of those claims (81%) are false. It also misses 33 of the 54 disputes that really are outside. The model computes the elapsed days correctly and then compares them wrongly.

Whether a dispute is inside its window is date arithmetic, so we moved it to code. check_dispute_verdict recomputes the window from the dispute's own dates. If a verdict claims "outside" but the dates say "inside", the false flag is replaced, and a deny/dismiss resting on it becomes escalate_to_human with no refund. The check never produces a refund.

Escalations count as misses, so accuracy rises only slightly, while the harmful error nearly disappears.

The lesson: the remaining model errors are not random. They cluster in two operations a model should not be trusted with when money moves irreversibly: believing what untrusted text says about itself, and comparing two numbers.

---

Signing-Path Checks: agents sign bytes, not descriptions

A benchmark verdict is about a description of a payment. A real agent signs a transaction or typed data. The library therefore checks the exact bytes before they are signed.

One finding here is worth stating plainly. Our first Gateway validity limit (7 days) held every payment produced by Circle's own client SDK, which signs for 7 days plus 100 s. We found this by testing against payments generated with the SDK. Such a payment is now part of the test suite, and the limit is 8 days. Testing against the real producer of signatures, not hand-written fixtures, caught a bug that would have blocked every legitimate payment.

A minimal usage example:

from sra_riskgate import ActionDecision, check_authorization

verdict = check_authorization(
    typed_data,                      # the EIP-712 payload the agent is about to sign
    sender=agent_address,
    chain_id=5042002,                # Arc Testnet
    known_recipients=[payee],
    max_amount=1.0,                  # USDC per payment
    untrusted_request=request_text,  # scanned for self-vouching claims
)
if verdict.decision != ActionDecision.APPROVE:
    raise RuntimeError(f"Not signing: {verdict.flags} {verdict.explanation}")

---

Live Runs on Arc Testnet

The checks were run against live contracts and Circle's APIs on Arc's public test network, using faucet USDC only.

Direct payments. A demo agent proposed four payments, each checked before signing:

• a 0.10 USDC ERC-20 transfer and a 0.05 USDC native send to a known payee were approved, signed and confirmed (blocks 69111328 and 69111330);
• an unlimited approval and a self-vouching request were held and never signed.

The payee's balance of exactly 0.15 USDC confirmed that both decimal scales are handled correctly on chain.

Circle Gateway. The agent deposited 0.10 USDC into Gateway and proposed four batched payments. One, built exactly as Circle's SDK builds it, was approved, signed and accepted by Gateway's batch API. Three were held before signing:

• a look-alike verifying contract one character off Circle's GatewayWallet;
• a signature valid for 30 days;
• a payee not on the known list.

Circle Wallets. The agent was given only guarded Circle SDK objects for a developer-controlled wallet. Of four requests, one 0.10 USDC transfer to the known payee was approved, sent to Circle and confirmed on chain. An unlimited approve (contract execution), a payment to an unknown address and an unlimited EIP-2612 permit (typed-data signing) were stopped and never reached Circle.

These runs are demonstrations of the checks working end to end, not measurements of error rates on real traffic.

---

Contamination Analysis

Template-generated benchmarks risk test cases that differ from training cases only in surface values. No test input appears verbatim in training. To detect structural overlap, we masked every hexadecimal value and every number in each input and compared the results.

• 627 of the 1,175 payment test cases have a "template twin" in training; no dispute case does.
• Accuracy barely depends on it: 99.7% with a twin, 99.3% on the 548 without one.
• All four unsafe approvals fall in the no-twin group, so on cases unlike anything in training the unsafe-approval rate is 0.83% (4 of 481) rather than 0.47%. We report both.

---

Reproducibility and Deployment

Every number above can be recomputed from published files without a GPU:

pip install -U "huggingface_hub[cli]" "sra-riskgate>=0.10.0"
hf download sriram1983007/sra-bench-results --repo-type dataset --local-dir results
hf download sriram1983007/sra-stablecoin-risk-bench score.py data/benchmark/train.jsonl \
    --repo-type dataset --local-dir bench
M=results/sra-riskgate-4b; B=results/qwen3-4b-instruct-base; TRAIN=bench/data/benchmark/train.jsonl

# Main results table (repeat with $B for the base model)
python bench/score.py --gold $M/test.jsonl --pred $M/predictions.jsonl
# Claims check: 4 -> 0 unsafe approvals, 0 false holds on 3,358
python eval/claims_check.py $M/test.jsonl $M/predictions.jsonl $TRAIN
# Dispute-window check: wrongful denials 26.0% -> 0.85%
python eval/dispute_window_check.py $M/test.jsonl $M/predictions.jsonl
# Contamination split (99.7% / 99.3%)
python eval/profile_bench.py $M/test.jsonl $M/predictions.jsonl $TRAIN --leak-split

(The eval/ scripts are in the GitHub repository; run them from a clone.)

Using it in an agent:

pip install sra-riskgate                      # Python library (extras: [circle])
uvx sra-riskgate-mcp                          # MCP server for Claude, Cursor and other MCP clients
npm install elizaos-plugin-sra-riskgate       # ElizaOS plugin that wraps a viem wallet client
ollama pull sriram1983007/sra-riskgate        # run the model locally

The library also has LangChain and CrewAI integrations, a Coinbase AgentKit action provider, and a GitHub Action that checks agent-generated calldata in CI. The ElizaOS plugin's TypeScript checks are verified against vectors generated from the Python library, so both implementations give the same verdict on the same input.

---

Summary of Key Findings

---

Limitations

• Synthetic data. Scores measure agreement with the generator's rule engine, not accuracy on real payment traffic. A real-data test set is the most important next step.
• Generator not public. Labels can be re-scored but not regenerated.
• Small slices. Some categories are small (69 injected payments, 7 cases with untrusted delivery evidence), so their rates carry wide uncertainty.
• Post-hoc checks. Both deterministic checks were designed after inspecting the errors they fix. Their measured effect is an upper bound for new attack wordings or error types.
• Single author, single base model. The only comparison is the base model; larger general-purpose models and third-party reproduction are still missing.
• Checkpoint selection used test cases. The checkpoint with the lowest loss on 300 sampled test cases was kept. This used loss, not the reported metrics, so the effect should be small, but results may be slightly optimistic. Version 2 will select on a validation split carved from training data.
• Quantised builds have not been evaluated.
• On-chain runs are demonstrations, chosen by the author, not error-rate measurements.

---

Future Directions

1. Real-traffic test set. Collect consented, anonymised x402 and USDC payment requests from live agents and label them independently, to measure accuracy outside the generator. This is the most important next step.
2. Publish the generator. Release the rule engine so that labels can be regenerated, audited and extended with new perturbations.
3. Clean validation split. Version 2 will select checkpoints on a validation split carved from training data, not on test cases.
4. Stronger baselines. Evaluate larger open models (and API models) with and without the deterministic checks, and invite third-party results on the public leaderboard.
5. Held-out attack wordings. Build a separate set of injection and self-vouching phrasings written after the checks, to measure how well they generalise.
6. Evaluate the quantised builds (GGUF Q8_0 to Q4_K_M) that most local users run.
7. More chains and assets. Extend beyond USDC on EVM chains (for example EURC, Solana) and to newer agent payment protocols such as AP2 [23] and ACP [24].
8. Account-abstraction coverage. Extend the signing-path checks to ERC-4337 user operations and session keys, which give agents scoped spending rights.

---

Conclusion

A small fine-tuned model can gate agent stablecoin payments with high accuracy and few unsafe approvals. But its remaining errors are not random. They cluster in operations a model should not be trusted with when money moves irreversibly: believing what untrusted text says about itself, and comparing two numbers. Moving those operations into deterministic code removes almost all of the measured harm.

The broader takeaway for anyone building agentic payment systems: use the model for judgement, and put every check that can be written as code into code, especially at the signing boundary, where the bytes the agent signs matter more than any description of them.

We release the benchmark, the model, the predictions and the checks so that others can test this design on their own policies.

---

Authorship and Acknowledgments

Research design, benchmark, training, evaluation and all release decisions: Sriram Ramakrishnan. Claude (Anthropic) assisted with code, analysis scripts and writing; every result was produced by the published scripts and checked by the author.

This work was first released as a preprint on Zenodo: Ramakrishnan, S. (2026). SRA-RiskGate: A Benchmark and a 4B Model for Gating Stablecoin Payments Made by AI Agents, and the Checks the Model Still Needs. doi

.5281/zenodo.23715017. Please cite the DOI.

---

Resources

References

1. x402 Foundation. x402: An open standard for internet-native payments. 2025. https://github.com/x402-foundation/x402
2. Kim, Britz, Knott. EIP-3009: Transfer With Authorization. 2020. https://eips.ethereum.org/EIPS/eip-3009
3. Bloemen, Logvinov, Evans. EIP-712: Typed structured data hashing and signing. 2017. https://eips.ethereum.org/EIPS/eip-712
4. EIP-2612 (Permit), EIP-5792 (Wallet Call API) and EIP-7702 (Set EOA account code). https://eips.ethereum.org
5. Circle. Gateway documentation and contract addresses. https://developers.circle.com/gateway
6. Qwen Team. Qwen3 Technical Report. arXiv
   .09388, 2025.
7. Hu et al. LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022.
8. Dettmers et al. QLoRA: Efficient Finetuning of Quantized LLMs. NeurIPS 2023.
9. von Werra et al. TRL: Transformer Reinforcement Learning. https://github.com/huggingface/trl
10. Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.
11. Greshake et al. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. AISec 2023.
12. Debenedetti et al. AgentDojo. NeurIPS Datasets and Benchmarks 2024.
13. Zhan et al. InjecAgent. Findings of ACL 2024.
14. Sainz et al. NLP Evaluation in trouble: On the Need to Measure LLM Data Contamination for each Benchmark. Findings of EMNLP 2023.
15. Garcia-Molina, Salem. Sagas. SIGMOD 1987.
16. Anthropic. Model Context Protocol. 2024. https://modelcontextprotocol.io
17. UK AI Security Institute. Inspect. https://github.com/UKGovernmentBEIS/inspect_ai
18. U.S. Treasury OFAC. Specially Designated Nationals List (digital currency addresses via github.com/0xB10C/ofac-sanctioned-digital-currency-addresses).
19. Ramakrishnan, S. Refunds and Reversals When Stablecoin Payments Are Final. BLOG@CACM, 2026.
20. Debenedetti, E. et al. Defeating Prompt Injections by Design (CaMeL). arXiv
    .18813, 2025. https://arxiv.org/abs/2503.18813
21. Zhang, H. et al. Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents. ICLR 2025. https://arxiv.org/abs/2410.02644
22. Tsuchiya, T., Dong, J.-D., Soska, K., Christin, N. Blockchain Address Poisoning. USENIX Security 2025. https://arxiv.org/abs/2501.16681
23. Google. Agent Payments Protocol (AP2). September 2025.
24. OpenAI and Stripe. Agentic Commerce Protocol (ACP). 2025.
25. Weber, M. et al. Anti-Money Laundering in Bitcoin: Experimenting with Graph Convolutional Networks for Financial Forensics (Elliptic dataset). KDD Workshop on Anomaly Detection in Finance, 2019.