Goal
Move the authoritative issuer/asset side of the current .well-known/stellar.toml out of blocktransfer/website and into issuers.info, with a proposed transfer-agent field and tighter IssuerLink integration.
The intent is for the website to stop being the source of truth for issuer compliance/network state. Instead, issuer state should be maintained with the issuer data and then surfaced into the SEP-1 document.
Why separate this from the website?
The contemplated migration scheme during the first exam was an automated link between the disclosure platform and the company website. The WK TOML is also the one file I specifically called out for special Git treatment.
That separation matters more as we scale the commercial/open-source sales and frontend side of the Syndicate's registered organization. Right now the same repository permissions cover two substantially different kinds of work:
- compliance and functional Stellar-network disclosures; and
- marketing, sales, and frontend copy.
Those are different skill sets and should not need the same write path or repository permissions. Moving issuer-owned TOML state into issuers.info gives us a cleaner access-control boundary.
Proposed direction
-
Make issuers.info the source of issuer/asset TOML state. IssuerLink should be able to update the underlying issuer record and materialize the relevant TOML from that live state instead of requiring edits to the website repository.
-
Preserve SEP-1 discovery semantics. SEP-1 still discovers the file at https://DOMAIN/.well-known/stellar.toml, so this needs an explicit domain/home_domain design rather than merely relocating the file path. See the current SEP-1 location requirement:
https://github.com/stellar/stellar-protocol/blob/265d64edc87627707941a31bd12798b7fdeb47d1/ecosystem/sep-0001.md#L34-L41
-
Add a transfer-agent field. A candidate TAD3 extension could look something like:
transfer_agent = "blocktransfer.com"
The exact name, value format, and placement still need to be decided. This would be a TAD3 extension; it is not currently a SEP-1 field.
-
Make SEP-1 status the authoritative live-state signal. The current TOML has both an info_href into issuers.info and a local status = "live" value:
|
info_href = "https://api.issuers.info/1846058" |
|
is_asset_anchored = true |
|
is_unlimited = true |
|
issuer = "GDRM3MK6KMHSYIT4E2AG2S2LWTDBJNYXE4H72C7YTTRWOWX5ZBECFWO7" |
|
issuer_cik = 1846058 |
|
issuer_name = "BlockTrans Syndicate" |
|
name = "BlockTransfer Common Shares" |
|
par = 0 |
|
par_fiat = "USD" |
|
regulated = true |
|
seniority = 1 |
|
status = "live" |
SEP-1 already defines status as live, dead, test, or private:
https://github.com/stellar/stellar-protocol/blob/265d64edc87627707941a31bd12798b7fdeb47d1/ecosystem/sep-0001.md#L147-L164
With tighter IssuerLink integration, we should be able to publish the current state directly into the TOML instead of requiring consumers to follow the current info_href endpoint to determine it. SEP-14 is useful prior art for dynamic asset metadata at scale, but this proposal is specifically about keeping lifecycle state in the SEP-1 document while generating that document from live issuer data.
-
Tie this into issuer-based treasury wallets. This fits the broader move toward issuer-based treasury wallets rather than a servicing-agent-centric asset model. It also opens the door to a uniform list of TAD3 assets independent of servicing agent. That has pros and cons, but the data model should make it possible.
Follow-on: TAD3.info relationship discovery
The bigger next step is frontend TAD3.info explorer logic that recognizes signers on the issuer root account.
If the issuer relationship can be derived from the issuer root's signer configuration, the explorer can cryptographically infer that relationship instead of relying on the current board-resolution-based equivalent, which requires centralized trust.
That would give us a path toward:
issuer root
-> signer relationship
-> transfer agent / TAD3 servicing relationship
-> issuer + asset discovery
and make the resulting TAD3 asset index less dependent on any one servicing agent's website or manually maintained disclosure layer.
Implementation questions
- What should the issuers.info domain/
home_domain shape be so SEP-1 discovery remains clean?
- Should
transfer_agent live per currency/asset, per issuer, or in both places?
- What identifier should the field contain: domain, Stellar account, TAD3 identifier, or another stable identifier?
- Which IssuerLink state changes should regenerate/publish the TOML?
- How should signer-based relationship discovery coexist with an explicit
transfer_agent declaration?
- During migration, which data remains in
blocktransfer.com/.well-known/stellar.toml, and which data becomes generated from issuers.info?
Goal
Move the authoritative issuer/asset side of the current
.well-known/stellar.tomlout ofblocktransfer/websiteand into issuers.info, with a proposed transfer-agent field and tighter IssuerLink integration.The intent is for the website to stop being the source of truth for issuer compliance/network state. Instead, issuer state should be maintained with the issuer data and then surfaced into the SEP-1 document.
Why separate this from the website?
The contemplated migration scheme during the first exam was an automated link between the disclosure platform and the company website. The WK TOML is also the one file I specifically called out for special Git treatment.
That separation matters more as we scale the commercial/open-source sales and frontend side of the Syndicate's registered organization. Right now the same repository permissions cover two substantially different kinds of work:
Those are different skill sets and should not need the same write path or repository permissions. Moving issuer-owned TOML state into issuers.info gives us a cleaner access-control boundary.
Proposed direction
Make issuers.info the source of issuer/asset TOML state. IssuerLink should be able to update the underlying issuer record and materialize the relevant TOML from that live state instead of requiring edits to the website repository.
Preserve SEP-1 discovery semantics. SEP-1 still discovers the file at
https://DOMAIN/.well-known/stellar.toml, so this needs an explicit domain/home_domaindesign rather than merely relocating the file path. See the current SEP-1 location requirement:https://github.com/stellar/stellar-protocol/blob/265d64edc87627707941a31bd12798b7fdeb47d1/ecosystem/sep-0001.md#L34-L41
Add a transfer-agent field. A candidate TAD3 extension could look something like:
The exact name, value format, and placement still need to be decided. This would be a TAD3 extension; it is not currently a SEP-1 field.
Make SEP-1
statusthe authoritative live-state signal. The current TOML has both aninfo_hrefinto issuers.info and a localstatus = "live"value:website/.well-known/stellar.toml
Lines 120 to 131 in 6b14a0f
SEP-1 already defines
statusaslive,dead,test, orprivate:https://github.com/stellar/stellar-protocol/blob/265d64edc87627707941a31bd12798b7fdeb47d1/ecosystem/sep-0001.md#L147-L164
With tighter IssuerLink integration, we should be able to publish the current state directly into the TOML instead of requiring consumers to follow the current
info_hrefendpoint to determine it. SEP-14 is useful prior art for dynamic asset metadata at scale, but this proposal is specifically about keeping lifecycle state in the SEP-1 document while generating that document from live issuer data.Tie this into issuer-based treasury wallets. This fits the broader move toward issuer-based treasury wallets rather than a servicing-agent-centric asset model. It also opens the door to a uniform list of TAD3 assets independent of servicing agent. That has pros and cons, but the data model should make it possible.
Follow-on: TAD3.info relationship discovery
The bigger next step is frontend TAD3.info explorer logic that recognizes signers on the issuer root account.
If the issuer relationship can be derived from the issuer root's signer configuration, the explorer can cryptographically infer that relationship instead of relying on the current board-resolution-based equivalent, which requires centralized trust.
That would give us a path toward:
and make the resulting TAD3 asset index less dependent on any one servicing agent's website or manually maintained disclosure layer.
Implementation questions
home_domainshape be so SEP-1 discovery remains clean?transfer_agentlive per currency/asset, per issuer, or in both places?transfer_agentdeclaration?blocktransfer.com/.well-known/stellar.toml, and which data becomes generated from issuers.info?