# Sozu Rollup Architecture

graph TD
    %% Main Layers
    subgraph User Layer
        A[User Wallet]
        B[Small Apps]
    end

    subgraph Sozu Infrastructure
        C[Sequencer]
        D[Full Nodes]
        E[Bridge Contract]
        F[Pool Contract]
        G[UTXO Storage]
        H[Credit/Debit Balance Management]
        I[Proxy Accounts]
    end
    
    subgraph Blockchain Layer
        J[External Blockchains]
        J1[Ethereum]
        J2[Polygon]
        J3[Solana]
        J4[Optimism]
    end

    %% Connections between layers
    A --> F
    A --> C
    B --> C

    F -->|Token Deposit| E
    E --> D
    D --> C
    C --> G
    G -->|Generate| A

    %% Transaction Flow 
    A -->|Submit Action| C
    C -->|Batch Actions| J
    J -->|Confirm Batch| C
    C --> H

    %% Proxy Accounts
    H --> I
    I --> J

    %% Cross-Chain Bridges and Rebalancing
    subgraph Bridge & Rebalancing System
        K[Liquidity Pool]
        L[Trust-Minimized Bridges]
        K --> L
        L --> J
    end
    
    H -->|Cross-Chain Balance Access| K

    %% Fraud Proofs
    subgraph zkVM Fraud Proof Module
        M[Fraud Proof Generator]
        N[zkVM Verification]
        M -->|Generate Proof| N
        N --> J
        N -->|Message Other Chains| J
    end

*(not final architecture, need to make one, better than this)*

Sozu employs a rollup mechanism designed to enhance scalability by aggregating transactions into chain-specific batches, which are then settled on the respective blockchains. This allows multiple transactions to be processed in a single, consolidated batch, optimizing both transaction throughput and cost-effectiveness. By reducing the number of on-chain interactions, Sozu's rollup architecture provides a scalable and efficient chain abstraction operational model, aligning with the needs of users who demand low-cost, high-speed transactions across multiple blockchains.

## Sequencer Functionality
The sequencer plays a central role in Sozu’s architecture, orchestrating transaction batching, verification, and finalization. It organizes user actions from Sozu’s mempool into batches, verifies each transaction for ownership or proof validity, and posts these batches to the designated blockchain. This includes a recursive zero-knowledge proof (zk-proof) verification step to ensure privacy and security. The sequencer updates account data and nullifiers within its Merkle trees and generates UTXOs (unspent transaction outputs) upon confirmation. This architecture ensures a transparent and secure system that guarantees transaction completion while preserving data integrity.

## Deposit Flow and UTXO Generation
When users deposit ERC20 tokens into Sozu, these deposits are channeled into a pool contract. The pool contract then calls the bridge contract with token details, emitting an event recognized by Sozu full nodes. This deposit event is subsequently processed by the sequencer, which verifies the bridge transaction for finality and reorganization protection. Once confirmed, the sequencer creates UTXOs unique to the user’s account, allowing for flexible spending of these assets across chains without repeated bridging. The UTXO structure facilitates smooth cross-chain spending, eliminating the need for manual bridging and simplifying asset utilization for users.

sequenceDiagram
    participant User
    participant PoolContract
    participant BridgeContract
    participant FullNodes
    participant Sequencer
    participant Account/PrivateBucket
    
    User->>PoolContract: Deposit ERC20 Tokens
    PoolContract->>BridgeContract: Call Bridge Contract with Deposited Token
    BridgeContract-->>FullNodes: Emit Deposit Event
    FullNodes->>Sequencer: Pass Event Data
    Sequencer->>Sequencer: Verify Bridge Transaction (Reorg & Confirmation)
    Sequencer->>Account/PrivateBucket: Create UTXO in Account or Private Bucket
    Account/PrivateBucket-->>User: UTXO Ready for Spending

## Transaction Flow with zk-Proof Integration
Users submit their actions (e.g., transfers or swaps) into Sozu’s mempool, where the sequencer groups them into batches and verifies ownership or proof validity. Upon batch completion, the sequencer initiates the batcher contract on-chain, which executes and validates recursive SNARK proofs before updating the corresponding data trees. After confirmation, the transaction generates output UTXOs, allowing users to access their assets seamlessly across chains. This structured transaction flow, with integrated zero-knowledge proofs, provides privacy and efficiency, aligning with Sozu's objective of delivering high-throughput, secure transactions in a multi-chain environment.

sequenceDiagram
    participant User
    participant Mempool
    participant Sequencer
    participant BatcherContract
    participant Blockchain
    participant MerkleTrees
    
    User->>Mempool: Submit Action (e.g., Transfer, Swap)
    Mempool->>Sequencer: Add Action to Mempool
    Sequencer->>Sequencer: Batch Actions & Verify Proof/Ownership
    Sequencer->>BatcherContract: Send Batch to Specific Chain
    BatcherContract->>Blockchain: Execute Batch & Validate Recursive SNARK Proof
    Blockchain->>MerkleTrees: Update Account Data & Nullifiers
    Blockchain->>Sequencer: Confirm L2 Transaction
    Sequencer->>User: Generate Output UTXOs for Spending

