> For the complete documentation index, see [llms.txt](https://whitepaper.getpaid.family/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.getpaid.family/introduction/the-problem.md). # The Problem Outlines fee-routing constraints and GetPaid’s proposed responses through multi-rail settlement, adapters, flexible recipients, token mechanisms, and anti-vamping. GetPaid is designed to address five constraints common to fee-routing systems. ### 1. Single-rail payouts Some payout systems depend on one rail, such as X Money or crypto worker wallets. That dependency can limit how recipients receive value. GetPaid proposes a multi-rail architecture so an integrated launchpad could support more than one settlement path. The final rails and their operating constraints remain undefined. ### 2. Single-chain scope Fee-routing systems can be bound to one chain or ecosystem. This fragments routing logic when launchpad activity spans different networks. GetPaid proposes a multi-chain adapter architecture. The aim is to provide a common routing layer while accommodating chain-specific integrations. No adapters are deployed. ### 3. Single-recipient routing Some models primarily route fees to a single creator. That approach does not inherently express holder participation or treasury allocation. GetPaid proposes configurable destinations that may include: * A creator * Token holders * A protocol or community treasury Recipient rules, allocation logic, and eligibility criteria will be finalized before deployment. ### 4. Burn-only token utility Burn-only models provide one path for fee-linked token activity. The GetPaid design considers a broader set of mechanisms: * Burn * Buyback * Staking * Governance This utility model is proposed. It does not establish token performance or investment outcomes. ### 5. Fee-recipient flexibility Recipient configuration creates a tradeoff. Permanent locks can prevent legitimate changes. Unlimited flexibility can enable fee recipients to be changed too easily. GetPaid proposes an anti-vamping approach with limited early changes, seven-day cooldowns, and later **LOCK** or **FLEXIBLE** modes. The design balances predictable recipient rights with controlled configuration changes. These mechanisms are proposed. GetPaid has not deployed or validated them in production. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://whitepaper.getpaid.family/introduction/the-problem.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.