The Colabonate Wallet must serve as a unified user interface, abstracting the complexity of managing funds across L1, RSK (RBTC/Forks), and L2 (LN).

We must choose between two primary custody models for LN funds:

Decision: Adopt a Hybrid Custodial (HC) model for everyday users utilizing LN, ensuring that all LN activities are mirrored in the Audit Layer and linked to the active SI. Non-Custodial LN support will be an optional feature for power users.

• Balance Aggregation: Display a single aggregated Bitcoin balance, clearly segmented into: L1/RSK balance, LN Channel Balance (HC or NC), and Fork Asset balance.
• Automatic Switching: The wallet automatically selects the LN rail for standard payments below a defined threshold (e.g., $100 USD equivalent) and the RSK/L1 rail for higher values or governed transactions (Escrow, Fork Transfer).
• SI Authorization: Every LN invoice generation or payment execution must pass an internal SI check (e.g., authenticated session linked to the SI-key context) before execution on the LN node.

The LPM Rail is the backend infrastructure responsible for lightning operations.

• Node Implementation: Colabonate will operate a cluster of highly available Lightning Nodes (e.g., LND or Core Lightning) managed by the system.
• Liquidity Management: Dedicated internal system or service responsible for maintaining robust, balanced channels with major network hubs to ensure payment reliability.
• SI-Linked Accounts: Each standard user (HC model) is represented by a dedicated sub-account or channel allocation managed by the Colabonate LN Node Cluster, mapped directly to their SI.

• Request: A user initiates a standard payment (e.g., buying a feature) or requests a payment from another user.
• SI Check: The system verifies the initiator’s active SI context via the Identity Layer.
• Invoice Generation: The LPM Rail generates a standard BOLT-11 LN Invoice via the Colabonate LN Node cluster.
• Payment: The payer’s wallet (or external wallet) settles the invoice.
• Audit Logging: Upon successful HTLC settlement, a simplified transaction record (Payment Hash, Value, SI Originator/Recipient) is immediately logged to the Audit Layer’s Off-Chain Index. This ensures that even off-chain payments are traceable for DAO governance and dispute resolution purposes via the Ticket System.

Lightning transactions, being off-chain, must maintain adherence to the on-chain governance rules where necessary.

• Fork Transactions: Trading or management of Codex Forks remains strictly on the RSK Contract Layer due to the need for atomic execution and static governance assurance. LN is unsuitable for Fork transfers.
• Channel Lifecycle Governance: High-value operations, like the initial commitment of funds from L1/RSK to open a new major channel for the Colabonate cluster, or closing a channel, require Proximity Proof authorization integrated with the Wallet Layer (as defined in 3.4 of the main concept).
• RSK Bridge Interoperability: A direct, programmatic bridge between RBTC on RSK and the Colabonate LN Node is necessary for rapid on/off-boarding of funds, minimizing friction in high-liquidity situations without requiring manual L1 transactions. This link must be secured by multi-signature governance defined by the DAO.

The integration of Layer 2 requires tailored security controls.

• L2 Anti-Fraud: Implementation of automated monitoring for suspicious channel state changes and forceful channel closures, with immediate reporting to the Audit Layer.
• HC System Auditability: The Hybrid Custodial model necessitates granular auditing. The Audit Layer must log:
  • Channel open/close operations (L1/RSK on-chain transactions).
  • All routed payments (off-chain HTLC state settlement).
  • SI linkage for every invoice and payment originated or received.
• Key Management: The private keys controlling the liquidity in the Colabonate LN Node must be managed using robust hardware security modules (HSMs) and require quorum multisig controlled by the DAO (via RSK smart contract governance) for access to large funds.