docs: design security architecture

[mfw78]

Context

Nexum requires a comprehensive security architecture that provides defense-in-depth for all transactions and RPC calls. This includes firewall-like RPC filtering, programmatic signing rules, risk assessment, human-readable transaction interpretation, and final execution validation before transactions are sent.

Considerations

This specification should address the following considerations:

Firewall & RPC Access Control:

• RPC method filtering at TUI/application level
• Per-identity RPC permissions
• Per-origin (dapp) RPC permissions
• Allowlist/blocklist management
• Rate limiting and quota enforcement
• Filtering rules language or DSL

Signing Rules & Confirmation Framework:

• Programmatic rules for determining when confirmation is required
• Rule conditions (transaction value, destination, calldata patterns)
• Auto-approval policies for trusted scenarios
• Identity-specific signing policies
• Override mechanisms for high-risk operations

Risk Assessment Module:

• Risk scoring algorithm for transactions
• Factors considered: value, destination, calldata complexity, gas price
• Integration with external risk feeds or oracles
• Risk thresholds for different confirmation levels
• Malicious contract detection

Transaction Interpretation:

• WASM module interface for transaction decoders
• Parsing to/value/calldata into human-readable descriptions
• ABI decoding and function signature resolution
• Support for common patterns (transfers, approvals, swaps)
• Fallback behavior for unknown transactions
• Multi-language support for descriptions

Execution Validation:

• Pre-send validation as last line of defense
• Sanity checks (gas limits, nonce, balance)
• Simulation/dry-run capabilities
• Final user confirmation requirements
• Abort mechanisms

Integration:

• How these layers integrate with the module system
• How these layers integrate with the request flow (docs: design system architecture #89)
• Performance considerations for validation pipeline
• Error handling and user feedback

Dependencies

Depends on (Phase 4):

• docs: design system architecture #89 (System architecture defines request flow)
• docs: design module system & RPC namespace architecture #121 (Module system provides integration points)

Out of Scope

• Specific risk scoring algorithms (implementation details)
• UI/UX for confirmation dialogs
• External oracle integration (initially)

References

• Related: docs: design system architecture #89 (System architecture), docs: design module system & RPC namespace architecture #121 (Module system)
• Similar systems: Frame.sh security model, Rabby wallet security features
• Epic: [EPIC 0.0] Foundation - Identity & Account Architecture pm#3 (Foundation)