Dara DocsReferenceStellar
Asset Model Evaluation (Stage 5)
Decision: A. Classic Stellar asset with native issuer multisig (Q-02, accepted 2026-10-29). This document records why.
Options:
- A. Classic asset. Issuer account + distribution (Treasury) accounts; flags
AUTH_REQUIRED | AUTH_REVOCABLE | AUTH_CLAWBACK_ENABLED; authority through native signers and thresholds. - B. Classic asset + Stellar Asset Contract (SAC) with a custom admin contract. Same asset and supply. The SAC admin is a role-gated Soroban contract (cap, minter role, pause); the issuer is locked after
set_admin(custom-sac-adminguide). - C. Soroban RWA token. OpenZeppelin
stellar-contractsv0.8.0tokens/rwa(T-REX/ERC-3643 style), a contract token with its own supply.
| Criterion | A. Classic | B. Classic + SAC admin contract | C. Soroban RWA token |
|---|---|---|---|
| Issuer controls | Native: issue = Payment from issuer (medium), freeze = SetTrustLineFlags (low), clawback (medium), config (SetOptions high) | Through the contract only, after the issuer is locked; before locking, the issuer can bypass the contract | Contract roles |
| Supply cap | Not on-chain. Backend check + human co-signers on every issuance | On-chain in the admin contract | On-chain (Capped) |
| Authorization / KYC | AUTH_REQUIRED trustlines, authorized by a low-weight signer | set_authorized through the contract | Identity registry + claims |
| Freeze | Revoke authorization (whole trustline) | Same, via contract | Address and partial freeze |
| Clawback | Native, only on trustlines created after the flag | Via SAC clawback | Forced transfer, recovery |
| Pause | No native pause; per account (revoke) or by not signing | Contract can pause mint; cannot pause Classic payments between holders | Native pause |
| Role separation | Thresholds: low / medium / high. Enough to separate KYC authorization from issuance (baseline A8). Cannot separate issuance from clawback (both medium) | Arbitrary roles | Arbitrary roles |
| Programmability | None | Mint/clawback/auth logic only; holder transfers remain Classic | Full |
| Wallet / exchange support | Universal | Universal (still a Classic asset) | Soroban-aware wallets only |
| DEX | Yes (we do not use it) | Yes | No |
| Contract risk | None | One custom contract (audit required) | Library + our integration (audit required) |
| Upgrade risk | None | Contract upgrade authority must be governed; the issuer lock is irreversible | Contract upgrades governed |
| Operational complexity | Lowest: signer ceremony + signature collection | Medium: contract deploy, upgrade governance, Soroban fees and footprints | Highest |
| Transaction cost | 100 stroops/op base | Soroban resource fees for admin actions | Soroban fees for every transfer |
| Throughput | 1,000 Classic ops per ledger network-wide | Same for transfers | Soroban limits; parallel execution |
| Auditability | Classic events (CAP-67) + ledger entries | Same + contract events | Contract events |
| Future integrations | SAC can be deployed later for the same asset (deterministic ID), so contracts and DeFi stay possible | Ready | Ready |
Why A for the MVP
- Customer trading moves existing Treasury inventory and never issues. Issuance is rare and is already approved by two staff (four-eyes). Making the human issuer signers co-sign each issuance gives a cap enforced by independent people, without contract risk.
- The authorization signer that runs daily KYC is a low-weight online key. With weights in
security/AUTHORITY_MATRIX.mdit cannot issue, claw back or change signers. - No Soroban contract means no external contract audit, no upgrade authority and no contract fees on the money path.
- A → B is a non-breaking migration: deploy the SAC,
set_adminto the audited admin contract, then lock the issuer. The asset identity (code + issuer) and every trustline stay the same. A → C would be a new asset and a migration.
What A gives up (accepted risks)
| Risk | Mitigation |
|---|---|
| No on-chain supply cap: enough colluding or compromised issuer signers can issue without backing | Multisig across independent people and hardware keys; the backend never holds an issuance-capable key; the indexer raises a CRITICAL incident for any issuance without a matching approved supply_operations row; reconciliation checks supply ≤ approved backing each run |
| Issuance and clawback share the medium threshold | Both need the same human quorum; clawback is also four-eyes in the app |
| No global pause | The trading gate stops all platform activity. On-chain, transfers already need two authorized trustlines, and every holder is one of our custodial accounts, so no one else can move tokens |
When to revisit (move to B)
- External withdrawals to non-platform wallets (Q-09) are enabled and an on-chain cap becomes a market expectation.
- Regulators or auditors require code-enforced issuance limits.
- Contract integrations (vaults, DeFi) need the SAC.