v1.1

Co-authored-by: JulesCrown <admin@noip.localhost>
Reviewed-on: http://gitea.loseyourip.com:4000/giteadmin/SoLUSH-3/pulls/16

.gitignore

@@ -1,2 +1,5 @@
 onchain/cache/
-onchain/out/
+onchain/out/
+out/
+cache/
+lib/forge-std

ISSUE_TEMPLATE.md

@@ -0,0 +1,47 @@
+me: Bounty
+about: Bounty
+title: ''
+labels: bounty
+assignees: ''
+
+---
+
+# Bounty
+
+## Scope
+<!-- A list of specific things which should be done to deliver the bounty. These could be seen as requirements to verify/review bounty against -->
+
+-
+-
+-
+
+## Deliverables
+<!-- Artifacts produced as the result of this bounty. Something that could be verified/reviewed. Some examples: updated code, deployment made, blog post published, public event conducted etc -->
+
+-
+-
+
+## Bounty Owner/Gardener
+<!-- The Role who is responsible for the bounty. -->
+<@your github username> as **<Role>**
+
+## Gain for the Role
+<!-- How the completion of this bounty helps to pursue the Role's purpose -->
+
+## Roles
+bounty gardener: <@your git username> / X DAI <!-- likely shouldn't be a % but rather flat -->
+bounty worker: name / share
+bounty reviewer: name / share
+
+## Gardener checklist
+
+- [ ] I have attached one of the `size-` labels to this bounty
+
+<!--
+# Bounty sizes
+XS / 200 DAI / effort ~ 3h
+S / 350 DAI / effort ~5h 
+M / 550 DAI / effort ~8h
+L / 900 DAI / effort ~13h
+XL / 1400 DAI / effort ~21h
+-->

Interpreter.md

