> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.
# x402 Transfers
> x402 protocol token transfers across all chains, with inorganic activity flags for organic volume analysis
The `crosschain.agents.x402_transfers` table contains individual x402 protocol token transfer events across all supported chains. This is a union of chain-specific transfer models.
## Table Columns
| Column | Description |
| -------------------------- | --------------------------------------------- |
| chain | Network name |
| facilitator\_id | Unique facilitator identifier |
| facilitator\_name | Display name of the facilitator |
| block\_timestamp | When the transfer occurred |
| token\_address | Token contract/mint address |
| token\_name | Name of the token |
| token\_symbol | Symbol of the token |
| raw\_amount | Raw transfer amount before decimal adjustment |
| amount | Decimal-adjusted transfer amount |
| usd\_amount | USD value of the transfer |
| usd\_exchange\_rate | Exchange rate used for USD conversion |
| from\_address | Token sender address (buyer) |
| to\_address | Token recipient address (seller) |
| transaction\_from\_address | Transaction signer (facilitator address) |
| transaction\_to\_address | Transaction recipient |
| transaction\_hash | Transaction hash/signature |
| log\_index | Log index (NULL for Solana) |
| block\_number | Block number/height |
| block\_hash | Block hash |
| unique\_id | Unique identifier for the transfer |
| \_created\_at | Record creation timestamp |
| \_updated\_at | Record update timestamp |
## Adjusted Transfers & Inorganic Activity Flags
Some x402 volume is fabricated — self-payments and wash-return loops that inflate a server's apparent transaction count and volume. The `crosschain.agents.x402_transfers_adjusted` table joins `x402_transfers` (on `unique_id`) with flags that identify this activity, so you can filter down to organic volume without re-deriving the detection logic yourself.
### Table Columns
Every column from `x402_transfers` above, plus:
| Column | Description |
| ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| is\_self\_dealing | TRUE when the sender and recipient are the same wallet — a server paying itself |
| is\_reciprocal\_return | TRUE when the recipient sends a proportional stablecoin amount back to the original sender within 24 hours |
| is\_agent\_economy\_circulation | TRUE for servers where circular payment flows are a documented protocol feature (e.g. Virtuals ACP), not fabricated volume |
| is\_inorganic | TRUE when `is_self_dealing` or `is_reciprocal_return` is TRUE and `is_agent_economy_circulation` is FALSE. The primary gate for organic volume |
Use `WHERE NOT is_inorganic` to restrict to organic activity.
### How each flag works
`from_address = to_address` — the x402 buyer and the server receiving payment are the same wallet. In practice this catches developer self-testing: wallets running thousands of transactions against their own server at a fixed low amount. Volume impact is negligible (\<0.01% of total), but the check is essentially free to run.
Flags a payment when the receiving server sends stablecoin back to the original payer within **24 hours**, at **no more than 10x** the original payment amount.
The 24-hour window comes from a 30-day calibration sample: the signal accumulates almost entirely within the first hour (5.71% of organic payments have a same-side return) and flattens out by 24 hours (6.34%) and 7 days (6.75%) — the tail past 24h is noise. The 10x proportional cap excludes servers that use their x402 receiving address as a general treasury wallet; without it, any large unrelated outflow to a past payer would be flagged as a "return" regardless of intent.
**Known limitation:** the check uses the earliest stablecoin return on the same calendar day. If a server sent stablecoin to a buyer earlier that day for an unrelated reason (before the x402 payment), a later, legitimate refund can be masked. This is unlikely to affect adversarial wash trading, where the return specifically follows the payment.
Carves out servers where circular payment flows are designed protocol behavior, not wash trading. Currently covers Virtuals ACP (`acp-x402.virtuals.io`, pay-to address `0xef4364fe4487353df46eb7c811d4fac78b856c7f`), whose protocol treasury distributes earnings back to agent wallets that are often also buyers of the same server. Without this carve-out, roughly 24% of Virtuals transactions (18% of volume) would be falsely flagged as inorganic.
The top-level gate: `(is_self_dealing OR is_reciprocal_return) AND NOT is_agent_economy_circulation`. `TRUE` means the transfer is suspected fabricated volume.
Two patterns were investigated and deliberately left unflagged. **High-frequency buyers** aren't flagged because thousands of micropayments to the same server is the intended x402 use case, not bot behavior. **Triangular wash loops (A→B→C→A)** aren't flagged because the only rings found in a 30-day sample were artifacts of a single facilitator's internal payment-routing infrastructure, not adversarial gaming.
## Sample Queries
### All transfers
```sql theme={null}
SELECT
chain,
block_timestamp,
facilitator_name,
from_address AS buyer,
to_address AS seller,
usd_amount
FROM crosschain.agents.x402_transfers
ORDER BY block_timestamp DESC
LIMIT 100;
```
### Organic volume only
```sql theme={null}
SELECT
chain,
block_timestamp,
facilitator_name,
from_address AS buyer,
to_address AS seller,
usd_amount
FROM crosschain.agents.x402_transfers_adjusted
WHERE NOT is_inorganic
ORDER BY block_timestamp DESC
LIMIT 100;
```