> For the complete documentation index, see [llms.txt](https://docs.stonkfun.bot/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stonkfun.bot/welcome/how-it-works.md). # How STONKFUNBOT Works STONKFUNBOT is reachable from three surfaces — the website, X, and Farcaster — but all three run on the same underlying logic. This page explains that structure. ## One shared core, multiple surfaces Whichever surface you use, the message you send is normalized into a common form and handled by the same shared logic. That logic is the only thing that decides: * what your message means, * what it is allowed to do, and * what gets said back. The website, X, and Farcaster differ in how a message arrives and how a reply is delivered — not in what an action means or how safely it's handled. Equivalent requests behave the same way regardless of surface. ## Identity is the account, never the display name Every account is tied to a stable, immutable identifier from whichever provider you signed in with — not to a username or handle that can change hands. A handle or display name is used only to make a reply read naturally; it is never used to decide whose wallet to sign with. This is what stops a renamed or reassigned social handle from ever inheriting someone else's wallet. A public message from an account with no linked identity does not create one. Registration always happens privately, on the website. ## Conversational input never signs The part of the system that interprets your message can: * answer a question, * price a proposal, and * explain what happened. It cannot sign or submit anything. Turning a proposal into a signed transaction happens through separate, deterministic code — gated entirely on your explicit confirmation of that one specific, already-priced proposal. See [Transaction Flow](/transaction-flow/ask.md) for the full sequence. ## Proposal, then confirmation A request to launch or trade never executes immediately. It is priced, and its terms are stored under a short code tied to your account. Only a second message — from the same account, carrying that code — can turn it into a signed transaction. Confirming re-checks the real cost at that moment; if it moved beyond a small tolerance, the confirmation fails closed rather than silently charging more. See [Confirmations](/understanding-the-system/confirmations.md). ## Where this is enforced This isn't a description of intent — it's a structural property of the system: the conversational layer has no path to sign or submit a transaction on its own. Execution lives entirely behind the confirmation step, on every surface, without exception. --- # 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://docs.stonkfun.bot/welcome/how-it-works.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.