مستندات دارا
مرجع فنیاستلار
این صفحه فقط به انگلیسی موجود است.

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-admin guide).
  • C. Soroban RWA token. OpenZeppelin stellar-contracts v0.8.0 tokens/rwa (T-REX/ERC-3643 style), a contract token with its own supply.
CriterionA. ClassicB. Classic + SAC admin contractC. Soroban RWA token
Issuer controlsNative: 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 contractContract roles
Supply capNot on-chain. Backend check + human co-signers on every issuanceOn-chain in the admin contractOn-chain (Capped)
Authorization / KYCAUTH_REQUIRED trustlines, authorized by a low-weight signerset_authorized through the contractIdentity registry + claims
FreezeRevoke authorization (whole trustline)Same, via contractAddress and partial freeze
ClawbackNative, only on trustlines created after the flagVia SAC clawbackForced transfer, recovery
PauseNo native pause; per account (revoke) or by not signingContract can pause mint; cannot pause Classic payments between holdersNative pause
Role separationThresholds: low / medium / high. Enough to separate KYC authorization from issuance (baseline A8). Cannot separate issuance from clawback (both medium)Arbitrary rolesArbitrary roles
ProgrammabilityNoneMint/clawback/auth logic only; holder transfers remain ClassicFull
Wallet / exchange supportUniversalUniversal (still a Classic asset)Soroban-aware wallets only
DEXYes (we do not use it)YesNo
Contract riskNoneOne custom contract (audit required)Library + our integration (audit required)
Upgrade riskNoneContract upgrade authority must be governed; the issuer lock is irreversibleContract upgrades governed
Operational complexityLowest: signer ceremony + signature collectionMedium: contract deploy, upgrade governance, Soroban fees and footprintsHighest
Transaction cost100 stroops/op baseSoroban resource fees for admin actionsSoroban fees for every transfer
Throughput1,000 Classic ops per ledger network-wideSame for transfersSoroban limits; parallel execution
AuditabilityClassic events (CAP-67) + ledger entriesSame + contract eventsContract events
Future integrationsSAC can be deployed later for the same asset (deterministic ID), so contracts and DeFi stay possibleReadyReady

Why A for the MVP

  1. 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.
  2. The authorization signer that runs daily KYC is a low-weight online key. With weights in security/AUTHORITY_MATRIX.md it cannot issue, claw back or change signers.
  3. No Soroban contract means no external contract audit, no upgrade authority and no contract fees on the money path.
  4. A → B is a non-breaking migration: deploy the SAC, set_admin to 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)

RiskMitigation
No on-chain supply cap: enough colluding or compromised issuer signers can issue without backingMultisig 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 thresholdBoth need the same human quorum; clawback is also four-eyes in the app
No global pauseThe 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.

در این صفحه