Wallets & assets

The wallet module gives members a wallet inside the community app: balances, in-app payments and transfers, and member benefits. Balances, transfers, payment records and benefit rules live in the operator's deployment on the wallet-service component. Wallet modules integrate a trusted execution environment (TEE) for protected key operations.

The module is in developer preview because its specified key protection — TEE — is new to Symorva. The reference deployment already runs a wallet service with on-chain deposits and withdrawals, in-app transfers, chat payments, a double-entry ledger and a separately deployed custody boundary that keeps private keys out of every business API. The TEE-backed path described here builds on that design.

CapabilitiesCopy Anchor Link

ConfigurationCopy Anchor Link

{
  "modules": {
    "wallet": {
      "enabled": true,
      "keyProtection": "tee",
      "payments": true,
      "memberBenefits": true,
      "networks": ["network-a", "network-b"]
    }
  }
}

Network identifiers are chosen by the operator. Identifiers that appear in CLI templates are placeholders; listing a network does not imply that Symorva operates on it or has deployed anything to it.

Key protectionCopy Anchor Link

In the module design, every operation that touches private key material — key generation, address derivation, signing — runs inside a trusted execution environment. The wallet service's business logic, its transaction workers, the admin console and the operator's staff request operations through a narrow interface and never handle raw keys.

The reference deployment establishes the boundary this design builds on:

• A separate custody service. Key creation and signing are exposed only as internal operations — create or recover a key and derive its address; authorise and sign a fixed-size digest — and the custody service is deployed as its own security boundary.
• Separate databases. Custody key data and signing records live in databases separate from each other and from the business database, each with its own migrations.
• Explicit policy. Allowed networks, key purposes and amount limits are explicit configuration. Withdrawals to member-chosen destinations must be enabled explicitly; other movements go only to allowlisted destinations.
• Pluggable custody models. A sealed single-key model, a 2-of-3 threshold signing model in which one compromised share cannot sign, and an external key-management service. Changing models never rewrites existing keys.
• Hot and cold separation. Online wallets pay out; cold addresses receive consolidation and their keys never enter online systems.

Exact key handling depends on the wallet implementation a community deploys — for example whether keys are held by the community's custody service or by members. TEE protection does not make on-chain transactions anonymous, does not imply any particular custody or regulatory model, and is not insurance.

Payments and confirmationCopy Anchor Link

Money movement is always confirmation-driven:

• No optimistic balances. Apps show a transfer as complete only when the wallet service confirms it.
• Payment PIN. The member's PIN is encrypted on the device with the server's public key before it is sent. Biometric confirmation is enabled only when the server advertises a verification protocol for it.
• Idempotent commands. Every payment command carries a stable request identifier; retrying it cannot charge twice.
• Unknown results are queried, never resent. If the outcome of a command is unknown — for example after a network failure — the app queries the original command instead of submitting a new one.

Ledger integrityCopy Anchor Link

The wallet service records every movement as balanced double-entry postings. In the reference deployment, restored backups are checked against invariants before use: postings balance and are paired, orders and refunds are posted consistently, references resolve, and no account is negative.

EventsCopy Anchor Link

Preview webhook events.

Privacy scopeCopy Anchor Link

Key operations are processed inside a trusted execution environment (TEE).

Balances and payment records are visible to the member and to operator staff with finance roles. Key material is visible to no one.

Shared services and meteringCopy Anchor Link

The wallet module uses no shared services and has no metered units. All wallet operations stay inside the operator's deployment.

LimitsCopy Anchor Link

Per-network, per-asset and per-member limits are operator configuration in the wallet service.