Wallet Boundaries

info

Active portfolio classification — 2026-07-25 [D]. Wallet Boundaries is shared pre-launch authority-and-custody discipline inside Skyzai Personal and Skyzai Work, not an independent SKU, package, wallet, custodian, signer, or authority source. Product, pricing, commercial-page, and standalone-launch language below is preserved design history; route names do not prove a live wallet or value movement.

Status: pre-launch. This page describes target design; this document does not establish a deployed service.

Scope: proposed shared authority-and-custody discipline for Skyzai Personal and Skyzai Work, the two app/commercial packages. The seven product owners retain their distinct payment, identity and case responsibilities. This discipline is not a standalone SKU. See The Product Family.

Surface: wallets.skyzai.com (declarative) Docs: Wallet Boundaries reference (public documentation; not a live wallet) Status: DESIGN · Phase 2 Evidence tier: [D] with [I] qualifier — design-stage spec, architecturally inferred (qualifiers never substitute for [B]/[E]) Canonical manifest: (private, unpublished)

---

What Wallet Boundaries Are

Wallet Boundaries define sovereignty classes (W1–W5) that separate different types of wallet authority within an organization or personal setup. The service provides:

1. Topology design — map wallet classes to org/personal structure
2. Key ceremony — guided multi-party key generation with audit trail
3. Policy engine — spending limits, time locks, approval chains, slashing
4. Monitoring — real-time balance, transaction, and anomaly detection
5. Recovery — social recovery, dead man's switch, K4 Grace Exit

Critical boundary: No charge for sovereignty, chain fees, or user exit. Revenue comes from setup, monitoring, policy checks, and support.

---

Historical W1–W5 reference topology

Current wallet taxonomy is unresolved. These numbers are compatibility labels, not adopted authority classes.

Class	Name	Scope	Lane	Key Characteristics
W1	Personal Hot	Individual daily use	B2C	2FA, simple backup, mobile-first
W2	Personal Vault	Individual savings	B2C	Time-locked, social recovery, higher security
W3	Business/DAV	Organization treasury	B2B	Multi-sig (M-of-N), role-based access, org policies
W4	Private Principal	Natural Person's private critical acts	Personal/private reference	Air-gapped option, ceremony-required, never automated
W5	Service/Execution	Automated within policy	B2B	Bounded scope, slashing conditions, policy-gated

---

Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                        WALLET BOUNDARIES                             │
├─────────┬─────────┬─────────┬─────────┬─────────────────────────────┤
│   W1    │   W2    │   W3    │   W4    │            W5               │
│ Personal│ Personal│ Business│ Private │         Service             │
│   Hot   │  Vault  │   DAV   │Principal│       Execution             │
├─────────┼─────────┼─────────┼─────────┼─────────────────────────────┤
│ 2FA     │Timelock │ M-of-N  │Air-gapped│ Policy engine              │
│ Simple  │Social   │Role-based│Ceremony │ Bounded scope              │
│ backup  │recovery │access   │Human-only│ Slashing conditions        │
│ Mobile  │Higher   │Org      │Never     │ Automated within policy    │
│         │security │policies │automated │ Monitoring + alerts        │
└─────────┴─────────┴─────────┴─────────┴─────────────────────────────┘
                              │
                              ▼
                    ┌─────────────────┐
                    │  Policy Engine  │
                    │  (shared)       │
                    └─────────────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        ┌─────────┐    ┌─────────┐    ┌─────────┐
        │ EvoNet  │    │  Typed  │    │   K4    │
        │ SHOULD  │    │Authority│    │  Grace  │
        │  NOT    │    │         │    │  Exit   │
        └─────────┘    └─────────┘    └─────────┘

---

Key Ceremony Protocol

W3 (Business/DAV) Key Ceremony

Step 1: Participants gather (N signers)
Step 2: Each generates key share locally (air-gapped device)
Step 3: Shares combined using threshold scheme (M-of-N)
Step 4: Public key published, shares distributed
Step 5: Ceremony receipt emitted (OFN format)
Step 6: Recovery policy configured and signed

W4 (Private Natural Principal) Key Ceremony

