# Spam Transactions & Abuse Prevention Policy (Beta) ### Overview To maintain stable and fair access to our infrastructure, we actively monitor transaction delivery quality and abusive usage patterns across the platform. Certain behaviors, especially large-scale transaction spam through bundle systems, can negatively impact both our infrastructure and our SWQoS partners. Because of this, we have introduced **automated protection** and **penalty mechanisms** designed to prevent bad actor behavior and preserve service quality for all users. {% hint style="warning" %} This policy applies to all users of the Beta product and is subject to updates as the product evolves. {% endhint %} *** ### What We Consider Spam Transactions A transaction may be considered spam when it is intentionally or systematically submitted without a realistic intent to land on-chain. The most common example includes: * High-volume Jito bundle submissions that never land on-chain * Repeated broadcast attempts with extremely low landing probability * Artificial traffic generation aimed at saturating routing or SWQoS capacity * Transaction flooding patterns that degrade infrastructure performance for other users While occasional failed transactions are expected in normal Solana network conditions, persistent failure patterns indicate abusive behavior. *** ### Transaction Sending Rate Limits | | | | | | | ---------- | --------- | ---------- | ---------- | ------------ | | Plan | **Start** | **Focus** | **Stream** | **Aperture** | | Rate limit | 60 tx/min | 200 tx/min | 500 tx/min | 500 tx/min | {% hint style="info" %} **The number of transactions within the bundle** is calculated too, e.g. while sending bundles of 2 transactions each on Focus, the effective rate limit will look like 50 bundles/min and 6,000 bundles/hour. {% endhint %} *** ### Landing Ratio Monitoring We continuously evaluate the transaction landing ratio associated with an account. #### Spam Threshold If the majority of submitted transactions fail to reach the blockchain over a sustained observation period, this is treated as a strong indicator of consistent spam activity. At that point, the **account will automatically enter a penalty state.** *** ### Penalty State & Throttling Users identified as generating spam traffic may be subject to temporary restrictions, including: * RPC endpoint throttling * Reduced rate limits * Bundle submission restrictions * Temporary subscription suspension * Additional internal review procedures This effectively creates a de facto blockade intended to protect the platform and our infrastructure partners from abuse. *** ### Automatic Recovery The penalty state is not necessarily permanent. If the user stops abusive behavior and returns to normal transaction patterns, the restriction will be automatically lifted after a sustained period of compliant activity. Once the system detects healthy behavior again: * Rate limits gradually return to standard subscription levels * Penalty measures may be removed automatically * Account status returns to normal operation *** ### Important Notes About Beta Status Our anti-spam systems, landing-ratio thresholds, rate limits, and penalty mechanisms are currently part of a Beta product environment. Because of this: * Detection methodologies may evolve * Thresholds may change without prior notice * Enforcement policies may be adjusted as infrastructure requirements evolve * Additional protections may be introduced over time **We reserve the right to apply protective measures whenever account activity threatens platform stability, infrastructure integrity, or service quality for other users.** *** ### Fair Use Reminder Our infrastructure is designed for legitimate transaction delivery and low-latency blockchain operations — not for synthetic traffic generation or infrastructure abuse. Users are expected to operate within reasonable fair-use boundaries and ensure that their transaction flow reflects genuine blockchain intent. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/spam-transactions-and-abuse-prevention-policy-beta.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.