@@ -1,124 +0,0 @@
-# Interpreter.md
-
-## Overview
-
-This repository provides a **Push3-like interpreter** implemented in Solidity. It uses a _token-based bytecode_ approach to parse programs from a `bytes` array (the `code`) into typed **descriptors**, which are then executed by the interpreter.
-
-**Push3** is a stack-based language originally designed for genetic programming and autoconstructive evolution. Each data type (e.g. `INT_LITERAL`, `FLOAT`, `BOOLEAN`, etc.) has its own stack. The **`EXEC`** stack manages the flow of execution.
-
-**In this implementation**:
-- We store code in a single `bytes` array (`code`).
-- We parse sublists and integer literals from that array.
-- We push instructions and literals onto an execution stack.
-- We pop them in LIFO order and execute them.
-
-### Key Features
-
-1. **Token-Based Parsing**: We define small tokens (`0x00` => NOOP, `0x01` => INTEGER_PLUS, `0x02` => INT_LITERAL, `0x03` => SUBLIST). If we see `INT_LITERAL`, we read 4 bytes for a 32-bit integer; if we see `SUBLIST`, we read 2 bytes for the sublist length, then parse it recursively.
-2. **Descriptor System**: We represent instructions, literals, and sublists using 256-bit “descriptors.” Each descriptor encodes:
-   - A `tag` (top 8 bits): e.g. `INT_LITERAL`, `INSTRUCTION`, `SUBLIST`.
-   - `offset` and `length` for sublists.
-   - A leftover field (e.g. for storing integer data).
-3. **Reversing Items**: When we pop a sublist descriptor, we parse it into descriptors and then push them onto the `EXEC` stack in reverse order. This ensures the list’s leftmost token executes first, consistent with the Push3 spec.
-4. **Separation of Parsing and Execution**: 
-   - **Parsing**: Transforms raw byte tokens into typed descriptors (instructions, literals, or nested sublists).
-   - **Execution**: The `runInterpreter` function repeatedly pops from `EXEC`, decides if it’s an instruction or literal or sublist, and acts accordingly.
-
-## Code Structure
-
-### 1. **Enums**
-
-- **`CodeTag`**: 
-  - `NO_TAG` (unused), 
-  - `INSTRUCTION`, 
-  - `INT_LITERAL`, 
-  - `SUBLIST`.
-
-- **`OpCode`**:  
-  - `NOOP`, 
-  - `INTEGER_PLUS`.
-
-### 2. **Descriptor Layout**
-
-A **256-bit** word has:
-```
-[  top 8 bits    |  offset(32 bits) |  length(32 bits)  |  leftover(184 bits) ]
-```
-- `tag`: The top 8 bits (e.g. `INT_LITERAL`).
-- `offset, length`: If `tag = SUBLIST`, these define which bytes in `code` represent the sub-sublists.
-- `leftover`: If `tag = INT_LITERAL`, we store the 32-bit integer in the bottom 32 bits of leftover. If `tag = INSTRUCTION`, we store the opcode (`NOOP`, `INTEGER_PLUS`) in the lowest 8 bits of leftover.
-
-### 3. **Helper Reads**
-
-- **`readUint32(code, start)`**: Copies 4 bytes from calldata into a small buffer, returns the final `uint32`. By shifting bits if needed, we ensure we get the integer from the correct part of the loaded word.
-- **`readUint16(code, start)`**: Similar logic for 2 bytes.
-
-### 4. **`parseSublist` Function**
-
-When we see a sublist descriptor (`tag=SUBLIST`), we parse the slice `[off..off+len]` in the `bytes code`. We iterate token by token:
-- `0x00` => `NOOP`
-- `0x01` => `INTEGER_PLUS`
-- `0x02` => read 4 bytes => `INT_LITERAL`
-- `0x03` => read 2 bytes => sub-sublist length => build a sub-descriptor
-
-We accumulate these descriptors in an array. Then, later, we push them _in reverse_ onto the `EXEC` stack.
-
-### 5. **`runInterpreter` Function**
-
-1. Loads initial CODE, EXEC, and INT stacks from the provided arrays.
-2. While `EXEC` is non-empty:
-   - Pop the top descriptor.
-   - If `INSTRUCTION`, decode the opcode (e.g. `INTEGER_PLUS`) and do it (pop top 2 ints, push their sum).
-   - If `INT_LITERAL`, push that integer onto the int stack.
-   - If `SUBLIST`, parse that sublist into descriptors, then push those in reverse.
-
-## How to Contribute
-
-1. **Add New Instructions**  
-   - Expand `OpCode` enum (e.g. `INTEGER_MINUS`, `INTEGER_MUL`, etc.).
-   - Write a `makeInstruction` or `makeIntLiteral` function to build the descriptor for it.
-   - In the main loop, implement the logic (pop the correct number of integers, do the operation, push the result).
-
-2. **Support More Data Types**  
-   - For instance, a `FLOAT` or `BOOLEAN` stack.  
-   - Add a new tag (`FLOAT_LITERAL`?), new instructions (`FLOAT.PLUS`?), etc.
-
-3. **Improve Parsing**  
-   - If you want 256-bit literals, define a new token that reads 32 bytes, or do other expansions (like `CODE` type).  
-   - Or define advanced sublist structures (like nested `( ( ) )` expansions).
-
-4. **Gas Optimization**  
-   - Check how large arrays are allocated (like in `parseSublist`).  
-   - Possibly implement step-by-step execution if large code exceeds block gas limits.
-
-5. **Add Logging & Debug Tools**  
-   - Use `console.log(...)` to trace tokens, track final states, or measure performance.
-
-6. **Test Coverage**  
-   - Provide more unit tests in Foundry for advanced instructions, nested sublists, edge cases with zero-length sublists, etc.
-
-## Next Steps
-
-### A. Extending the VM
-
-A “full” Push3 VM might include:
-- **Multiple Data Stacks**: `BOOLEAN`, `FLOAT`, `NAME`, etc.  
-- **NAME Binding**: Let `NAME`s reference values or code.  
-- **Control Structures**: `EXEC.IF`, `EXEC.DO*COUNT`, or combinators like `EXEC.Y`.
-
-### B. Example Project
-
-You could use this interpreter in:
-- A genetic programming environment, where random code is generated and mutated.
-- A puzzle solver that runs tiny “scripts” in EVM-like constraints.
-
-## Conclusion
-
-This `Push3Interpreter` is a **minimal** scaffold for a token-based, list-expanding interpreter with typed descriptors. By following the patterns for instructions, sublists, and typed stacks, you can easily expand it into a more complete VM. We welcome contributions in the form of new instructions, data types, and performance optimizations.
-
-1. **Clone** this repo.  
-2. **Check** the `test/` folder for Foundry-based tests.  
-3. **Add** or modify instructions & sublists in `parseSublist` and `runInterpreter`.  
-4. **Run** `forge test --via-ir -vv` to see logs and confirm your changes.
-
-Enjoy exploring the **Push3** style VM in Solidity!

