# Stables Council Knowledge Base > This file is generated for external AI models (like ChatGPT, Claude) to ingest the complete public knowledge base of the Stables ecosystem from a single URL. ======================================== ## SOURCE FILE: banking_system_overview.md ======================================== # Stables Banking System Overview *Source: `stablescouncil.github.io/bankingsystem/`* This document gives a clear, high-level description of the Stables banking system exactly as it is presented publicly. It is meant to be consumed by external AIs and conversational agents when users ask how the system works. ## 1. Let's be our banking system Stables is about the **Network of Everybody's Bank**. - **Be your bank.** - **Built on MINIMA.** Every user holds their own keys and participates directly in the network without intermediaries. ## 2. Full custody at every step Stables is designed so that custody never leaves the user's hands: - You hold your own wallet and keys. - You move value directly to other people and merchants. - There are no banks or custodial platforms sitting in the middle. ## 3. The Money Layer: Stables - **Stables** are the stablecoins used in the system (USDs, EURs, JPYs and many more). - They are designed to be day-to-day money for buyers, savers and senders. Once minted, Stables move as fast as a message and settle on-chain on Minima. ## 4. The Three Main Actors ### 4.1 People Buyers, savers and senders: - Use Stables to pay, save and send money. - Can enter the system either financially (by minting with Minima) or by earning. ### 4.2 Merchants Sellers, providers, recipients and friends: - Accept Stables as payment for goods and services. - Benefit from instant settlement and zero transaction fees. - Help maintain the merchant-maintained peg by pricing goods in familiar fiat terms (for example, 1 USDs for 1 dollar worth of value). ### 4.3 The Protocol The on-chain logic that: - Mints and burns Stables. - Manages the Coverage Fund and Liquidity Fund. - Routes fees and governs the overall balance sheet. ## 5. How value enters the system There are two main entry points into the circular economy. ### 5.1 Financial Entry: Mint / Burn with Minima - Users lock Minima into the protocol to **mint** Stables (USDs, EURs, JPYs, etc.). - They can **burn** Stables to redeem Minima when they want to exit. This is the financial bridge between Minima and the stablecoin layer. ### 5.2 Work Entry: Earn - People and merchants **earn** Stables by providing goods and services or onboarding other merchants. - This allows new users to join the system without first acquiring Minima. Both paths lead to the same place: more Stables circulating in the economy and more merchants using them as money. ## 6. The Protocol Pillars ### 6.1 Coverage Fund - Receives **all transaction fees** generated by payments inside the circular economy. - Is the **yield and stability** engine of the protocol. - Strengthens the backing of the stablecoins and rewards its token holders. In stressed conditions it can tilt exposure toward xMinima to keep the system solvent while still letting everyday payments continue. ### 6.2 Liquidity Fund (xMinima / Minima) - Provides deep, continuous liquidity between **xMinima** and **Minima**. - Allows the market to discover the price of xMinima without disturbing the stability of the Stables layer. - Ensures that equity-side participants can enter and exit positions smoothly. ### 6.3 xMinima (Protocol Wealth) - The equity token of the protocol. - Absorbs volatility in the Minima collateral. - Represents the protocol's long-term wealth and governance power. Holders of xMinima take on structural risk and in return participate in upside as the network grows. ### 6.4 Treasury (Council Treasury) - Funded by **merchant listing fees** and other protocol revenues. - Acts as an arbitrageur and growth engine: - Can support Liquidity Fund positions. - Helps keep markets orderly around xMinima. ## 7. The Circular Economy Flow At the center is the **circular economy** where Stables are used for everyday payments: 1. Users mint or earn Stables. 2. They pay merchants for goods and services. 3. Merchants can hold Stables, convert them back to Minima, or use them to pay others. 4. Every transaction generates small fees that flow into the Coverage Fund. 5. The Coverage Fund and Liquidity Fund quietly maintain stability and liquidity in the background. This creates a loop where: - People and merchants enjoy instant, zero-fee payments in money that holds its value. - The protocol continuously reinforces its own stability and liquidity through fees and treasury management, instead of relying on a single discretionary treasury. ======================================== ## SOURCE FILE: charter_overview.md ======================================== # The Stables Constitution: Vision and Structure *Note: The full Constitution is currently in the drafting phase. This document outlines its conceptual framework and objective so the community can understand its eventual form.* ## Objective The Stables Constitution serves as the foundational legal and operational framework for the Stables ecosystem. It is designed to ensure a truly decentralized, censorship-resistant, and equitable banking solution built on the Minima network. Its primary purpose is to define the unchangeable rules of the network and to map out the "Transition Doctrine"—a roadmap for evolving from the current financial system into a sovereign, peer-to-peer monetary system. ## Form and Structure To remain effective and adaptable, the Constitution is intentionally separated into distinct layers. This separates high-level philosophical doctrines from rigid operational rules: 1. **The Charter:** This is the concise, formal, and primary constitutional document. It defines the unchangeable core principles (The Pillars) and the [Transition Doctrine (Stage -2 to Stage 3)](/Constitutional Charter). It represents the soul of the ecosystem. - Master File: `constitutional_charter.md` 2. **The Companion:** This supporting document contains internal guidelines, locked decisions, and operational definitions. It assists the Council in interpreting the Charter without bloating the main text. - Master File: `constitutional_companion.md` By keeping the core Charter minimal and structurally sound, it remains readable to everyone, ensuring the "Be your bank" philosophy is accessible to all. ======================================== ## SOURCE FILE: circular_economy_diagram.md ======================================== # Stables circular economy (diagram knowledge for StablesAgent) ## Authority and scope This document describes the **public concept map** at **https://stablescouncil.org/circulareconomy/**. It is **not** a literal balance sheet and **not** a substitute for locked protocol math. For **exact mechanics** (transaction fee formula, Coverage Ratio thresholds, cf token behaviour, mint/burn locks, and the rule that **xMinima receives no transaction-fee revenue**), StablesAgent must follow **`0_handshake/protocol_mechanics_spec.md`** and **`stables_master_reference.md`** §14. If any diagram-friendly phrase here could be read as contradicting those specs, **the specs win**. **Related public page (different map):** https://stablescouncil.org/bankingsystem/ **Terminology bridge:** Older public brain copy (for example **banking_system_overview.md**) refers to a **Liquidity Fund** on the Minima/xMinima liquidity axis. The circular economy page labels that axis **Arbitrage Fund** in Council vocabulary for this map. If a user asks, clarify: on **circulareconomy** use **Arbitrage Fund**; if they say **liquidity fund**, explain that wording differs across materials unless governance defines them as the same. ### Fund vocabulary (all valid concepts) **Coverage Fund**, **Arbitrage Fund**, and **Liquidity Fund** are all legitimate elements in Stables materials. They answer different questions: - **Coverage Fund:** In locked mechanics, the buffer tied to **cf** instruments, **transaction fee routing** to cf holders, stress paths between stable and xMinima exposure, and **Coverage Ratio** context. See **`protocol_mechanics_spec.md`** for exact formulas and rules. - **Arbitrage Fund:** On **circulareconomy**, the named box on the **Minima x xMinima** axis and the opportunistic, profit-seeking behaviour the page describes for that part of the map (not a peg guarantor). - **Liquidity Fund:** Wording still used in materials such as **banking_system_overview** for **deep Minima x xMinima liquidity** and orderly equity-side entry and exit, often described alongside **Council Treasury** support for market depth. StablesAgent should treat these as **compatible layers of description** (map labels, banking overview, locked ledger math). If a user collapses them into one box, explain the distinction and point to the right page or spec. **Do not** treat any of the three as invalid. --- ## What this is The Stables circular economy page is a **concept map**. It shows how external capital, on-chain economic activity, protocol treasuries, Stables (debt), xMinima (equity), merchant tooling, and two protocol funds relate in one picture. **Subtitle on the page:** How capital, Minima, Stables, xMinima, and protocol funds interact. --- ## How to read the arrows (legend) - **Bidirectional cyan arrows:** In this diagram, reserved for flows that represent **minting and burning mechanism relationships** (two-way coupling between the named boxes), not optional two-way trade in general. - **Bidirectional white (non-cyan) arrows:** Two-way links that are **not** labelled as mint/burn in the legend (for example treasury and market links, or operational two-way ties). - **One-way white arrows:** Directed flows such as spend/listing direction, fee routing, treasury allocation, or structure work feeding the economy. - **TF\*** on the diagram means **transaction fees** (also repeated in the page footnote: **TF: transaction fees**). --- ## Nodes (exact labels as on the page) ### External capital - **Subtitle:** From CEX/DEX (bridges) - **Meaning:** Capital and liquidity that can enter or leave via centralised or decentralised exchanges and bridge routes (off-chain / broader market interface). ### Economic Activity - **Subtitle:** Goods and services - **Meaning:** Real commerce and usage where Stables-related instruments matter as part of the economy (not a specific product screen). ### Community Treasury (Asset) - **Subtitle:** Minima - **Meaning:** Community-side treasury positioned in the diagram as an asset centre (the page explicitly tags it **(Asset)** in the title). It is the bridge in the picture between external capital and the Stables / xMinima layer. ### Merchants listing + Promo - **Subtitle:** Minima - **Meaning:** Merchant-facing listing and promotion paid or denominated in Minima in this schematic (discovery and marketing rail). ### Stables (Debt) - **Subtitle:** USDs, EURs, JPYs, + - **Meaning:** Stablecoin-style debt instruments in the protocol narrative (tickers shown as examples; **+** means other fiat pegs in the same family). ### xMinima (Equity) - **Subtitle:** Minima price risk takers - **Meaning:** Leveraged equity / risk-bearing side of the structure relative to Stables as debt: participants taking Minima price (and related) risk in return for equity-like exposure in this framing. ### Council Treasury - **Subtitle:** Minima - **Meaning:** Council-operated treasury in Minima for governance-directed uses in this diagram (distinct from **Community Treasury (Asset)**). ### Means of Exchange - **Subtitle:** Accepted by Merchants - **Meaning:** What merchants actually accept at checkout in the story of the map (the cash register side of Stables usage). ### TF\* - **Standalone label** (no subtitle on the box). - **Footnote:** TF = transaction fees. ### Coverage Fund - **Subtitles:** Stables <-> xMinima and USDscf, EURscf, JPYscf, + - **Meaning:** Fund whose role in the diagram is tied to the Stables / xMinima axis and coverage instruments (tickers shown as examples; **+** = other variants). ### Arbitrage Fund - **Subtitle:** Minima <-> xMinima - **Meaning:** Fund positioned on the Minima / xMinima axis for arbitrage-style activity. **Terminology note for the agent:** In Council copy on this page, this is **Arbitrage Fund**; do not conflate with a separate **liquidity fund** label if the user distinguishes them. ### Structure Dev - **Subtitle:** Audit, partners, etc - **Meaning:** Structural development spend: audits, partnerships, and similar infrastructure and credibility work. --- ## Connections (directionality as drawn) ### Top band (markets and activity) - **External capital <-> Economic Activity** (white, both ways): Outside capital and on-chain economic activity are mutually connected in the broad loop. ### Treasury and protocol core - **Community Treasury (Asset) <-> External capital** (white, both ways): Community treasury and external capital can move in both directions in this schematic (funding and recycling of exposure). - **Community Treasury (Asset) <-> Stables (Debt)** (cyan, both ways): Treated in the legend as part of **mint/burn mechanism coupling**. - **Community Treasury (Asset) <-> xMinima (Equity)** (cyan, both ways): Same **mint/burn** family of coupling in the diagram’s legend. ### Merchants and Council funding - **Economic Activity -> Merchants listing + Promo** (white, one way): Activity feeds listings/promo demand (the diagram does not show return flow from merchants listing back to Economic Activity). - **Merchants listing + Promo -> Council Treasury** (white, one way): Listing/promo flows into the Council Treasury side in this map. ### Stables rail and merchant acceptance - **Stables (Debt) -> Means of Exchange** (white, one way): Stables as debt instruments map into what functions as means of exchange in commerce. - **Stables (Debt) <-> Coverage Fund** (cyan, both ways): **Mint/burn / mechanism coupling** in the legend. - **Means of Exchange -> TF\* -> Coverage Fund** (white, one way through TF\*): Transaction fees are shown as a directed hop from means of exchange toward Coverage Fund (single logical path on the diagram). ### xMinima rail and funds - **xMinima (Equity) <-> Coverage Fund** (cyan, both ways): **Mint/burn / mechanism coupling** in the legend. - **xMinima (Equity) <-> Arbitrage Fund** (cyan, both ways): **Mint/burn / mechanism coupling** in the legend. ### Council treasury allocations - **Council Treasury -> Arbitrage Fund** (white, one way). - **Council Treasury -> Structure Dev** (white, one way). ### Funds and structure - **Arbitrage Fund <-> Structure Dev** (white, both ways): Bidirectional, but **not** cyan on the page: the diagram treats this as a two-way operational / funding relationship, **not** as one of the cyan mint/burn mechanism pairs. ### Closing the loop - **Structure Dev -> Economic Activity** (white, one way): Development and partnerships feed back into economic activity (better tooling, trust, integrations). ### Large outer curve - **Large outer curve** (white, with arrowhead along the path): A visual circularity spine linking the lower / outer part of the map back toward the upper Economic Activity region. Treat it as **narrative closure** of the loop, **not** a substitute for precise accounting. --- ## Explanatory prose on the page (substance to echo) The page text makes three main claims the agent should be able to restate faithfully: 1. **Coverage Fund** and **Arbitrage Fund** each pursue a **self-interested objective**: maximise profit within their own risk capacity. Together, that behaviour tends to push the system toward **equilibrium** and **peg maintenance**, without claiming either fund is a peg **guarantor**. 2. The peg is **not guaranteed** by the Coverage Fund or the arbitrage function. Those actors are **opportunistic**: they exploit market opportunities during a depeg, similar in spirit to how external capital behaves. 3. The strength of the structure is a **level playing field** where different actors can pursue their own financial goals, while the design should make their interaction support peg maintenance, described on the page as a **priority ordering** idea: **Community Treasury > Debt > leveraged equity > 0** (as written on the page; interpret as **informal structural intuition**, not a formal proof). For that to work in practice, the page lists **design requirements**: full transparency; tools for each actor to manage exposures and assess risk; visibility of the global positioning of the structure and its risks; and **low friction execution**: no unnecessary barriers and **no or minimal fees** (framing on the page; locked fee math for user transactions remains in **protocol_mechanics_spec.md**). --- ## Agent behaviour notes - Prefer **Arbitrage Fund** wording when explaining **this** map; if users say **liquidity fund**, clarify they are not the same label in Council vocabulary unless governance defines otherwise. - **Community Treasury (Asset)** vs **Council Treasury:** two treasuries in the diagram, different roles and links. - **Stables (Debt)** vs **xMinima (Equity):** debt vs equity framing in this illustration; xMinima subtitle is **Minima price risk takers**. - When asked **what the cyan arrow means**, answer with the **page legend**: bidirectional cyan = **minting and burning mechanism flows** (this diagram’s convention). - **TF\*** always expands to **transaction fees** when explaining the map. ======================================== ## SOURCE FILE: comprehensive_knowledge_base.md ======================================== # Stables Comprehensive Knowledge Base **Version: Foundation & Philosophy (Public)** This document synthesizes all public Stables documentation, community discussions, and architectural decisions into a single, comprehensive source of truth. It represents the deepest level of understanding of the Stables protocol, explicitly refined for precision. ## 1. The Core Philosophy: Why Minima? Stables is not another "crypto project." It is a decentralized banking system built exclusively on the **Minima blockchain**. Minima was chosen because it is the only network where every user runs a full validating and constructing node on their local device (phone or PC). This architecture eliminates miners, delegators, and centralized infrastructure providers, resulting in true censorship-resistance and absolute decentralization. "Stables exists because Minima exists, not the other way around. Minima's decentralization is not just a feature, it is a prerequisite for sovereign money." ## 2. The Four Pillars of True Stable Money (The Grok Challenge) A resilient stablecoin must achieve four nearly impossible feats. Stables is designed explicitly to survive these exact challenges: 1. **Perfect Economics:** Flawless peg stability and incentive design. Stables achieves this without fractional reserves by using massive over-collateralization of native Minima, backed by a 3-layer risk absorption structure. 2. **Battle-Tested Code:** Secure, audited, exploit-resistant software. Stables will heavily stress-test its MiniDapp on a testnet (using the test asset "Winiwa") before any real value is introduced. 3. **Massive Adoption:** Stablecoins need deep liquidity. Stables circumvents the "retail crypto" adoption hurdle by targeting Web2, non-crypto users—specifically merchants—as the entry point. 4. **Surviving Regulation & Crashes:** By building a 100% on-chain, non-custodial, decentralized structure governed by code without a corporate issuer, Stables minimizes regulatory attack vectors while remaining mathematically robust against flash crashes. ## 3. The Sovereign Monetary Architecture Stables is not a traditional DeFi project. It is a **floating collateralized synthetic monetary layer** built on Minima. It is designed with deterministic solvency, distributed equity absorption, and no discretionary emergency logic. ### A. Stablecoins (Floating, Not Defended) - **The Core Mechanic:** Stables does not "defend a peg" using centralized treasuries. It uses Floating Redemption. At all times, the backing ratio is visible: `Available Minima Assets / Stablecoin Liabilities`. - **The Merchant Peg:** If the backing ratio dips below 1, redemption floats with it. However, the system's stability relies on **The Merchant Network**. As long as local merchants continue to accept 1 USDs for $1 worth of real-world goods—because it guarantees them zero transaction fees and instant settlement—the network retains its utility value regardless of secondary market fluctuations in the Minima collateral. ### B. xMinima (Equity Absorption) - **The Structural Buffer:** xMinima represents the equity layer. The holders of xMinima voluntarily absorb the volatility of the Minima collateral. They provide the structural foundation that keeps the Stablecoin backing ratio robust in exchange for leveraged exposure to Minima's native growth. - **Proportional Voting:** Power resides with those who assume this structural risk: **1 xMinima token = 1 vote**. No tiers, no admin keys, no quadratic voting. ## 4. The Transition Doctrine (The Arc of Money) Stables does not claim to be the final form of human money. It is a necessary bridge from the centralised present to a sovereign future. We view monetary history as a sequence of stages: - **Stage −2 (Commodity Money):** Direct exchange and intermediary assets with intrinsic value (shells, salt, metals). Trust was local and mutual. - **Stage −1 (Sound Money/State Capture):** Standardisation of gold/silver coins. Trust shifted from community to state. Coercion entered via legal tender and mandated taxation. - **Stage 0 (Fiat/Centralised Control):** The current world. Money is issued by decree and managed by central banks. Individuals are assigned a currency by jurisdiction. Participation is mandatory; exclusion is common. - **Stage 1 (Stables - Sovereign Opt-In):** The current phase. Stables provides synthetic pegged assets (USDs, EURs, CADs, IRTs) so participants can opt-in to a sovereign network today while maintaining familiar pricing. Minima is listed alongside these as the native destination. - **Stage 2 (Minima-Native Economy):** As adoption deepens, participants begin pricing goods and services directly in Minima. The reliance on fiat-pegged bridges fades. Everyone becomes their bank on infrastructure they validate themselves. - **Stage 3 (The Circular Horizon):** A future state where monetary power is a fundamental human right. It recognises the right of every human to live with dignity and operates in service of the planet. **The StablesAgent's Role:** The Agent exists to facilitate Stage 1, guiding users and merchants across the bridge from Stage 0 to Stage 2. ### Communication & Pitch - **Target Audience:** Your mother, your uncle, the local shop owner. - **The Pitch:** We never use the words blockchain, crypto, or web3 in consumer marketing. We sell: "A better alternative to cash." "Zero transaction fees." "Instant settlement." "No chargebacks." - **Privacy:** In a world of centralized data leaks, Stables provides pseudonymous, safe financial dignity. ## 5. Funding & Community Rewards - **Zero VCs:** There will be no venture capital raises, no private sales, and no dedicated "Project Token" sold to extract value. - **The Core Team:** The initiators of the project are just kickstarting the protocol to eventually hand control completely to the decentralized Stables Council. The team will never touch protocol money. - **Airdrops & NFTs (Winiwa Testnet):** To heavily stress-test the system, Stables will run an epoch-based competition on its testnet. Users will start with "Winiwa" (fake Minima) and compete to end the epoch with the highest portfolio value. Winners and active questers will be rewarded with commemorative NFTs. These NFTs hold no protocol utility and grant no special rights; they are purely an attestation of early support. - **Socials Strategy:** Stables targets Web2 platforms aggressively (Instagram, Facebook) to reach normal users who feel disenfranchised by the traditional banking system. ## 6. Architecture Precedents Stables is not inventing novel, untested mechanics. It is taking battle-tested economic models (such as those pioneered by MoneyOnChain on RSK) and executing them on a superior base-layer (Minima) with a superior UI/UX, pushing it fully into retail utility instead of keeping it in the DeFi niche. ## 7. The Stables Banking System: How the Mechanic Works This section gives the Agent a clean, step‑by‑step description of how the Stables banking system works in practice, mirroring the public "Our Banking System" presentation. ### 7.1 The Three Main Actors - **People:** Buyers, savers and senders who hold and use Stables day‑to‑day. - **Merchants:** Sellers, providers and recipients of payments who agree to accept Stables at a 1:1 value with local pricing (for example, 1 USDs for 1 dollar worth of goods). - **The Protocol:** The on‑chain logic that mints and burns stablecoins, manages the Coverage Fund and Liquidity Fund and routes fees. ### 7.2 The Money Layer (Stablecoins) - **Stables:** USDs, EURs, JPYs and other synthetic currencies that are designed to hold a stable value and be used as everyday money. - **Financial Entry (Mint / Burn):** People can lock Minima into the protocol to mint new stablecoins, and they can burn stablecoins to redeem Minima. This is the financial on‑ramp into the system. - **Work Entry (Earn):** People and merchants can also earn Stables directly by providing goods and services or by onboarding other merchants. This is the work‑based on‑ramp. In both cases, the result is the same: more users and merchants hold and use Stables as their money, and payments move directly between them with zero transaction fees. ### 7.3 The Internal Protocol Mechanics - **Coverage Fund:** All transaction fees generated by the network flow into the Coverage Fund. It is the yield‑bearing buffer that strengthens the backing of the stablecoins and rewards the holders of the coverage fund tokens. When coverage is high, it can hold mostly stablecoins. When coverage is stressed, it can gradually tilt toward xMinima to absorb volatility while keeping the system solvent. - **Liquidity Fund (xMinima / Minima):** A dedicated pool that provides deep, continuous liquidity between xMinima and Minima. It ensures that participants who take the equity side (xMinima) can always enter and exit positions without destabilizing the money layer that normal users rely on. - **xMinima (Equity Layer):** The equity token of the protocol. xMinima holders voluntarily absorb price swings in the Minima collateral in exchange for long‑term upside and a direct role in governance. They sit structurally “behind” the stablecoin holders, taking the first hit when the market moves against the collateral but benefiting most when the network grows. - **Council Treasury:** Funded by merchant listing and related protocol fees. The Treasury can be used to seed and maintain Liquidity Fund positions so that there is always a healthy bid and ask for xMinima without depending on external market makers. ### 7.4 How a Typical Flow Works 1. A user locks Minima into the protocol and mints USDs. 2. The user pays a merchant in USDs for real‑world goods and services. The merchant can either keep the USDs as savings or burn them to redeem Minima. 3. Every payment generates tiny fees that flow automatically to the Coverage Fund instead of to banks or card networks. 4. The Coverage Fund strengthens the overall balance sheet and rewards its token holders, while the Council Treasury builds up resources from merchant listing fees. 5. The Treasury and Liquidity Fund together ensure that xMinima remains liquid so that equity‑side participants can come and go, while ordinary users just experience instant, fee‑less payments in money that holds its value. The core mechanic is therefore simple: **People and merchants use Stables as day‑to‑day money, while the Coverage Fund, Liquidity Fund and xMinima layer quietly absorb volatility and route fees in the background so that the system stays solvent and resilient over time.** ## 8. The Ambassador Program (The 16 Big Mac® Economy) The Stables Ambassador program is a professional, incentivized network designed to grow the merchant base in a Fair & Global manner. It is a "Ruled by Code" economy that rewards mentorship while protecting the treasury. ### 8.1 The Economic Core (V0.0.01) - **Universal Anchor Fee:** 16 Big Mac® (Independent Registration). - **Mentored Registration Fee:** 15 Big Mac® (1 BM Discount for using an Ambassador). - **Active Reward (Ambassador):** 8 Big Mac® (Fixed). - **Mentor Reward (Trainer):** 1 Big Mac®. - **Council Share:** 6-16 Big Mac® (Treasury Growth). - **Fairness Anchor:** All fees are pegged to the global **Big Mac Index**. - **Settlement:** Paid and settled in any token of Stables (USDs, EURs, CADs, etc.), Minima, or xMinima. ### 8.2 The Merchant's Choice - **Why Stables?** Secure, Pseudonymous, Unstoppable. Zero middleman fees and instant settlement. - **Why Listing?** Visibility on the global map, "Verified" status, and discoverability. - **Wait, is Listing Mandatory?** No. Stables is an open protocol. Any merchant can accept Stables for free without being listed. Listing is a professional services choice. ### 8.3 The Integrity & Investment Principle - **100% Investment:** The 16 Big Mac® fee is not a payment; it is a 100% investment into the Stables infrastructure, owned collectively by its participants and managed by the Council Treasury. - **Risk Disclosure:** Stables is a pioneer journey. While sovereignty (node/keys) is the ultimate shield, early ambassadors acknowledge the lack of protocol track record. ### 8.4 Technical Guardrail: The Shield Principle The system is mathematically balanced so that "self-onboarding" (bypassing an ambassador) is always more expensive than joining a mentored hub. This ensures the human layer (Ambassadors) is protected by the ledger's logic. **The StablesAgent's Role (Ambassador Support):** The Agent provides 24/7 technical and strategic support for Ambassadors, helping them manage their Hubs and merchant campaigns. ## 9. Stables Academy (Education Layer, Draft) Stables Academy is a practical education layer for users and merchants who want to manage sovereign banking safely. - **Purpose:** improve real-world operational confidence topic by topic, starting with security. - **Quiz model (current prototype):** each attempt draws 10 questions from a larger question bank, each with 3 options. - **Pass logic:** no single "perfect score" requirement. Pass requires a minimum threshold (6/10) and mandatory critical questions correct. - **Progression logic:** retake cool-down, best score retained. - **Community learning feedback:** users can optionally authorize anonymized demographic + score contribution to a public learning database used to improve communication priorities. - **Recognition:** successful completion unlocks a lightweight certificate and social sharing. - **Ambassador path direction:** completing all Academy core topics is being positioned as an onboarding prerequisite for Ambassador status once the full topic set is live. ## 10. Public website: where it lives and how it ships The Council public site (**https://stablescouncil.org/**, GitHub Pages **`StablesCouncil/stablescouncil.github.io`**) is **authored in the Stables monorepo**, not by editing the Pages repo by hand as the primary workflow. - **Sandbox:** **`1_development/stream_1_app/task_stablescouncil_github_io/`** with **`webpages/`** (HTML and **`dapp/`** mirror), **`static/`** (shared CSS, brand, **`CNAME`**), and a **generated** **`site/`** tree that matches the live URL layout. - **Build:** **`npm run sync:site`** runs **`tools/sync-site.mjs`**: merge **`static/`** into **`site/`**, then copy **`webpages/`** to the mapped outputs (for example home → **`site/index.html`**, links hub → **`site/links.html`**, Playing Field → **`site/playing_field.html`**, directory routes for circular economy and banking system, **`site/dapp/`** for the MiniDapp web tree). - **Ship:** copy **contents** of **`site/`** to the **root** of the **`stablescouncil.github.io`** working tree, commit, push **`main`**. **`CNAME`** for **`stablescouncil.org`** must stay consistent with GitHub Pages settings. - **Local disk preview:** pages may include a **`file:`** protocol helper that rewrites asset paths and reloads stylesheets and scripts so shared **`static/`** assets and controls still load when opening HTML from the filesystem. - **Full detail for the Agent:** **`github_pages_website_engineering.md`** in this brain base; the monorepo **handover** table and status live in **`handover_document.md`** at the repo root. - **Public UI buttons:** **`website_button_hierarchy.md`** (how **`btn-primary`** and **`btn-secondary`** must be used); canonical markup in **`0_handshake/web_component_spec.md`** (COMPONENTS → Buttons). ======================================== ## SOURCE FILE: core_definitions.md ======================================== # Stables Core Definitions This document serves as the absolute source of truth for the Agent regarding specific definitions, mechanics, and terminology within the Stables ecosystem. ## xMinima Token - **Definition:** xMinima IS the equity token of the Stables platform. - **Purpose:** It exists to allow for the governance of the Stables protocol via the Minima blockchain. - **Voting Power:** Governance is strictly proportional: **1 xMinima token = 1 vote**. "No special voting power" means there are no privileged tiers, no delegated boosts, no admin keys, and no quadratic voting. A holder with 10 tokens has 10 votes; a holder with 1,000 tokens has 1,000 votes. It is a pure, flat equity structure where power is derived exclusively from the amount of risk (collateral) managed. ## The Multiplicator - **Definition:** An advanced mechanism designed for participants who want to do more than just pay. - **Purpose:** It allows users to amplify their exposure and actively support the resilience and stability of the entire Stables network. ======================================== ## SOURCE FILE: council_minima_devtools.md ======================================== # Council Minima dev tools (public website) ## Minima Onchain Watch **URL:** `https://stablescouncil.org/onchain-watch.html` **What it is:** A public Council devtool page with two main features: 1. **Holdings chart** — enter any Minima address (or pick a saved / preset address) and query its historical balance (Minima) and UTXO count over a chosen date range. Results appear as a dual-axis line chart (Balance on left axis, UTXO count on right). The chart reads from the Council archive MySQL database via the API at `https://agent.stablescouncil.org`. Displays live blockchain block height and the latest DB block height so you can see how current the data is. A **Download CSV** button exports the queried data. - **Range presets:** 1 month, 3 months, 1 year, All, Custom dates. - **Interval options:** DAY, WEEK, MONTH, QUARTER, YEAR. - **Saved addresses:** Users can save labelled addresses locally in the browser for quick re-query. - **Default / example address:** MEXC hot wallet `0x4AD25252814256BEDDF7EA6F0CF75E48FC10E8D11FE3FC70551BB427A2BBA84A`. 2. **Minima archive node download** — a direct download button for the latest full Minima archive export (`archive_latest.raw.dat`) served from the Council VPS (`http://140.82.36.166:8080/`). The export is updated daily by the StablesCouncil VPS. The panel shows the **latest block**, **export timestamp**, and **file size** for the current export. 3. **Discord channel link** — links directly to the on-chain analysis thread in the Stables Discord (`https://discord.com/channels/1461269219009232997/1493173250497450066`) for discussion and sharing of on-chain analysis. **Who it is for:** Community members, archive node operators, and analysts who want to inspect Minima address holdings history or download a full archive to run their own archive node. **How to use it (holdings):** 1. Open `https://stablescouncil.org/onchain-watch.html`. 2. Paste a Minima address (starts with `0x`) in the address field, or pick a saved address from the dropdown. 3. Choose a date range preset (or set custom dates) and an interval. 4. Click **Run query** — the chart updates with balance and UTXO count. 5. Click **Download CSV** to export the data. **How to use it (archive download):** 1. On the same page, scroll to the **Minima archive node** panel. 2. Click **Download** to get `archive_latest.raw.dat` from the Council VPS. 3. Use the file to initialise or resync a Minima archive node. --- ## Other devtools URLs (legacy / hub) Canonical public URLs (custom domain `stablescouncil.org`): - **Hub:** `https://stablescouncil.org/devtools/` — lists archive chain exports for archive nodes and the Minima address holdings explorer. - **Archive downloads (devtools path):** `https://stablescouncil.org/devtools/minima-archive/` — same `archive_*.raw.dat` files; large files served from Council VPS. - **Holdings query (devtools path):** `https://stablescouncil.org/devtools/minima-query/` — older URL for the holdings chart. - **Onchain Watch (canonical, current):** `https://stablescouncil.org/onchain-watch.html` — this is the current, canonical single-page version combining holdings chart + archive download + Discord link. **All links page:** Under the **Council** section there is a single row, **Minima Onchain Watch** (chart icon), pointing to `onchain-watch.html`. **Site chrome:** The page uses `links-page-body has-site-rail deck-chrome-page` body classes — same header/footer/rail chrome as other document deck pages. Right-hand rail nav menu includes Full presentation, Minima dev tools, All links. StablesAgent floating button is present. **Governance runbooks** (Stables monorepo, not on the public site): operator export, MySQL read-only access, and archive scheduling live under `2_current/stream_3_governance/prod_minima_archive_admin/`. ======================================== ## SOURCE FILE: github_pages_website_engineering.md ======================================== # Stables public website: engineering and operations **Audience:** StablesAgent, operators, and contributors who need **how the site is built, previewed, and shipped**, not marketing copy. **Companion docs:** User-facing messaging stays in **`website_presentation.md`**. Protocol and economics stay in **`protocol_mechanics_spec.md`**, **`stables_master_reference.md`**, and **`comprehensive_knowledge_base.md`**. For the **authoritative file map and ship checklist** in the monorepo, use **`handover_document.md`** at the Stables repository root (Status block holds the latest **GitHub Pages** commit reference when maintained). --- ## 1. Live site and repos - **Public site (custom domain):** `https://stablescouncil.org/` - **GitHub Pages origin:** `https://stablescouncil.github.io/` (same deployment; custom domain is **`stablescouncil.org`** via **`CNAME`** in the Pages repo root). - **Pages repository:** `StablesCouncil/stablescouncil.github.io` on **`main`**. Only the **root** of that repo is what GitHub Pages serves. - **Council handshake task name for authoring:** **`task_stablescouncil_github_io`** (sandbox under **`1_development/stream_1_app/`**). --- ## 2. Canonical authoring layout (monorepo) Authoring spans **two** sibling folders under **`1_development/stream_1_app/`** (paths relative to Stables repo root): **`1_development/stream_1_app/task_stablescouncil_github_io/`** (static pages + build) and **`1_development/stream_1_app/dapp/`** (MiniDapp only). | Layer | Path | Role | |-------|------|------| | **Human page sources** | **`task_stablescouncil_github_io/webpages/pages//index.html`** | One folder per route; slugs include **`index`**, **`links`**, **`playing_field`**, **`qr-code`**, **`ambassadorsprogramdesc`**, **`circulareconomy`**, **`bankingsystem`**. | | **MiniDapp web mirror** | **`1_development/stream_1_app/dapp/`** | Same folder layout as **`https://stablescouncil.org/dapp/`** (**`1-showcase/`**, **`2-demo/`**, **`3-test/`**, **`4-prod/`**, optional **`v00…/`** redirect stubs, …). | | **Shared shipped assets** | **`static/`** | Shared CSS (including **`stables.css`** pattern from Council spec), **`assets/`** (e.g. **`site-chrome.css`**), brand files, **`CNAME`**, images used across pages. | | **Built tree (generated)** | **`site/`** | **Only** output that matches the live URL layout. **Do not hand-edit** files here except **`site/README.md`** (tracked). Everything else under **`site/`** is produced by sync and is typically gitignored. | | **Sync tool** | **`tools/sync-site.mjs`** | Implements the merge and copy rules. | There is **no** duplicate **`index.html`** or **`dapp/`** at the **task folder root**; the root holds **`webpages/`**, **`static/`**, **`site/`**, and tooling. **Eleventy:** templates may live under **`src/`** with **`npm run build`**; the **hand-maintained** public pages use **`npm run sync:site`** for the tree that ships to Pages. --- ## 3. Route map (source → live URL → `site/` output) | Source | Typical live URL | Output under **`site/`** | |--------|------------------|---------------------------| | **`webpages/pages/index/`** | **`/`** | **`index.html`** | | **`webpages/pages/links/`** | **`/links.html`** | **`links.html`** | | **`devtools/`** (at **Pages repo root**, hand-maintained until synced from monorepo) | **`/devtools/`**, **`/devtools/minima-archive/`**, **`/devtools/minima-query/`** | same paths under **`site/`** if copied by your ship process | | **`webpages/pages/playing_field/`** | **`/playing_field.html`** | **`playing_field.html`** | | **`webpages/pages/qr-code/`** | **`/qr-code.html`** | **`qr-code.html`** | | **`webpages/pages/ambassadorsprogramdesc/`** | **`/ambassadorsprogramdesc.html`** | **`ambassadorsprogramdesc.html`** | | **`webpages/pages/circulareconomy/`** | **`/circulareconomy/`** | **`circulareconomy/`** (directory) | | **`webpages/pages/bankingsystem/`** | **`/bankingsystem/`** | **`bankingsystem/`** (directory) | | **`stream_1_app/dapp/`** | **`/dapp/...`** | **`dapp/`** (copied by **`sync-site`** from **`../dapp/`**) | **Minima devtools pages** use the same **document deck** pattern as **`qr-code.html`** and **`playing_field.html`**: link **`../stables.css`** (or **`../../stables.css`** in nested routes), **`assets/site-chrome.css`**, **`assets/site-map-nav.css`**, **`assets/devtools-pages.css`**, then the standard **`site-chrome-header`**, right rail (globe menu includes **Full presentation**, **Minima dev tools**, **All links**), **`main.site-chrome-main.site-chrome-main--document`**, minimal footer, **`site-rail` scripts**, and the **StablesAgent** FAB block (same inline widget as other deck pages). **Document page uniformity (mandatory for new deck pages):** Inside **`main`**, the first content wrapper MUST be **`div.container`** (optionally with a scoped inner class such as **`devtools-hub-inner`**). The first child inside that container MUST be **`div.title-block`** containing exactly one **`h1`** and, when needed, a single lede paragraph with class **`subtitle`** (not ad hoc **`h1`** margins or a custom **`lede`** class). Section blocks below use normal panels or page-specific CSS scoped under the inner wrapper. **`assets/site-chrome.css`** applies the standard header-to-title spacing and gradient **`h1`** to **`main.site-chrome-main--document > .container > .title-block:first-child`** for **`body.links-page-body.deck-chrome-page`**. Hub and subpages use **`data-site-map-role`** values **`devtools-hub`**, **`devtools-archive`**, and **`devtools-query`** (see **`assets/site-map-nav.js`**). Add new deck **`body`** classes to the **`--links-stack-max: 960px`** group in **`site-chrome.css`** when the page should match document stack width. Brain summary for StablesAgent: **`council_minima_devtools.md`**. Detail tables also live in **`task_stablescouncil_github_io/webpages/README.md`** and **`handover_document.md`**. --- ## 4. Build command From **`task_stablescouncil_github_io/`**: ```bash npm run sync:site ``` This runs **`node tools/sync-site.mjs`**, which **merges `static/` into `site/` first**, then copies **`webpages/`** into **`site/`** according to the route map. Always run sync after changing **`webpages/`** or **`static/`** before previewing the full site or copying to the Pages repo. --- ## 5. Ship workflow (GitHub Pages) 1. Edit **`webpages/`** and **`static/`** (and **`tools/`** if the pipeline changes). 2. Run **`npm run sync:site`** so **`site/`** is complete and consistent. 3. Copy **only the contents** of **`site/`** (not the parent sandbox folder name) into the **root** of the **`stablescouncil.github.io`** working tree, then commit and push **`main`**. **Monorepo mirror:** A full clone with embedded git metadata may live under **`3_archive/stream_1_app/task_archived_nested_repo_stablescouncil_github_io_2026-04-12/stablescouncil.github.io/`** with **`_embedded_git/`**; the archive **`README.md`** documents **`git --git-dir`** / **`--work-tree`** usage. Operators may instead use a standalone clone of **`StablesCouncil/stablescouncil.github.io`** and copy **`site/`** the same way. **Custom domain:** Repo root **`CNAME`** must match GitHub Pages custom domain settings for **`stablescouncil.org`**. --- ## 6. Local preview and `file://` behaviour Opening **`index.html` (and other pages) directly from disk** uses the **`file:`** protocol. Relative paths that assume **`https://stablescouncil.org/`** may fail unless adjusted. **Implemented pattern:** Main pages under **`webpages/pages/.../`** include a small script that runs on **`DOMContentLoaded`**: when the protocol is **`file:`**, it rewrites asset URLs (for example toward **`../../../static/`**), and **re-clones** linked stylesheets and scripts so CSS and JS **reload** after href/src changes. Agent and rail controls that depend on correct asset paths should therefore work under local file preview as well as on the live site. **Shared chrome:** Global footer/header styling and spacing may be centralized in **`static/assets/site-chrome.css`** (linked from pages after sync). Design tokens and button classes follow **`0_handshake/web_component_spec.md`** and Council **`stables.css`** conventions. For StablesAgent and RAG, the **button hierarchy** (one **`btn-primary`** per group, **`btn-secondary`** for the rest, no primary for inactive states) is summarized in **`website_button_hierarchy.md`** in this brain base; full recipes stay in **`web_component_spec.md`**. --- ## 7. Content and chrome policy (handover) **Agreed constraint:** Do **not** change core copy, headings, body text, link targets, link order, diagrams, or interactive behaviour inside existing main content regions unless Council explicitly lifts the freeze. Safe changes: **layout wrappers**, **global header/footer**, **spacing**, **shared styles**, **encoding fixes** for existing characters, **asset path** fixes, and **pipeline** improvements. **Objective:** One **uniform chrome** (header + footer + shared CSS) so all nodes **feel** like one site. **Template first:** **`links`** hub was chosen as the first shell template, then the same pattern rolls to other pages. --- ## 8. StablesAgent on the site The public site exposes StablesAgent (FAB / avatar / chat entry points depending on page). **Knowledge** for answers comes from the Council brain pipeline (Markdown brain base → ingestion → **`llms.txt`** / vector store); see **`website_presentation.md`** for the public **`llms.txt`** URL and Telegram / X entry points. When operators **update this engineering document** or other brain Markdown, they must promote from sandbox **`1_development/stream_3_governance/task_stablesagent-brain-base/`** to **`2_current/stream_3_governance/prod_stablesagent-brain-base/`** per handshake, then run the ingestion script in **`2_current/stream_3_governance/task_x_agent_node/`** (for example **`node ingest_knowledge.js`**) so **`llms.txt`** and embeddings stay current. --- ## 9. Quick operator checklist 1. Edit **`webpages/`** or **`static/`** in **`task_stablescouncil_github_io`**. 2. Run **`npm run sync:site`**. 3. Spot-check **`site/`** (or open synced HTML with the **`file:`** helper in place). 4. Copy **`site/`** contents to **`stablescouncil.github.io`** repo root; commit; push **`main`**. 5. Confirm **`CNAME`** and HTTPS when changing domain-related files. 6. If brain docs changed: promote **`task_stablesagent-brain-base`** → **`prod_stablesagent-brain-base`**, then ingest. --- ## 10. Related files in the Stables repo (for humans and agents) - **`handover_document.md`** — Status, seven-node table, ship workflow, archive path. - **`task_stablescouncil_github_io/webpages/README.md`** — Page and **`dapp`** map, sync command. - **`task_stablescouncil_github_io/static/README.md`** — Static assets policy. - **`task_stablescouncil_github_io/site/README.md`** — What **`site/`** is and that it is generated. - **`0_handshake/handshake.md`**, **`0_handshake/web_component_spec.md`**, **`0_handshake/session_map.md`** — Governance, UI tokens, task matrix. ======================================== ## SOURCE FILE: minidapp_showcase_app.md ======================================== # Stables MiniDapp — Showcase (public) vs active dev line *Last updated: 2026-04-01.* This section is for StablesAgent and external AIs when users ask about the **Stables app preview** (Showcase / MiniDapp), how to open it, and how feedback works. ## 0. Version map (do not conflate) | Line | Version | Meaning | |------|---------|--------| | **Public web + published zip** | **v0.01.01** | What visitors get at **https://stablescouncil.org/dapp/** and **`Stables_v0.01.01.mds.zip`** in Pages **`dapp/1-showcase/latest-version/`** until Council publishes a newer zip and redeploys web. (Former root **`dapp/latest-version/`** redirect stub **retired 2026-04-16**; see **`0_handshake/minidapp_version.md`** for current paths.) | | **Frozen source snapshot** | **v0.01.01** | `3_archive/stream_1_app/prod_stables_app_v0.01.01/` (see `FROZEN.md` there). | | **Active repo development** | **v0.01.02** | `1_development/stream_1_app/prod_stables_app_v0.01.02/` per `0_handshake/minidapp_version.md`. Changes are logged in **`CHANGELOG.md`** in that folder. | If the user asks “what version is live on the web?” answer **0.01.01** until the site and **`1-showcase/latest-version`** zip are updated. If they ask “what are you building now?” answer **0.01.02** in the development folder. ## 1. What it is - The Showcase MiniDapp is a **preview**: wallet-style UI, demos, StablesAgent hooks, and **More → Feedback** (structured public submissions). Not a final production release. - **Frozen older UIs** (v0.2.x, etc.) live in archive folders; **do not** describe them as current unless the user asks about history. ## 2. Where to open it - **Web (Showcase):** **https://stablescouncil.org/dapp/** (also under the Council GitHub Pages site). Marketing CTA **Test the showcase** on stablescouncil.org. - **Minima node:** Install the **published** package from GitHub **`dapp/1-showcase/latest-version/`** (filename matches the published version, e.g. **`Stables_v0.01.01.mds.zip`** while that remains latest). Zip root = app contents, not a nested folder (`build/README.md` in the active dev folder). ## 3. MiniDapp list: write mode vs read mode - On a **Minima node**, each MiniDapp can run in **read mode** or **write mode**. - For Stables, **write mode** is required for features that use the node network: **StablesAgent**, **structured feedback** (HTTP POST via the node), and similar. If those fail, ask them to set Stables to **write mode** (not read mode). ## 4. Structured feedback (More → Feedback) - Posts **public** JSON to the Council feedback API (default **`https://agent.stablescouncil.org/api/feedback`**, configurable via `FEEDBACK_SUBMIT_URL` / `runtime-config`). **Web (browser)** typically uses **`fetch`**; **node** uses **`MDS.net.POST`**. Consent required; no secrets. - **Community:** **https://t.me/stablescommunity** and the public GitHub feedback folder linked from the app. ## 5. Known issues (Showcase) - **Some mobile nodes:** structured feedback may not complete on the node; **web** path has been reported working. **Workaround:** Telegram or GitHub; engineering continues to debug node delivery. ## 6. Mint xWiniwa chart (Showcase) - Location: **Mint** tab → **Mint xWiniwa**, **below** the **Mint xWiniwa** button (not above the form). - **Three lines:** - **Winiwa · USD (cyan):** about the last **365 days** of spot in **USD**. Data source is **CoinGecko** `market_chart` for the **minima** id (shown in-app as **Winiwa** in this test phase; thinned points for drawing). - **xWiniwa · USD (purple):** demo strip **Winiwa_USD × leverage** at each time step (same leverage series as the green line). **Not** on-chain xWiniwa. - **Leverage (green, right axis):** derived from **headline coverage ratio** as **CR% / (CR% − 100%)** (example: **130%** → **130 / 30 ≈ 4.33×**). The chart sweeps **interpolated** values from in-app **`CR_HIST_DATA`** along the time axis and pins the **last** point to the live Treasury **CR** (`#protocolCRBig`). **Not** on-chain. **Current leverage** on the Mint form and **xWiniwa** demo pricing use the **same** formula from the current CR headline. - **Hover or drag (touch):** vertical crosshair and a small panel with **calendar date** plus **Winiwa USD**, **xWiniwa USD**, and **leverage** at the nearest sample. - If the chart shows **Unavailable.**, the network or API rate limit blocked the fetch (retry later; **MDS.net.GET** on node when `MDS` is present). ## 7. StablesAgent inside the app - With **`MDS`**, StablesAgent may open in the **system browser** per `runtime-config` / in-app behaviour. ## 8. One-line answers - **“Where is the Showcase?”** → **https://stablescouncil.org/dapp/**. - **“Which zip matches what’s published?”** → Check **`dapp/1-showcase/latest-version/`** on the Pages repo (currently **0.01.01** until a new zip is published). - **“Feedback won’t send on my phone node.”** → **Write mode**, **online**; else **Telegram** (**t.me/stablescommunity**). ======================================== ## SOURCE FILE: website_button_hierarchy.md ======================================== # Website and MiniDapp: button hierarchy (public UI law) **Audience:** StablesAgent, contributors, and anyone answering questions about Council HTML or the MiniDapp shell. **Canonical spec (monorepo):** **`0_handshake/web_component_spec.md`**, section **COMPONENTS → Buttons**, including **Button hierarchy (mandatory)**. **`0_handshake/handshake.md`** §1 states the same obligation in brief. ## What the Agent must remember 1. **Classes only** from Council **`stables.css`**: **`btn btn-primary`** or **`btn btn-secondary`** inside **`
`**. Do not invent local gradients or ghost styles for actions. 2. **`btn-primary`** (cyan-to-purple gradient): **one** main call to action per obvious visual group (hero row, card footer, modal, panel). Users must see a single clear “do this”. 3. **`btn-secondary`** (dark fill, cyan border): supporting actions (cancel, back, optional path, second choice). Use for anything that is not that single main step. 4. **Inactive or “coming soon only”** actions must **not** use **`btn-primary`**. Use **`btn-secondary`**, plain text, **`disabled`**, or omit the control. Do not keep gradient styling while meaning “unavailable”. 5. **Two primaries** side by side is allowed only when two **equal** commitments are intentional and noted in the change or PR; default is **at most one primary** per group. 6. **GitHub Pages deck pages** and the **MiniDapp shell** follow the same rule. Deck chrome and **`main`** layout: **`github_pages_website_engineering.md`**. When in doubt, read **`web_component_spec.md`** in the monorepo before suggesting markup. ======================================== ## SOURCE FILE: website_presentation.md ======================================== # Stables Official Website Presentation *Source: stablescouncil.github.io* **Technical reference (build, ship, routes, local preview):** see **`github_pages_website_engineering.md`** in this brain base. It is the canonical operations summary for agents and operators. ## Be your bank Money that is truly yours. Secure, Pseudonymous and Unstoppable. Built on Minima. ## Pay instantly. Own completely. Experience money that moves as fast as a message. No banks to freeze your account. No hidden fees. Just a simple, powerful wallet that gives you 100% control over your assets. - 100% Self-Custody: Only you have the keys. - Day-to-day ready: Fast, cheap, and simple. - Stables: Designed to hold its value. ## Settled in seconds. Connect directly. Stop waiting days for your money. With Stables, payments are confirmed and settled in seconds. Build a direct relationship with your customers without intermediaries taking a cut. Perfect for modern commerce, from local shops to global services. ## The Multiplicator. A new way to participate in the stability of the ecosystem. Use the Multiplicator to amplify your exposure and support the network's resilience. Advanced tools for those who want to do more than just pay. ## The Core Concept Let's be our banking system. The Network of Everybody's Bank. ## Stables Showcase MiniDapp (preview) - The public site **https://stablescouncil.org/** uses a primary call-to-action **Test the showcase**, which opens **https://stablescouncil.org/dapp/** (Showcase web entry). A full-page **All Links** control may appear lower on the page; the hero area focuses on the single showcase CTA. - **Published** web and zip versions follow **`dapp/1-showcase/latest-version/`** on GitHub Pages. **Version policy:** **`0_handshake/minidapp_version.md`**. **Showcase packaging note:** this folder’s **`minidapp_showcase_app.md`**. On a **Minima node**, install the versioned **`.mds.zip`** from that folder and set the MiniDapp to **write mode** (not read mode) for StablesAgent and structured feedback. ## StablesAgent and the Knowledge Base StablesAgent is the official AI assistant for the Stables community. It can be reached in the following ways: - In the Stables Community Telegram group, in the dedicated 4-StablesAgent thread, by mentioning @StablesAgentBot followed by a question. - In a private conversation with @StablesAgentBot directly. - On X at https://x.com/StablesCouncil Anyone who prefers to use their own AI (ChatGPT, Grok, Claude, or any other tool) can access the full Stables knowledge base using this direct link (same URL as the StablesAgent web chat footer): https://raw.githubusercontent.com/StablesCouncil/stables-agent/main/brain/llms.txt To use it, paste that link into any AI and say: "Learn everything in this file." The AI will then be able to answer any question about Stables in detail and in any language. The knowledge base source files and generated rollup are published under the **`brain/`** folder in the public **StablesCouncil/stables-agent** repository; interaction logs may be published per that repo’s README.