Dara DocsIssuer and Treasury operations
Procedures that change who controls the platform's Stellar accounts. They are performed by the human signers with
their own tools and keys; the platform never holds those keys. What the platform does is verify: the binary
refuses to start unless every account in the manifest has exactly the expected signers, weights, thresholds, flags
and master weight 0 (app.VerifyAccounts), and asset activation and every reconciliation run re-check the issuer.
Each procedure is four-eyes: a written request (what, why, the exact operations) approved by a second person, then the on-chain thresholds. Keep the request, the transaction hashes and the verification output in the change record.
1. Account ceremony (Testnet, Mainnet)
dara bootstrap-local does this on the local network only. On a real network the operators do it, with the same
layouts (backend/internal/ceremony/local.go; ../security/AUTHORITY_MATRIX.md §1):
| Account | Signers (weight) | Thresholds low / med / high | Flags, trustlines |
|---|---|---|---|
| ISSUER (one per asset) | H1…Hn (10), AUTH (1) | 1 / 10·a / 10·change — launch (one signer): 1 / 10 / 10; 4 signers: 1 / 20 / 30 | AUTH_REQUIRED, AUTH_REVOCABLE, AUTH_CLAWBACK_ENABLED; home_domain = the landing domain |
| TREASURY_COLD | T1…Tn (10) | 10 / 10·a / 10·change — launch: 10 / 10 / 10 | Trustline to every asset |
| TREASURY_HOT | HOT (10), T1…Tn (10) | 10 / 10 / 20 | Trustline to every asset |
| RESERVE_SPONSOR | SPONSOR (10), T1…Tn (10) | 10 / 10 / 20 | — |
| FUNDER | FUNDER (10), T1…Tn (10) | 10 / 10 / 20 | — |
| CHANNEL ×N (AUTO pool), ×3+ (GOV pool) | CHANNEL (1) | 1 / 1 / 1 | — |
Steps:
- Collect public keys only: the human signers' keys (launch: the one signer's key, used as both H1 and T1;
../security/KEY_MANAGEMENT.md§1a), and the platform's online keys (dara keyswithSIGNER_BACKEND=vaultprints AUTH, HOT, SPONSOR, FUNDER, CHANNEL, CUSTODY afterdeploy/vault/setup-transit.sh). - Issuers first (the Treasury trustlines need them): for each asset, generate a throwaway key on an offline
machine; fund the account with a
CreateAccountfrom the operator's XLM funding account; in one transaction signed by the throwaway key: set the three flags, sethome_domain, add the signers, set thresholds and master weight 0. The throwaway key is then useless; destroy it. - TREASURY_COLD, TREASURY_HOT (with
ChangeTrustto every asset), RESERVE_SPONSOR, FUNDER and the channels the same way. Fund the sponsor and funder with the XLM float (../stellar/XLM_RESERVE_AND_FEE_MODEL.md). - Authorize the Treasury trustlines: done by the platform (AUTH key) when the asset's issuer is registered.
- Write the manifest (
deployments/<network>.json: network, passphrase,indexer_start_ledgerat or before the first ceremony transaction, every account) and setISSUER_SIGNERS,TREASURY_SIGNERS. - Start the platform: startup verification must pass. Register each asset's issuer in the console, set the unit
definition, publish the
stellar.toml(served automatically from the landing domain), activate: activation re-verifies the issuer and fetches thestellar.toml. - Record the creation transaction hashes and the asset identity in
../stellar/ASSET_REGISTRY.md.
GOV channels: each proposal awaiting human signatures holds one until signed or expired (up to 24 h). Create one per proposal that may be pending at the same time (at least three), so an urgent clawback never waits behind an unsigned issuance. AUTO channels: about one settlement per channel per ledger; size them for the peak order rate.
Sizing for the launch volume (Q-08: up to about 1 order per second at peak)
| Item | Rule | Launch value |
|---|---|---|
| AUTO channels | peak orders/s × ledger time (≈ 5 s) × 1.5 headroom | 8 |
| GOV channels | one per proposal that may be pending at once | 3 |
| Channel XLM | CHANNEL_MIN_BALANCE_STROOPS (5 XLM) each; the funder tops them up | 11 × 10 XLM at creation |
| FUNDER float | fees at 1 tx/s ≈ 86 400 tx/day × 100–1 000 stroops ≈ 0.9–9 XLM/day, plus channel top-ups | 500 XLM; alert DaraFunderXLMLow below 3× the 100 XLM gate minimum |
| RESERVE_SPONSOR float | 1.5 XLM per customer with GOLD (account 2 × 0.5 base reserve, trustline 0.5) | 1.5 XLM × expected customers in the first quarter, + 20% |
If peak volume grows beyond about 1.5 orders/s, add AUTO channels: create and fund them, add them to the manifest, and restart (startup verifies and registers them). The GOLD hot float target and ceiling and the daily BUY/SELL limits are per-asset settings in the admin console, set by two operators from the expected daily sell volume (a float of about one day's net sales).
Checks before go-live (../stellar/ASSET_CONFIGURATION.md "Ceremony verification"): removing any single signer
still leaves every threshold reachable; no other holder; zero supply before the first issuance; no SAC balance,
pool or claimable balance for the asset.
2. Signer or threshold change
Used to rotate a key (../security/KEY_MANAGEMENT.md) or replace a person.
- Request: the account, the current configuration (from Dara Scan's issuer view or the account entry), the proposed configuration, the reason. Approved by a second person.
- Build the
SetOptionstransaction offline (Stellar CLI or Lab), source = the account, with the change and a boundedmaxTime. Each required signer verifies the decoded operations and the network before signing. Issuer and COLD signer changes need their high threshold (launch: the one signer; 4 signers: 3 of 4); the online accounts need their online key and one T, or two T. - Submit; then update configuration (
ISSUER_SIGNERS/TREASURY_SIGNERSor the signer backend) and restart: startup verification must pass with the new configuration. - The indexer will report the change as
UNEXPECTED_AUTHORITY_CHANGE(no platform intent asked for it). Resolve that incident with the change record's reference: this is the deliberate double check.
3. Adding an asset later
A new asset needs its issuer ceremony (§1 step 2) and Treasury trustlines on COLD and HOT. HOT's ChangeTrust can
be signed by the platform's HOT key; COLD's needs two T signers (built offline as in §2, or with the
platform's proposal flow once it supports ChangeTrust — not implemented yet). Then register, define, activate.
4. Emergency: lost or compromised human key
Lost: the remaining signers replace it (§2); thresholds stay reachable with three of four. Compromised: the same,
immediately, and treat any action it took as an incident (INCIDENT_RESPONSE.md).