README.md

@@ -1,6 +1,14 @@
 # **SoLUSH**: A Push 3 Virtual Machine in Solidity
 
-Welcome to **SoLUSH 3** (pronounced like **"slush"** without the "o", composed from **S**o**L**idity and p**USH** 3), a Solidity implementation of the [Push 3 stack machine](http://faculty.hampshire.edu/lspector/push3-description.html), designed to bring evolved genetic algorithms on-chain. By enabling the execution of Push 3 programs directly within Ethereum smart contracts, SoLush 3 paves the way for decentralized, adaptive systems to address complex optimization problems.
+Welcome to **SoLUSH 3** (pronounced like **"slush"** without the "o", composed from **S**o**L**idity and p**USH** 3), a **Push3-like interpreter** implemented in Solidity. It uses a _token-based bytecode_ approach to parse programs from a `bytes` array (the `code`) into typed **descriptors**, which are then executed by the interpreter.
+
+**Push3** is a stack-based language originally designed for genetic programming and autoconstructive evolution. Each data type (e.g. `INT_LITERAL`, `FLOAT`, `BOOLEAN`, etc.) has its own stack. The **`EXEC`** stack manages the flow of execution.
+
+**In this implementation**:
+- We store code in a single `bytes` array (`code`).
+- We parse sublists and integer literals from that array.
+- We push instructions and literals onto an execution stack.
+- We pop them in LIFO order and execute them.
 
 ## 🌟 Vision
 
@@ -12,19 +20,97 @@ SoLUSH is a key step toward realizing the vision of running decentralized evolut
 
 To understand the broader vision, check out the [Vision Document](vision.md).
 
+### Key Features
+
+1. **Token-Based Parsing**: We define small tokens (`0x00` => NOOP, `0x01` => INTEGER_PLUS, `0x02` => INT_LITERAL, `0x03` => SUBLIST). If we see `INT_LITERAL`, we read 4 bytes for a 32-bit integer; if we see `SUBLIST`, we read 2 bytes for the sublist length, then parse it recursively.
+2. **Descriptor System**: We represent instructions, literals, and sublists using 256-bit “descriptors.” Each descriptor encodes:
+   - A `tag` (top 8 bits): e.g. `INT_LITERAL`, `INSTRUCTION`, `SUBLIST`.
+   - `offset` and `length` for sublists.
+   - A leftover field (e.g. for storing integer data).
+3. **Reversing Items**: When we pop a sublist descriptor, we parse it into descriptors and then push them onto the `EXEC` stack in reverse order. This ensures the list’s leftmost token executes first, consistent with the Push3 spec.
+4. **Separation of Parsing and Execution**: 
+   - **Parsing**: Transforms raw byte tokens into typed descriptors (instructions, literals, or nested sublists).
+   - **Execution**: The `runInterpreter` function repeatedly pops from `EXEC`, decides if it’s an instruction or literal or sublist, and acts accordingly.
+
+## Code Structure
+
+### 1. **Enums**
+
+- **`CodeTag`**: 
+  - `NO_TAG` (unused), 
+  - `INSTRUCTION`, 
+  - `INT_LITERAL`, 
+  - `SUBLIST`.
+
+- **`OpCode`**:  
+  - `NOOP`, 
+  - `INTEGER_PLUS`.
+
+### 2. **Descriptor Layout**
+
+A **256-bit** word has:
+```
+[  top 8 bits    |  offset(32 bits) |  length(32 bits)  |  leftover(184 bits) ]
+```
+- `tag`: The top 8 bits (e.g. `INT_LITERAL`).
+- `offset, length`: If `tag = SUBLIST`, these define which bytes in `code` represent the sub-sublists.
+- `leftover`: If `tag = INT_LITERAL`, we store the 32-bit integer in the bottom 32 bits of leftover. If `tag = INSTRUCTION`, we store the opcode (`NOOP`, `INTEGER_PLUS`) in the lowest 8 bits of leftover.
+
+### 3. **Helper Reads**
+
+- **`readUint32(code, start)`**: Copies 4 bytes from calldata into a small buffer, returns the final `uint32`. By shifting bits if needed, we ensure we get the integer from the correct part of the loaded word.
+- **`readUint16(code, start)`**: Similar logic for 2 bytes.
+
+### 4. **`parseSublist` Function**
+
+When we see a sublist descriptor (`tag=SUBLIST`), we parse the slice `[off..off+len]` in the `bytes code`. We iterate token by token:
+- `0x00` => `NOOP`
+- `0x01` => `INTEGER_PLUS`
+- `0x02` => read 4 bytes => `INT_LITERAL`
+- `0x03` => read 2 bytes => sub-sublist length => build a sub-descriptor
+
+We accumulate these descriptors in an array. Then, later, we push them _in reverse_ onto the `EXEC` stack.
+
+### 5. **`runInterpreter` Function**
+
+1. Loads initial CODE, EXEC, and INT stacks from the provided arrays.
+2. While `EXEC` is non-empty:
+   - Pop the top descriptor.
+   - If `INSTRUCTION`, decode the opcode (e.g. `INTEGER_PLUS`) and do it (pop top 2 ints, push their sum).
+   - If `INT_LITERAL`, push that integer onto the int stack.
+   - If `SUBLIST`, parse that sublist into descriptors, then push those in reverse.
+
+
+
+## Next Steps
+
+### A. Extending the VM
+
+A “full” Push3 VM might include:
+- **Multiple Data Stacks**: `BOOLEAN`, `FLOAT`, `NAME`, etc.  
+- **NAME Binding**: Let `NAME`s reference values or code.  
+- **Control Structures**: `EXEC.IF`, `EXEC.DO*COUNT`, or combinators like `EXEC.Y`.
+
+### B. Example Project
+
+You could use this interpreter in:
+- A genetic programming environment, where random code is generated and mutated.
+- A puzzle solver that runs tiny “scripts” in EVM-like constraints.
+
 ## 🚀 Getting Started
 
-SoLUSH 3 is in active development. To contribute or test the functionality, follow these steps:
+This `Push3Interpreter` is a **minimal** scaffold for a token-based, list-expanding interpreter with typed descriptors. By following the patterns for instructions, sublists, and typed stacks, you can easily expand it into a more complete VM. We welcome contributions in the form of new instructions, data types, and performance optimizations.
 
-1. Clone the repository:
+1. **Clone** this repo.  
-   ```bash
+2. **Check** the `test/` folder for Foundry-based tests.  
-   git clone https://github.com/your-username/SoLUSH.git
+3. **Add** or modify instructions & sublists in `parseSublist` and `runInterpreter`.  
-   cd SoLUSH
+4. **Run** `forge test --via-ir -vv` to see logs and confirm your changes.
-   ```
-2. Install dependencies (if applicable).
-3. Review the examples and test cases to understand how Push 3 programs are executed on the VM.
 
 
+### How to contribute
+
+Check the [Issues](../../../issues) section to find tasks to tackle.
+
 ## 🛠️ Roadmap
 
 - **Core Features:**

vision.md

@@ -1,8 +1,47 @@
-# SoLUSH: Running Intelligence On-Chain
+# Sovraigns: Intelligence Where LLMs Can't Reach
 
-In decentralized finance, systems often involve tasks such as determining optimal liquidity ranges for automated market makers, allocating staking rewards in a way that balances fairness and participation incentives, or dynamically adjusting collateralization ratios to minimize risks in lending protocols. These challenges are critical for ensuring the efficiency and stability of protocols, yet they are particularly difficult to address without centralization. Off-chain solutions often rely on external computation and centralized entities or oracles, introducing trust dependencies and undermining the decentralized ethos of blockchain systems.
+## The DeFi Intelligence Paradox
 
-Artificial intelligence is increasingly being explored in decentralized finance to enhance token ecosystems and liquidity management. This shift represents a practical application of AI tools aimed at addressing complex optimization problems directly within blockchain ecosystems. While large language models (LLMs) dominate discussions around AI innovation due to their general-purpose capabilities, they are poorly suited to the demands of decentralized adaptive systems. In contrast, **genetic algorithms** (GAs) offer a more natural and efficient fit for systems requiring iterative improvements, combining computational simplicity with adaptive behavior.
+Decentralized finance protocols are caught in an impossible dilemma. They desperately need sophisticated optimization to remain competitive - determining optimal liquidity ranges for automated market makers, dynamically adjusting collateralization ratios, allocating staking rewards efficiently. Yet the very nature of their decentralization prevents them from using modern AI solutions.
+
+**The paradox is stark:**
+1. **Protocols need intelligence** - Complex market dynamics and adversarial environments require adaptive, sophisticated algorithms
+2. **They can't trust centralized AI** - Using OpenAI APIs or centralized optimizers defeats the entire purpose of decentralization
+3. **They can't run AI on-chain** - Even simple neural networks would cost millions in gas fees
+
+This creates a fundamental barrier: **DeFi protocols need intelligence to compete, but using intelligence makes them centralized.**
+
+Current "solutions" like external oracles and trusted computation providers are just band-aids that reintroduce the very centralization DeFi was meant to eliminate. When a protocol relies on Chainlink for price feeds or Gauntlet for parameter optimization, they're trusting a centralized entity that could be compromised, censored, or simply fail.
+
+## Sovraigns: Bringing Intelligence On-Chain
+
+Sovraigns enables verifiable intelligence directly within blockchain systems through a breakthrough combination of **genetic algorithms**, **zero-knowledge proofs**, and **based rollups**.
+
+The key innovation: algorithms are evolved off-chain, registered on a sidechain after validation, and then executed with zero-knowledge proofs whenever protocols need optimization. The proofs are batched in a based rollup that inherits Ethereum's security, enabling trustless intelligence at scale.
+
+## The Market Opportunity
+
+The inefficiencies in DeFi represent a massive, growing market:
+
+| **DeFi Inefficiency** | **Annual Value Lost** | **Root Cause** |
+|---|---|---|
+| Uniswap V3 LP Losses | ~$400M | Suboptimal position management |
+| Lending Protocol Inefficiency | ~$300M | Conservative parameters |
+| MEV/Arbitrage Extraction | ~$800M | Predictable protocol behavior |
+| **Total Market** | **$1.5B+** | **Lack of intelligent optimization** |
+
+As DeFi grows and becomes more complex, this problem compounds. With DeFi TVL exceeding $50B and growing, the market for intelligent optimization could reach **$10B+ within 5 years**.
+
+### Current Solutions vs. Sovraigns
+
+| **Aspect** | **Current Solutions** | **Sovraigns** |
+|---|---|---|
+| **Trust Model** | Centralized (Gauntlet, Chaos Labs) | Trustless ZK proofs |
+| **Accessibility** | Enterprise contracts only | Permissionless for all protocols |
+| **Transparency** | Black box optimization | Fully auditable algorithms |
+| **Cost** | High consulting fees | Pay-per-optimization |
+| **Adaptability** | Manual updates | Continuous evolution |
+| **Security** | Single point of failure | Decentralized validation |
 
 ## **Introduction to Genetic Algorithms**
 
@@ -13,41 +52,121 @@ Genetic algorithms (GAs) are optimization techniques inspired by the process of
 - **Selection:** The process of choosing the best-performing solutions to carry forward.
 - **Crossover and Mutation:** Methods to combine and modify solutions, creating new ones that explore the problem space.
 
-Through repeated iterations, GAs converge toward optimal or near-optimal solutions, making them highly effective for solving complex, dynamic problems. GAs have recently gained momentum with the development of the [Push 3 language](http://faculty.hampshire.edu/lspector/push3-description.html) by Lee Spector. Push 3’s compact and efficient architecture shares similarities with stack-based virtual machine systems like the Ethereum Virtual Machine (EVM). Although not designed specifically for EVMs, Push 3’s simplicity and flexibility make it conceptually compatible with blockchain execution environments. Push 3 has achieved milestones such as evolving [programs for quantum computers](https://faculty.hampshire.edu/lspector/aqcp/) and supporting autoconstructive evolution. A Push 3 VM could facilitate the deployment of genetic algorithms in decentralized systems, leveraging Push 3’s support for expressive program evolution and adaptive behavior in tasks like resource optimization.
+Through repeated iterations, GAs converge toward optimal or near-optimal solutions, making them highly effective for solving complex, dynamic problems. The [Push 3 language](http://faculty.hampshire.edu/lspector/push3-description.html) by Lee Spector provides a particularly suitable foundation for genetic programming with its stack-based architecture and support for multiple typed stacks. Push 3 has demonstrated powerful capabilities including evolving [programs for quantum computers](https://faculty.hampshire.edu/lspector/aqcp/) and supporting autoconstructive evolution. Its design principles make it well-suited for implementation within zero-knowledge virtual machines, where its stack-based operations can be efficiently encoded as cryptographic constraints.
 
 ## On Agents
 
-An agent is defined as an entity capable of perceiving its environment, processing information, and taking autonomous actions to achieve specific objectives. LLMs can be structured into agents using frameworks that provide memory and feedback loops, but they do not fit on-chain and, at the same time, cannot securely manage secrets like private keys. Without either of these capabilities, LLM-based agents require external key management, increasing risks and undermining decentralized security principles. In contrast, genetic algorithms exhibit agentic characteristics by evolving their behavior over time to meet specific goals. When deployed on-chain within smart contracts, GAs can autonomously adapt to real-time inputs and optimize decisions, all while operating entirely within the secure and deterministic framework of blockchain systems.
+An agent is defined as an entity capable of perceiving its environment, processing information, and taking autonomous actions to achieve specific objectives. LLMs can be structured into agents using frameworks that provide memory and feedback loops, but they do not fit on-chain and, at the same time, cannot securely manage secrets like private keys. Without either of these capabilities, LLM-based agents require external key management, increasing risks and undermining decentralized security principles. In contrast, genetic algorithms exhibit agentic characteristics by evolving their behavior over time to meet specific goals. In the Sovraigns architecture, GAs execute off-chain with zero-knowledge proofs, enabling them to adapt to real-time inputs and optimize decisions while maintaining verifiable correctness and privacy.
 
 ---
 
 ## **Genetic Algorithms vs. LLMs for Decentralized Systems**
 
-1. **Efficiency and Feasibility for Blockchain Execution**
+| **Aspect** | **Large Language Models (LLMs)** | **Genetic Algorithms (GAs)** |
+|---|---|---|
+| **Computational Requirements** | Resource-intensive, requires GPUs and large memory | Lightweight, runs on standard hardware |
+| **Blockchain Compatibility** | Impractical for on-chain execution | Efficient for ZK-proof verification |
+| **Trust Model** | Requires external oracles and APIs | Fully verifiable with cryptographic proofs |
+| **Training/Evolution** | Centralized training on massive datasets | Distributed evolution across populations |
+| **Transparency** | Black box, opaque decision-making | Auditable fitness functions and evolution |
+| **Cost** | High inference costs, API fees | Low computational overhead |
+| **Adaptability** | Fixed after training, requires retraining | Continuous evolution to new conditions |
+| **Determinism** | Non-deterministic outputs | Deterministic with fixed random seeds |
+| **Privacy** | Data sent to external providers | Computation can be done privately |
 
-   - **LLMs are resource-intensive:** The computational complexity and size of LLMs make them impractical for direct execution in decentralized environments, where every operation incurs costs. Running even the simplest inference for an LLM would require off-chain computation and trust in external oracles, undermining decentralization.
+### Why Genetic Algorithms Win for DeFi
-   - **GAs are lightweight:** Genetic algorithms, by design, are computationally efficient. Their iterative, population-based approach to optimization fits naturally into resource-constrained environments. This efficiency ensures GAs can evolve and execute entirely on-chain, preserving transparency and trustless execution.
 
-2. **Evolution vs. Training**
+1. **Verifiability**: Every optimization can be proven correct with ZK proofs
-
+2. **Efficiency**: Orders of magnitude cheaper than LLM inference
-   - **GAs evolve in parallel:** Genetic algorithms enable evolutionary processes to run across distributed populations simultaneously. This parallelism contrasts with the centralized training required for deep neural networks, which demand synchronized computation and significant infrastructure. GAs’ decentralized nature aligns well with blockchain environments.
+3. **Decentralization**: No dependency on centralized AI providers
-
+4. **Adaptability**: Algorithms evolve to match changing market conditions
-   - **Deep neural networks require centralized training:** Neural networks demand substantial computational resources and centralized coordination to train effectively. 
+5. **Transparency**: Clear fitness functions align with protocol goals
-
-3. **Auditability of Evolution vs Training**
-
-   - **Training LLMs is opaque:** The progress of training deep neural networks is often difficult to evaluate and verify because testing its capabilities relies on secret data, which cannot be audited by external parties.
-   - **GAs offer transparent evolution:** Genetic algorithms allow the progress of evolution to be easily audited against a target fitness function. This process is fully observable and can be verified at each step with minimal effort.
 
 ---
 
-## **Theoretical Framework for Decentralized Algorithm Evolution**
+## **Theoretical Framework: Zero-Knowledge Intelligence on Based Rollups**
 
-A protocol providing agents as a service could leverage genetic algorithms to address complex problems within blockchain environments. Read through this [real-life usecase explaining the applicability of agents to DeFi](example.md). Central to such a system would be the development of a Push 3 Virtual Machine (VM), enabling efficient execution of genetic algorithms. An "Optimizer Pool", an network of nodes could collaboratively train and evolve these algorithms offchain. These nodes would compete to improve the fitness of the algorithms. Once an improvement, a measuruable better solution to the fitness function is found in off-chain computation, a node would submit it to be accepted into the population of solutions registered on chain, in exchange for a rewards payment by the protocol. The nodes of the optimizer pool would run under an incentivization model simira to proof-of-work systems.
+Sovraigns combines genetic programming with zero-knowledge proofs and based rollups to create the first truly decentralized intelligence layer for DeFi. The system leverages a custom Push 3 VM implementation in OpenVM for verifiable execution, with all coordination happening on a based rollup that inherits Ethereum's security.
 
-![Components](/components.png)
+### Architecture Overview
+
+The protocol operates across three layers:
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                        ETHEREUM L1                              │
+│  • Final Settlement  • Proof Verification  • Protocol Updates   │
+└────────────────────────────┬───────────────────────────────────┘
+                             │ State Bridge
+┌────────────────────────────┴───────────────────────────────────┐
+│                      BASED ROLLUP (Sidechain)                  │
+│  • Task Registry    • Algorithm Storage    • Coordination      │
+│  • Reward Pools     • Version History      • Batch Requests    │
+└────────────────────────────┬───────────────────────────────────┘
+                             │ ZK Proofs
+┌────────────────────────────┴───────────────────────────────────┐
+│                     OFF-CHAIN COMPUTE                          │
+│  • Algorithm Evolution  • OpenVM Execution  • Proof Generation │
+│  • Council Validation   • Optimizer Competition                │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+| **Layer** | **Purpose** | **Key Components** |
+|---|---|---|
+| **Ethereum L1** | Final settlement and security | Smart contracts, State verification |
+| **Based Rollup** | Decentralized coordination | Task registry, Algorithm storage |
+| **Off-Chain** | Computation and evolution | OpenVM, Genetic algorithms, ZK proofs |
+
+### Based Rollup: Decentralized Coordination
+1. **Task Registration**: DeFi protocols register optimization tasks on the based rollup, including:
+   - Fitness functions (optimization goals)
+   - Evaluation parameters and constraints
+   - Reward pools for successful optimizations
+
+2. **Algorithm Registry**: The best algorithms for each task are registered on-chain after council validation
+   - Algorithm hashes stored on-chain for verification
+   - ZK proofs verify the exact algorithm (matching hash) was executed
+   - Version history maintained for auditability
+   - Permissionless access for all protocols
+
+3. **Execution Requests**: When protocols need optimization:
+   - Send request to based rollup with current data
+   - Request triggers off-chain execution
+   - Multiple requests batched for efficiency
+
+### Off-Chain: Evolution and Zero-Knowledge Execution
+1. **Algorithm Evolution**:
+   - Optimizers run genetic algorithms using standard Push 3 implementations
+   - Evolution happens on local high-performance infrastructure
+   - Best solutions submitted to council for validation
+   - No ZK proofs needed during evolution phase
+
+2. **Zero-Knowledge Proof Generation** (triggered by on-chain requests):
+   - Registered algorithms execute in OpenVM with request data
+   - OpenVM verifies the algorithm matches the on-chain hash
+   - STARK proofs generated via Plonky3
+   - Proofs include complete execution trace and results
+   - Multiple proofs batched into rollup blocks
+
+3. **Council Validation**: 
+   - Distributed validators verify algorithm improvements
+   - Consensus required before on-chain registration
+   - Ensures quality without centralized control
+
+### L1 Integration: Trustless Protocol Updates
+1. **State Bridge**: Based rollup posts state roots to Ethereum
+2. **Proof Verification**: Smart contracts verify STARK proofs
+3. **Action Execution**: DeFi protocols execute optimizations based on verified results
+
+### Key Components
+- **Registry (based rollup)**: Task and algorithm management with ZK verification
+- **OpenVM Runtime**: Custom Push 3 implementation for genetic programming
+- **Optimizers (off-chain)**: Compete to evolve better solutions
+- **Council (distributed)**: Validates algorithm quality before registration
+- **Proof Aggregator**: Batches multiple ZK proofs for efficient verification
+- **State Bridge**: Synchronizes rollup state with Ethereum L1
+
+This framework integrates off-chain computation with on-chain validation and deployment, ensuring scalable, transparent optimization. By decentralizing the process, it aligns incentives and fosters continuous improvement tailored to real-world DeFi needs. Ultimately, this system creates a foundation for scalable agent development, aligning with the broader concept of agents as a service, where users and protocols in DeFi can deploy and leverage optimized, evolving AI-agents tailored to specific tasks.
 
-To evaluate the effectiveness of distributed evolution, a "Council" mechanism needs to be created. This Council would consist of validators who execute the latest evolved algorithms and assess their performance against a predefined target fitness function. Validators would then cast votes on whether the new algorithms deliver measurable improvements. This transparent voting process ensures that only the most effective solutions are rewarded and integrated, fostering trust and collaboration across the Optimizer Pool. By aligning incentives with measurable progress, such a framework provides a reliable and decentralized method for advancing algorithmic evolution.
 
-Ultimately, this system creates a foundation for scalable agent development, aligning with the broader concept of agents as a service, where users and protocols in DeFi can deploy and leverage optimized, evolving algorithms tailored to specific tasks.