docs: document parallel execution across authorities (#48)

Per-authority PDA design means different authorities on the same wallet
can execute transactions concurrently on Solana's runtime. Only the
authority PDA is writable (counter increment); wallet and vault are
read-only during Execute, creating no shared write locks.

Author: onspeedhp

README.md

@@ -16,6 +16,7 @@ A high-performance smart wallet program on Solana with passkey (WebAuthn/Secp256
 - **Zero-Copy Serialization**: Raw byte casting via pinocchio, no Borsh overhead
 - **CompactInstructions**: Index-based instruction packing for multi-call payloads within Solana's 1,232-byte tx limit
 - **Deferred Execution**: 2-transaction flow for payloads exceeding the tx limit (e.g., Jupiter swaps) -- TX1 authorizes via signature, TX2 executes with full inner instruction space (~1,100 bytes)
+- **Parallel Execution**: Different authorities on the same wallet execute concurrently -- per-authority PDA means no shared write locks
 - **CPI Reentrancy Protection**: stack_height check prevents cross-program authentication attacks
 
 ---

docs/Architecture.md

@@ -139,6 +139,35 @@ Seeds: `["vault", wallet_pubkey]`
 
 No data allocated. Holds SOL. Program signs for it via PDA seeds during Execute.
 
+## Parallel Execution
+
+A key design property: **different authorities on the same wallet can execute transactions in parallel** on Solana's runtime.
+
+### Why it works
+
+During Execute, the only account written to is the **authority PDA** (odometer counter increment). The wallet PDA and vault PDA are read-only:
+
+| Account | Access | Shared across authorities? |
+|---|---|---|
+| Authority PDA | **Writable** (counter++) | No -- each authority has its own PDA |
+| Wallet PDA | Read-only | Yes, but no write lock |
+| Vault PDA | Signer-only (CPI) | Yes, but no write lock |
+
+Since each authority is a separate PDA, Solana's scheduler sees no writable overlap and runs them concurrently.
+
+### Parallelism matrix
+
+| Scenario | Parallel? | Reason |
+|---|---|---|
+| Authority A + Authority B (same wallet) | Yes | Different writable PDAs |
+| Session key + Secp256r1 authority (same wallet) | Yes | Different writable PDAs |
+| Same authority, 2 transactions | No | Same writable PDA + counter conflict |
+| Authority A (wallet 1) + Authority B (wallet 2) | Yes | Entirely separate accounts |
+
+### Design implication
+
+This enables high-throughput wallets where multiple authorized parties (e.g., an admin managing permissions while a spender sends payments, or multiple session keys operating concurrently) never block each other. The per-authority odometer counter provides replay protection without creating a shared bottleneck.
+
 ## 5. Instructions (9 total)
 
 ### CreateWallet (discriminator: 0)

docs/Costs.md

@@ -102,6 +102,20 @@ The Secp256r1 Execute transaction was optimized from **708 bytes to 658 bytes**
 
 ---
 
+## Parallel Execution
+
+Different authorities on the same wallet can execute transactions **in parallel** on Solana's runtime. This is possible because each authority has its own PDA -- the only writable account during Execute is the authority PDA (counter increment), while wallet and vault are read-only.
+
+| Scenario | Parallel? |
+|---|---|
+| Authority A + Authority B (same wallet) | Yes -- different writable PDAs |
+| Session key + Secp256r1 authority | Yes -- different writable PDAs |
+| Same authority, 2 transactions | No -- counter conflict on same PDA |
+
+This means a wallet can have multiple session keys, spenders, and admins operating concurrently without blocking each other. See [Architecture.md](Architecture.md) for the full account access analysis.
+
+---
+
 ## Rent-Exempt Costs
 
 Solana requires accounts to maintain a minimum balance (rent-exempt) based on data size. The formula is `(128 + data_size) * 3,480 * 2` lamports.