مستندات دارامرجع فنیتصمیمها
این صفحه فقط به انگلیسی موجود است.
Owner decisions, 2026-10-31
Answers the owner gave to the open questions that blocked the launch, and what each changed. Earlier questions and
their status: ../architecture/DECISIONS.md.
| Question | Decision | Implemented as |
|---|---|---|
| Q-07 human signers | One human signer, the same person for the issuer and the cold Treasury | ISSUER_SIGNERS / TREASURY_SIGNERS take 1–10 keys; thresholds follow from the count (ceremony.Quorum). One signer: issuer 1 / 10 / 10, cold 10 / 10 / 10 (TestSingleHumanSigner on local Stellar) |
| Q-07 how the human key is held | Software key on a laptop | Procedure and hardening: ../security/KEY_MANAGEMENT.md §1a |
| Q-07 / Q-12 online keys | Vault Transit (HashiCorp Vault or OpenBao, self-hosted) | SIGNER_BACKEND=vault, deploy/vault/setup-transit.sh, make vault-test (real OpenBao; a Vault-signed transaction applied on local Stellar) |
| Q-08 volume | Up to about 1 order per second at peak | 8 AUTO and 3 GOV channels, XLM float sizing: ../operations/ISSUER_OPERATIONS.md §1 "Sizing for the launch volume" |
| Q-13 assets | GOLD only; the domain is chosen later | Production template creates GOLD only; home_domain stays a setting (launch checklist) |
| Q-10 history | Self-hosted Galexie lake on local disk | deploy/datalake/, BACKFILL_DATASTORE_TYPE=Filesystem, make datalake-test (lake ledgers match our node hash for hash) |
| Alert receivers | Decide later | deploy/observability/alertmanager/production.yml.example (Telegram, email or webhook, secrets in files), checked by make observability-check |
Accepted risks
The owner chose these knowing the alternatives (3 people, 2-of-3; a hardware key with a sealed backup):
- One person controls issuance, burn, clawback and the cold Treasury. Nobody else has to agree: the platform's four-eyes approvals in the console still apply before a proposal exists, but on-chain one signature completes it. A mistaken or coerced signature cannot be stopped by a second signer.
- No key loss tolerance. With master weight 0 and one signer, losing that key means nobody can ever issue, burn or claw back the asset again, nor change its signers. Customers' balances stay where they are and trading continues on the hot float, but the asset would have to be re-issued under a new issuer (a migration).
- A software key on a laptop. Malware or theft of an unlocked laptop could sign unbacked issuance or move the
cold Treasury. Detection: the indexer flags any on-chain movement without a platform intent
(
DaraUnexplainedTokenMovement, trading stops); the platform's reconciliation flags supply above backing. Neither undoes a completed transaction.
Moving to more signers later is a signer change (../operations/ISSUER_OPERATIONS.md §2): add the new keys and
raise the thresholds in one SetOptions signed by the current signer, then update ISSUER_SIGNERS /
TREASURY_SIGNERS and restart. No code change.