> For the complete documentation index, see [llms.txt](https://smol404.gitbook.io/smol404-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://smol404.gitbook.io/smol404-docs/smol404/architecture.md). # Architecture SMOL404 uses a single contract architecture inspired by ERC 404. The same contract manages both the fungible token balance and the corresponding NFA ownership. At a high level: `BEP 20 balance` ↓ `SMOL404 synchronization` ↓ `BAP 578 NFA` The contract continuously tracks how many complete token units each participating wallet holds. If a wallet moves from: `0.7 → 1.1` it crosses one complete unit. One NFA can therefore be assigned. If that wallet later moves from: `1.1 → 0.6` it falls below one complete unit. The corresponding NFA is returned according to the protocol's assignment logic. Small transfers that do not change the number of complete units do not affect NFA ownership. #### Core relationship For normal participating wallets: `NFA count = floor(token balance / UNIT)` One whole unit corresponds to one NFA. Two whole units correspond to two NFAs. Fractions remain fungible. #### Token transfers The fungible side behaves like a standard token. Users can buy, sell and transfer fractions normally. NFA synchronization only becomes relevant when a wallet crosses a whole unit threshold. #### NFA assignment When a wallet becomes eligible for an additional NFA, the SMOL404 contract assigns one according to the implementation's assignment rules. When a wallet falls below a whole unit threshold, an NFA is returned to the available agent pool. The objective is to keep this process automatic and invisible to normal token trading. #### Liquidity pools DEX contracts and other infrastructure addresses can be exempt from standard NFA synchronization. This prevents liquidity pools from constantly receiving and returning NFAs during swaps. The fungible side can therefore move efficiently through DeFi infrastructure while the NFA layer remains primarily associated with users. #### The agent remains intact SMOL404 controls the relationship between fungible balances and NFA ownership. It does not define the intelligence or execution system of the agent. A BAP 578 NFA can still interact with agent frameworks, wallets, APIs, payment systems or infrastructure such as Binance Agent OS. This creates a clear separation between layers: **Agent infrastructure** What the agent can do. **BAP 578** Who the agent is. **SMOL404** How the market values and trades exposure to it. ## --- # 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://smol404.gitbook.io/smol404-docs/smol404/architecture.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.