Welcome to the official home repository for Documentation for the Stellar network.
Contributions are more than welcome! Thank you! 🎉
Before diving in, please read our Stellar Contribution Guide for details on contributing to Stellar's various repositories. Please take special note of the code of conduct. Then read this repo's CONTRIBUTING.md for how we work and the conventions we hold the content to.
Our documentation site is built with Mintlify. The content is written in MDX, which is Markdown with components mixed in. Even if you're unfamiliar with Markdown, do not fear! It's easy to learn, and you can always help fix typos, spelling, and broken links, too.
Important
Contributed here before October 2026? The site moved from Docusaurus to
Mintlify, and a few long-standing habits changed. The one you'll notice most:
we now write internal links as root-relative paths with no extension
([fees](/docs/learn/fundamentals/fees-resource-limits-metering)), not
relative .mdx paths. MIGRATING.md
has the full "we used to do X, now do Y" list.
You can contribute to the docs in several ways:
- See something that needs to be fixed in the docs, like an error in the code or a typo? File a pull request (PR) proposing to correct the error;
- Think there is helpful content missing from the docs, like a specific how-to guide or piece of explanatory content? File an issue explaining what you’d like to see (be sure to search existing issues to avoid duplication);
- Have an idea that could make the docs better, like a structural change or a new section idea? File an issue explaining what you’d like to see (these will be added to the Ideas section on the Dev Docs board for discussion);
- Want to complete an existing issue? Search through the issues to find something to work on! Issues without an assignee and labeled as a “Good First Issue” or with “Help Wanted” are great places to start! Once you’ve selected an issue to work on, file a PR with your proposed fix.
No matter what you contribute, whether a PR or an issue, you can expect to receive a response from docs maintainers within one week.
- PRs need to be reviewed and approved before merging. Look for either an approval or a follow-up question.
- Issues will be prioritized, labeled, and assigned (if possible). You can check the status of your issue on the Dev Docs board. The status of issues according to the column is:
- Ideas: these issues are being actively discussed. Ideas will either be discarded or repurposed into an actionable issue and added to the queue within three weeks.
- Backlog: these issues are not prioritized or actively being worked on.
- To Do: these issues are prioritized and will be worked on soon.
- In Progress: these issues are currently being worked on.
- Blocked: these issues are being worked on but are blocked for some reason and need attention.
- Done: these issues have been completed and can be closed.
If you have questions, feel free to ask in the Stellar Developer Discord.
To work on the documentation, you'll need:
- Node.js (v24, or higher): see https://nodejs.org/en/download/package-manager for details for your system
- pnpm: e.g.,
corepack enable pnpm
Once the prerequisites are installed, run:
git clone https://github.com/stellar/stellar-docs
cd stellar-docs
pnpm install
pnpm startpnpm start runs the Mintlify development server (mint dev) at
http://localhost:3000, and reloads as you save changes. The first run takes a
little longer, because it downloads Mintlify's preview client.
Before you open a PR, fix formatting and run the checks CI runs:
pnpm format:mdx # fix formatting (and the blank lines around component tags)
pnpm check # formatting, component padding, and `mint validate`
pnpm check:links # broken links, anchors, redirects, and snippetsA pre-commit hook runs the formatting checks for you. Mintlify also builds a
preview deployment for PRs to main, and a bot comments on the PR with the
link. For PRs from forks, a maintainer approves the preview first.
docs/contains the documentation pages. If you're contributing to the content, rather than the site itself, this is where you want to be.- A page's URL is its path:
docs/learn/fundamentals/lumens.mdxis served at/docs/learn/fundamentals/lumens. A folder's landing page is itsindex.mdx. - All filenames use dashes for spaces, not spaces or underscores.
- A page's URL is its path:
meetings/contains the developer meeting notes, laid out asmeetings/YYYY/MM/DD.mdx, and the changelog-style index page (meetings/index.mdx).docs.jsonis the site configuration: theme, navigation (the sidebar and tabs), SEO, integrations, and so on. Every page needs an entry innavigationto appear in the sidebar.redirects.jsonholds the redirect rules (referenced fromdocs.json). If you find a broken link out in the wilds of the internet, and there's no way for it to be changed, a redirect could be a useful tool. (Note our aim isn't to completely avoid 404 pages for a user. That would be impossible and impractical. Redirects are evaluated on a case-by-case basis.)snippets/contains reusable content (.mdx) and custom components (.jsx) that pages import. Snippets are never published as pages.assets/andimg/contain images and other static files. Files are served from their path in the repo, soassets/guestbook/foo.pngis at/assets/guestbook/foo.png.openapi/andopenrpc/contain the API specifications that the Horizon, Anchor Platform, Stellar Disbursement Platform, and Stellar RPC reference pages are built from. See CONTRIBUTING.md.style.css,sds-*.css, and the.jsfiles at the root are site-wide styling and scripts. Mintlify loads every.cssand.jsfile in the repo on every page..mintignorelists files Mintlify should never publish (drafts, tooling, and contributor docs).scripts/andtools/contain repository tooling.
If you're unfamiliar with Markdown, there are loads of good tutorials and cheat sheets out there. Check out some of these resources to get a handle on the basics:
Pages use Mintlify's built-in components, such as callouts (<Note>, <Tip>,
<Warning>), <Tabs>, <CodeGroup>, <Accordion>, <Steps>, and
<Card>. No imports are needed. The Mintlify components
documentation covers every component and its options.
Leave a blank line after every opening component tag and before every closing
one. Without it, a closing tag right after a list can get swallowed into the
last list item, and the build fails. pnpm format:mdx adds the blank lines for
you. For example,
<Note>
Callouts don't take a title. Put a **bold first line** in the body instead.
</Note>When you want the same example in more than one language, use <CodeGroup>.
Each fenced code block gets a title right after its language, which becomes the
tab label. If you're only showing a single language, stick with a normal
fenced code block.
<CodeGroup>
```js JavaScript
// create a completely new and unique pair of keys
// see more about KeyPair objects: https://stellar.github.io/js-stellar-sdk/Keypair.html
const pair = StellarSdk.Keypair.random();
pair.secret();
// SAV76USXIJOBMEQXPANUOQM6F5LIOTLPDIDVRJBFFE2MDJXG24TAPUU7
pair.publicKey();
// GCFXHS4GXL6BVUCXBWXGTITROWLVYXQKQLF4YH5O5JT3YZXCYPAFBJZB
```
```python Python
# stellar-sdk >= 2.0.0 required
# create a completely new and unique pair of keys
# see more about KeyPair objects: https://stellar-sdk.readthedocs.io/en/latest/api.html#keypair
from stellar_sdk import Keypair
pair = Keypair.random()
print(f"Secret: {pair.secret}")
# Secret: SCMDRX7A7OVRPAGXLUVRNIYTWBLCS54OV7UH2TF5URSG4B4JQMUADCYU
print(f"Public Key: {pair.public_key}")
# Public Key: GAG7SXULMNWCW6LX42JKZOZRA2JJXQT23LYY32OXA6XECUQG7RZTQJHO
```
</CodeGroup>Code groups with the same tab titles stay in sync across a page, so a reader who picks Python sees Python everywhere. See Mintlify's code block documentation for titles, line highlighting, and other options.
Remember that this is a community; we build together! 🫱🏻🫲🏽 Our code of conduct is here and our Privacy Policy is here.