Add an "Assets on Stellar" reference page, auto-sourced from a public asset registry (incl. permission status)

[mmazco]

Summary

Add a reference page to the docs that lists the assets live on Stellar Mainnet — stablecoins and tokenized real-world assets — with their issuer, asset class, contract (SAC) ID, and permission status (permissionless vs. permissioned). The page should be generated from a canonical, machine-readable source so it stays current automatically rather than being hand-maintained.

Problem

There is no page on developers.stellar.org that answers "what assets are actually live on Stellar, and can a developer build with them?" Today:

• Only USDC/Circle is meaningfully represented in the docs.
• The growing set of real-world assets (tokenized treasuries, funds, local-currency stablecoins, and issuers such as Franklin Templeton, WisdomTree, Ondo, Spiko, Centrifuge, Etherfuse, Mercado Bitcoin, and others) is not discoverable from the docs.
• Developers — and increasingly AI agents that read the docs — can't tell which assets are permissionless (freely transferable/holdable on-chain) vs. permissioned (holder allowlist / KYC / jurisdiction-gated). That distinction determines what they can actually build.

This is a discoverability + fragmentation gap: the information exists across separate surfaces, none of them linked from the docs.

What exists today

• Stellar Lab → Smart contracts → "Known assets" (public): a curated registry of ~163 assets with { assetCode, entity, assetClass, SAC contract }. Good for discovery ("what's onchain"), but it has no permission/authorization field.
• An internal asset registry maintained by the data team that additionally classifies each asset's permission status. This is the authoritative source for permissioning, but it is not currently published in a public, docs-consumable form.

Proposal

1. Add an "Assets on Stellar" page under Tokens (docs/tokens/), linked from the Tokens nav.
2. Generate its contents at build time from the public Lab RWA asset-list endpoint (Create an endpoint for RWA asset list laboratory-backend#81; see dependency) so it auto-updates.
3. For each asset, show: asset code, issuer/company, asset class (stablecoin / RWA / etc.), SAC contract ID, and permission status.
4. Include a short explainer of what "permissionless vs. permissioned" means for a builder (see note below), and how to verify any asset independently (Horizon issuer flags + the issuer's own eligibility/KYC terms).

Dependency (why this is an issue, not yet a PR)

The docs build is static (Docusaurus) and public, so it can't authenticate to the internal data source directly. The canonical data lives in the data warehouse (Hubble/BigQuery dbt_references.recognized_assets, built by the internal dbt project) — a static public site can't query that.

The clean path is to consume a public API endpoint that fronts this data. That endpoint is already being scoped in stellar/laboratory-backend#81 ("Create an endpoint for RWA asset list"). Once it exists, this docs page can be generated from it at build time (a Docusaurus plugin / CI fetch — avoids CORS) so it stays current automatically.

Ask on that endpoint (tracked in #81): include at minimum asset_code, issuer, contract_id, asset_class, permission_type; expose it publicly (build-time fetchable); keep internal-only fields out. SEP-42 Stellar Asset List is a good target payload format.

Interim (optional quick win, separate PR)

Before the feed exists, we can ship a lightweight version now: an "Assets on Stellar" page that links to the Lab "Known assets" list for discovery and documents the permission-verification method (Horizon flags + issuer terms), without reproducing the internal classification. This can be swapped for the generated table once the public feed lands.

Acceptance criteria

• "Assets on Stellar" page exists under Tokens and is linked in the sidebar/nav.
• Page content is generated from a public feed (no hand-maintained list) — or, interim, links Lab + documents the verification method.
• Each asset shows class, contract ID, and permission status.
• Page explains permissionless vs. permissioned and how to verify independently.

Note on the "permissionless" definition (food for thought)

_Probably one for the data team. It'd help downstream if permission_type is explicit about "permissionless = freely transferable/holdable on-chain" (no issuer-enforced holder allowlist) vs. acquisition gating (a token that transfers freely on-chain but still requires KYC/eligibility to mint/redeem — e.g., some tokenized treasuries). Noting it here so the field's meaning stays consistent wherever it's surfaced.

References

• Upstream endpoint: Create an endpoint for RWA asset list laboratory-backend#81 — "Create an endpoint for RWA asset list" (this page consumes it)
• SEP-42 Stellar Asset List format: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0042.md
• Stellar Lab "Known assets" (public discovery source)
• Existing related docs: docs/tokens/anatomy-of-an-asset.mdx, docs/learn/fundamentals/anchors.mdx

[JFWooten4]

This is somewhat addressed in SEP-42, as you cited. I would be really careful with this implementation because it can get really centralized (and hence gatekept) really fast.¹ The developer docs are a source of truth for downstream services like Raven, which can act as a first introduction to network development.

This responsibility should not be taken lightly, and the inclusion of certain assets or uses can lock in certain service providers. Specifically, Raven talks a lot about PaltaLabs' work, which can create a substantial barrier to innovation through difficulty gaining market adoption due to a lack of developer recognition. I like what you have going on the Lab, but I think it would be better to incentivize the use of block explorers and SEP-1 metadata in the developer docs.

Footnotes

1. It's already a private database, which is not unlike CUSIP number assignment. ↩

[ElliotFriend]

Having awareness of which tokens are available to developers is a very likely pain point for new folks to the ecosystem. Providing some guidance on that seems like an easy win to make the documentation better.

But, I think @JFWooten4 has a pretty good point here. Us "blessing" a list of specific assets as even quasi-canonical or official is not the role we want the docs to play. And we've worked hard to keep the docs as neutral as we can over time.

It might be a good option to share links/references to some sources that contain SEP-42 lists, or something similar. Stellar expert has a service where they have a directory of SEP-42 lists. We could also include the registry from Aha as a source.