Treasury|Treasury Docs

The Basics

Treasury is organized around a small set of public, community, and operational surfaces. These docs explain how those surfaces fit together so users and operators know where to find information, where to ask for help, and how to keep workflows consistent.

In a nutshell

  • Main site - The public entry point for Treasury at donut-treasury.com.
  • Treasury Discord - The live community and support surface.
  • Docs - The long-form reference layer for concepts, workflows, standards, and handoffs.
  • Operational systems - Treasury services, bots, automations, transcripts, and tooling that support the community and internal workflows.
  • Runbooks - Practical instructions for keeping repeated workflows consistent.

Main site

The main Treasury site is the public-facing home for the project. Use it when someone needs the official Treasury entry point, brand context, or high-level navigation.

Discord

The Treasury Discord is the primary live support and community surface. It is the right destination for questions, coordination, ticket handoffs, and issue escalation.

When docs point users to support, they should point to Discord unless a specific product workflow says otherwise.

Docs

Treasury Docs is the stable reference layer. Use it for information that needs to be discoverable, linkable, and consistent across support conversations.

Good docs pages should:

  • Define the workflow or concept clearly.
  • Explain who owns the workflow.
  • State what the user or operator should do next.
  • Link to Discord when live help is needed.

Operational systems

Treasury has multiple operational systems behind the scenes. These include Discord-facing services, support workflows, transcript tooling, automation workers, and shared internal utilities.

The docs should keep those boundaries clear. A page should explain the user-facing workflow without implying that separate systems are the same thing.

Runbooks

Runbooks are practical operating documents. They should be used for repeated tasks, escalation handling, launch checks, incident response, and support procedures.

A strong runbook should include:

  • Trigger conditions.
  • Required context.
  • Exact steps.
  • Escalation path.
  • Expected end state.

What next?