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.

note

Current public-DAV authority boundary — 2026-07-12. Pre-launch target design; nothing here proves a live system. A public-DAV consequence may occur only when at least two natural-person councilors bind the exact consequence in a complete valid bound PRISM decision receipt. PRISM records and verifies that receipt only; it never serves as council, signatory, authority, or receipt producer. AI and caste seats stage unsigned proposals only; they never authorize or execute a public-DAV consequence. Constitution or membership adoption establishes constitution and membership only; it does not authorize a later consequence. Policy may constrain an unsigned proposal but never authorizes execution or substitutes for the complete consequence-bound receipt. Before receipt validity, consequence fails closed to read-only proposal, simulation, or deterministic sandbox; live evidence remains gated_pending_complete_valid_bound_receipt. Software deterministically carries out only the exact consequence bound to a complete valid bound PRISM decision receipt from at least two natural-person councilors binding that exact consequence.

Scope: capability inside the two buyer products (Skyzai Personal / Skyzai Work ✱) — not a standalone SKU. See The Product Family.

Surface: wallets.skyzai.com (declarative) Docs: skyzai.org/docs/wallet-boundaries (normative) Status: DESIGN · Phase 2 Evidence tier: [D] with [I] qualifier — design-stage spec, architecturally inferred (qualifiers never substitute for [B]/[E]) Canonical manifest: 02_SKYZAI/02_ORGANISM_COMMONS/NOOSPHERE/03_PRODUCTS/00_SKYZAI_COM_PRODUCT_MANIFEST.md

---

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.

---

The W1–W5 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 K2 natural principal 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

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.

---

K4 Grace Exit

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.

---

η = 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: 02_SKYZAI/02_ORGANISM_COMMONS/NOOSPHERE/03_PRODUCTS/wallet_boundaries/WEBSITE.md

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
• 02_SKYZAI/02_ORGANISM_COMMONS/EXECUTION/SKYZAI/execution/contracts/FlowWalletV2.sol
• K4 Grace Exit

---

Zero-Sum Resolution Equation

K3 public-DAV authority history — 2026-07-12

K3 historical reference — not active authority

note

Current public-DAV boundary — 2026-07-10. Pre-launch target design; nothing here is live. The active DAV is public and targets PRISM, with no K2 runtime, launch, genesis/bootstrap, or fallback dependency. Consequential authority requires at least two natural-person councilors; AI/caste seats stage unsigned proposals only. Before quorum, behavior fails closed to read-only/proposal, simulation, or deterministic sandbox, and a live decision receipt remains gated pending quorum.