Step 1: Natural Person prepares an air-gapped key for their own private acts
Step 2: Key generated offline, never touches networked device
Step 3: Backup share split using Shamir's Secret Sharing
Step 4: Each backup share held by separate trusted party
Step 5: Ceremony receipt with biometric + signature proof
Step 6: Private-DAV reference policy records what the natural principal (single-owner approval) may sign

---

Policy Engine

Policy Types

{
  "spending_limits": {
    "daily_max": "10000 USDC",
    "per_transaction_max": "5000 USDC",
    "weekly_max": "50000 USDC"
  },
  "time_locks": {
    "withdrawal_delay": "24 hours",
    "large_transaction_delay": "72 hours"
  },
  "approval_chains": {
    "w3_transaction": ["w3_signer_1", "w3_signer_2"],
    "w4_threshold": "> $1000 equivalent"
  },
  "slashing_conditions": {
    "anomaly_score": "> 0.9",
    "velocity_violation": "3x normal",
    "jurisdiction_violation": "sanctioned_region"
  }
}

---

API Specification

POST /v1/wallets

Create a new wallet with specified class.

Request:

{
  "class": "W3",
  "organization_id": "org_abc123",
  "policy": {
    "m_of_n": {"m": 2, "n": 3},
    "signers": ["0x...", "0x...", "0x..."]
  }
}

POST /v1/wallets/{id}/transaction

Submit transaction for policy evaluation.

POST /v1/wallets/{id}/recover

Initiate recovery process.

GET /v1/wallets/{id}/audit

Retrieve full audit trail.

---

Evidence Tiers

Evidence description	What would support it
Design/specification [D]	Wallet-class and key-ceremony definitions
Local tests	Reproducible dated local ceremony receipts, not external verification
Observed run [B]	Reproducible deployment and key-ceremony receipt
Independent verification [E]	Independent review/use evidence under its exact scope

Current documented status: design/specification [D]. A security audit has a scope; it does not automatically become an algebraic [A] proof.

---

K4 Grace Exit

Grace Exit means documented withdrawal of legitimate/redeemable property, permitted data and keys. Exact authority and custody/settlement terms govern distribution. Policy may trigger review or a wind-down proposal, not fund movement. M-of-N keys do not prove required distinct persons. Surviving obligations, third-party rights and required retention remain; this page does not select the disputed wallet taxonomy, cooldown or payout denominator.

---

η = 0 Compliance

Chargeable	Not Chargeable
Wallet topology setup	Sovereignty or self-custody
Monitoring and alerts	Chain gas fees (pass-through)
Policy review and config	Exit or recovery
Support	Key storage (user retains keys)

---

Cross-links

• Product page: /products/wallet-boundaries/
• Buyer deck: /products/wallet-boundaries/deck/
• Resource room: /products/wallet-boundaries/resources/
• Access form: /products/wallet-boundaries/access/
• Adjacent canon: API Pay (P0), KYC/KYB Hooks (P2), K4 Grace Exit
• Source markdown: (private, unpublished)

Refer to the canonical WEBSITE.md source for complete product spec. This wiki page exists so the .com → .org bidirectional pair resolves cleanly.

---

See Also

• Wallet Boundaries — Commercial page
• API Pay — Technical docs
• KYC/KYB Hooks — Technical docs
• FlowWallet contract code (private, unpublished)
• K4 Grace Exit

---

Historical predecessor wording — retained on 2026-09-27, not active rules

The displaced passages are preserved verbatim for lineage. This retention date is not their original authorship date.

Predecessor passage 1

Tier	Claim	Required Evidence
[I]	W1–W5 classes are defined	Design document
[E]	Key ceremony protocol works in test	Local ceremony test
[B]	External org deploys wallet topology	Key ceremony receipt, deployed contract
[A]	Wallet system audited by external security firm	Security audit report

Current status: [I] — design stage.

Predecessor passage 2

Every wallet class supports K4 Grace Exit:

• W1–W2: Export private key or seed phrase, transfer balances, delete account data
• W3: M-of-N signers can dissolve treasury and distribute per policy
• W4: The private natural principal can revoke their own authority and transfer to a new address
• W5: Policy can trigger automatic wind-down and fund distribution

Organism retains nothing. Exit with everything you entered with.

Historical predecessor wording — retained on 2026-09-28, not active rules

Predecessor passage 1

The W1–W5 Classes