## Trust-Minimized Cross-Chain Bridges
Sozu’s trust-minimized bridges ensure security by using an optimistic framework across connected chains. A bridge contract on each chain monitors and processes deposits and withdrawals with optimistic settlement, and upon finalization across chains, the batch or block of batches is completed. If any batch is suspected of fraud, Sozu’s zkVM-based fraud proof system enables a prover to generate proof of fraud, which is validated across chains via Sozu’s messaging bridges. This mechanism enables Sozu to maintain decentralized control over cross-chain transactions, preventing fraud and enhancing trust in the platform’s security.

graph TD
    A[User Deposit to Bridge Contract] --> B[Bridge Contract Emits Event]
    B --> C[Event Picked by Full Nodes]
    C --> D[Full Nodes Relay Event to Sequencer]
    D --> E[Sequencer Verifies Transaction & Completes Batch]
    E --> F{Batch Finalization Across Chains}
    
    F --> G[Finalized on All Chains]
    F --> H[Fraud Proof Detection]
    
    H --> I{zkVM Fraud Proof Verification}
    I --> J[Message Sent to All Chains via Messaging Bridges]
    G --> K[Batch Finalized on All Chains]
    J --> K

## Liquidity Rebalancing
To support seamless cross-chain transactions, Sozu pools user liquidity and manages an aggregated balance. Every six hours, Sozu rebalances liquidity pools across chains using traditional bridges, selecting the most cost-effective option. This mechanism allows users to access their assets across chains without the need for individual bridging, ensuring that liquidity is consistently distributed and accessible wherever required. This frequent rebalancing structure aligns with Sozu’s mission to offer a unified, chain-abstracted user experience.

graph TD
    A[Aggregated User Liquidity Pool] --> B[Rebalance Every 6 Hours]
    B --> C{Choose Optimal Bridge for Cost Efficiency}
    
    C --> D[Use Bridge to Rebalance Across Chains]
    D --> E[Liquidity Distributed Across Chains]
    
    E --> F[Accessible Assets for User Across Chains]

## Credit and Debit Balance Differentiation
Sozu employs a dual-balance system to optimize asset management: a “credit balance” for cross-chain liquidity and a “debit balance” specific to chain-based activities. The credit balance is chain-abstracted, allowing users to engage with any blockchain supported by Sozu without incurring bridging fees. The debit balance, however, pertains to balances on specific blockchains, catering to users who prefer chain-specific interactions. This dual-balance system ensures flexibility and convenience for users, while also enabling Sozu to manage cross-chain assets efficiently.

flowchart TD
    A[User Actions] --> B[Check Balance Type]
    B -->|Credit Balance| C[Cross-Chain Usability]
    B -->|Debit Balance| D[Chain-Specific Usability]
    
    C --> E[Seamless Cross-Chain Transaction]
    D --> F[Native Chain Interaction]

## Proxy Accounts
Each Sozu user can maintain proxy accounts on connected blockchains, acting as representations of their main account across chains. These proxy accounts function as smart contract wallets through sozu, allowing cross-chain interactions through having wallets create resource locks for their balance, and empowering solvers to execute on behalf while executing so user doesn't lose their "identity" and get rid of the repeated bridging. Proxy accounts provide users with an EOA-like (Externally Owned Account) experience and enable credit balance functionality across chains. Smart contract wallets manage all the required conditions and provide users with a streamlined, efficient multi-chain interaction system.

graph TD
    A[User Main Account] --> B[Proxy Account Creation on Connected Chains]
    B --> C[Smart Contract Wallet per Chain]
    C --> D[Solver Governs Transactions]
    
    D --> E[Allows Cross-Chain Transactions Without Bridging]
    E --> F[EOA-Like User Experience]

## Small Applications (Small Apps)
Sozu’s ecosystem is designed to support the creation of “small apps,” allowing developers to build applications that integrate Sozu OAuth for streamlined cross-chain access. These applications range from simplified website integrations to fully functional apps that leverage Sozu’s infrastructure for decentralized, chain-abstracted interactions. By enabling small apps, Sozu creates an environment for developers to expand the platform’s utility and adoption, contributing to a broader ecosystem of user-friendly, blockchain-agnostic applications.

graph TD
    A[Developer] --> B[Build Small App]
    B --> C[Integrate Sozu OAuth]
    C --> D[Cross-Chain User Access]
    
    D --> E[User Authentication & Interaction]
    E --> F[App Functionality on Sozu Ecosystem]