updates current docs to reflect recent changes to our contracts and the coprocessor now that they're tied together

docs/src/SUMMARY.md

@@ -18,6 +18,8 @@
   - [Sparse Merkle Trees](./zk/05_sparse_merkle_trees.md)
   - [Guest Environment](./zk/06_guest_environment.md)
   - [State Encoding and Encoders](./zk/07_state_encoding_and_encoders.md)
+  - [Domain Proofs](./zk/08_domain_proofs.md)
+
 - [Authorization & Processors](./authorizations_processors/_overview.md)
   - [Assumptions](./authorizations_processors/assumptions.md)
   - [Authorization Contract](./authorizations_processors/authorization_contract.md)

docs/src/authorizations_processors/_overview.md

@@ -1,13 +1,14 @@
 # Authorization & Processors
 
-The **Authorization** and **Processor** contracts are foundational pieces of the **Valence Protocol**, as they enable on-chain (and cross-chain) execution of **Valence Programs** and enforce access control to the program's **Subroutines** via **Authorizations**.
+The Authorization and Processor contracts are foundational pieces of the Valence Protocol, as they enable execution of Valence Programs and enforce access control to the program's Subroutines via Authorizations.
 
-This section explains the rationale for these contracts and shares insights into their technical implementation, as well as how end-users can interact with **Valence Programs** via **Authorizations**.
+This section explains the rationale for these contracts and shares insights into their technical implementation, as well as how end-users can interact with Valence Programs via Authorizations.
 
 ## Rationale
 
-- To have a general purpose set of smart contracts that provide users with a single point of entry to interact with the Valence Program, which can have libraries and accounts deployed on multiple chains.
-- To have all the user authorizations for multiple domains in a single place, making it very easy to control the application.
-- To have a single address (Processor) that will execute the messages for all the contracts in a domain using execution queues.
-- To only tick a single contract (Processor) that will go through the queues to route and execute the messages.
+- To provide users with a single point of entry to interact with the Valence Program through controlled access to library functions.
+- To centralize user authorizations and permissions, making it easy to control application access.
+- To have a single address (Processor) that will execute the authorized messages. On CosmWasm this uses execution queues and permissionless ticks; on EVM the Lite Processor executes immediately (no queues).
 - To create, edit, or remove different application permissions with ease.
+
+Note: Programs can optionally include libraries and accounts deployed across multiple domains for certain multi-chain scenarios.

docs/src/authorizations_processors/assumptions.md

@@ -2,7 +2,7 @@
 
 - **Funds**: You cannot send funds with the messages.
 
-- **Bridging**: We are assuming that messages can be sent and confirmed bidirectionally between domains. The Authorization contract on the main domain communicates with the processor in a different domain in one direction and the callback confirming the correct or failed execution in the other direction.
+- **Bridging**: For programs that optionally span multiple domains, we assume that messages can be sent and confirmed bidirectionally between domains. The Authorization contract on the main domain communicates with the processor in a different domain in one direction and the callback confirming the correct or failed execution in the other direction.
 
 - **Instantiation**: All these contracts can be instantiated beforehand and off-chain having predictable addresses. Here is an example instantiation flow using Polytone:
   - Predict `authorization` contract address.

docs/src/authorizations_processors/authorization_contract.md

@@ -1,5 +1,23 @@
 # Authorization Contract
 
-The Authorization contract will be a single contract deployed on the main domain and that will define the authorizations of the top-level application, which can include libraries in different domains (chains). For each domain, there will be one Processor in charge of executing the functions on the libraries. The Authorization contract will connect to all of the Processor contracts using a connector (e.g. Polytone Note, Hyperlane Mailbox…) and will route the message batches to be executed to the right domain. At the same time, for each external domain, we will have a proxy contract (e.g. Polytone Proxy, Hyperlane Mailbox...) in the main domain which will receive the callbacks sent from the processor on the external domain with the `ExecutionResult` of the `MessageBatch`.
+The Authorization contract serves as the authority and message routing hub for Valence Programs. It supports two distinct authorization mechanisms: standard authorizations for traditional access control and ZK authorizations for zero-knowledge proof–based execution.
 
-The contract will be instantiated once at the very beginning and will be used during the entire top-level application lifetime. Users will never interact with the individual Smart Contracts of each program, but with the Authorization contract directly.
+A Valence Program has one Authorization contract and one Processor contract per domain. The Authorization contract defines authorizations that control access to library functions within the program. The contract validates user permissions and routes authorized messages to the associated Processor contract for execution.
+
+## Standard Authorizations
+
+Standard authorizations use a label-based system with different authorization modes.
+
+- CosmWasm: Permissionless authorizations allow anyone to execute (default Medium priority). Permissioned authorizations are enforced with per‑label TokenFactory tokens. With call limit, one token is consumed (burned on success, refunded on failure) per execution; without call limit, holding one token suffices. Tokens use `factory/{authorization_contract}/{label}` and enable on-chain transferability.
+- EVM: Permissioned access is enforced per label with address allowlists and function‑level constraints. For each label, the contract stores an array of AuthorizationData entries containing the target contract address and either the function selector or a call hash. No tokens are minted; authorization is purely address/function based.
+
+For standard message execution, the contract validates sender permissions and authorization state, ensures the message(s) align with the label’s subroutine configuration, routes the message to the Processor, and processes callbacks. On CosmWasm, token mint/burn/refund applies for call‑limited flows.
+
+## ZK Authorizations
+
+ZK authorizations enable proof‑based execution via a registry‑keyed configuration. Each registry stores allowed execution addresses, a verification key, a verification route (for a VerificationRouter), optional last‑block validation for replay prevention, and a metadata hash linking the VK to the program.
+
+- EVM: Users call `executeZKMessage(bytes inputs, bytes proof, bytes payload)`. The Authorization verifies sender allowance, optional replay protection, then routes to the `VerificationRouter.verify(route, vk, proof, inputs, payload)`. On success, it injects the current `executionId` into SendMsgs/InsertMsgs and forwards to the Processor.
+- CosmWasm: Users call `ExecuteZkAuthorization { label, inputs, proof, payload }`. The Authorization verifies sender allowance and optional last‑block execution checks, uses the configured verification route, and forwards the decoded Processor message.
+
+Note: CosmWasm cross‑domain routing uses Polytone (CosmWasm↔CosmWasm). EVM cross‑domain routing uses Hyperlane mailboxes. Both environments support callbacks to the Authorization for execution results.

docs/src/authorizations_processors/authorization_instantiation.md

@@ -1,11 +1,23 @@
 # Instantiation
 
-When the contract is instantiated, it will be provided the following information:
+Instantiation parameters vary slightly between CosmWasm and EVM.
 
-- Processor contract on main domain.
+## CosmWasm
 
-- Owner of the contract.
+The Authorization contract is instantiated with:
 
-- List of subowners (if any). Users that can execute the same actions as the owner except adding/removing other subowners.
+- Processor contract address on the main domain
+- Owner address
+- Optional list of sub‑owners (second‑tier owners who can perform all actions except sub‑owner management)
 
-Once the Authorization contract is deployed, we can already start adding and executing authorizations on the domain that the Authorization contract was deployed on. To execute functions on other domains, the owner will have to add external domains to the Authorization contract with all the information required for the Authorization contract to route the messages to that domain.
+Once deployed, authorizations can be created and executed on the main domain. To execute on other domains, the owner adds external domains with connector details (Polytone for CosmWasm domains; Hyperlane + encoder info for EVM domains).
+
+## EVM
+
+`constructor(address owner, address processor, bool storeCallbacks)`
+
+- `owner`: the contract owner (Ownable)
+- `processor`: the Processor contract address
+- `storeCallbacks`: whether to persist processor callbacks on‑chain (otherwise only events are emitted)
+
+EVM does not use sub‑owners; instead, the owner can add or remove admin addresses that are permitted to perform privileged updates. Cross‑domain routing is handled via Hyperlane mailboxes (set during Processor deployment), not at Authorization instantiation time.

docs/src/authorizations_processors/authorization_owner_actions.md

@@ -1,5 +1,9 @@
 # Owner Functions
 
+This page lists owner/admin actions. Items are grouped by execution environment when behavior differs.
+
+## CosmWasm
+
 - `create_authorizations(vec[Authorization])`: provides an authorization list which is the core information of the Authorization contract, it will include all the possible set of functions that can be executed. It will contain the following information:
 
   - Label: unique name of the authorization. This label will be used to identify the authorization and will be used as subdenom of the tokenfactory token in case it is permissioned. Due to tokenfactory module restrictions, the max length of this field is 44 characters.
@@ -69,3 +73,23 @@
 - `add_sub_owners(vec[addresses])`: add the current addresses as 2nd tier owners. These sub_owners can do everything except adding/removing admins.
 
 - `remove_sub_owners(vec[addresses])`: remove these addresses from the sub_owner list.
+
+- ZK‑specific owner actions:
+  - `create_zk_authorizations(vec[ZkAuthorization])`: add ZK registries with VK, allowed execution addresses, route, metadata hash, and optional last‑block validation.
+  - `modify_zk_authorization { label, validate_last_block_execution }`: enable/disable last‑block execution validation for a registry.
+  - `set_verification_router(address)`: set the on‑chain verification router address.
+  - `update_zk_authorization_route { label, new_route }`: update the verifier route for a registry.
+
+## EVM
+
+- Standard authorization admin:
+  - `addStandardAuthorizations(string[] labels, address[][] users, AuthorizationData[][] data)`
+  - `removeStandardAuthorizations(string[] labels)`
+- Processor/admin management:
+  - `updateProcessor(address)`
+  - `addAdminAddress(address)` / `removeAdminAddress(address)`
+- ZK authorization admin:
+  - `addRegistries(uint64[] registries, ZkAuthorizationData[] data)`
+  - `updateRegistryRoute(uint64 registryId, string route)`
+  - `removeRegistries(uint64[] registries)`
+  - `setVerificationRouter(address)`

docs/src/authorizations_processors/authorization_user_actions.md

@@ -1,9 +1,15 @@
 # User Actions
 
+## CosmWasm
+
 - `send_msgs(label, vec[ProcessorMessage])`: users can run an authorization with a specific label. If the authorization is `Permissioned (without limit)`, the Authorization contract will check if their account is allowed to execute by checking that the account holds the token in its wallet. If the authorization is `Permissioned (with limit)` the account must attach the authorization token to the contract execution. Along with the authorization label, the user will provide an array of encoded messages, together with the message type (e.g. `CosmwasmExecuteMsg`, `EvmCall`, etc.) and any other parameters for that specific ProcessorMessage (e.g. for a `CosmwasmMigrateMsg` we need to also pass a code_id). The contract will then check that the messages match those defined in the authorization, that the messages appear in correct order, and that any applied parameter restrictions are correct.
 
   If all checks are correct, the contract will route the messages to the correct Processor with an `execution_id` for the processor to callback with. This `execution_id` is unique for the entire application.
   If execution of all actions is confirmed via a callback, the authorization token is burned. If execution fails, the token is sent back.
   Here is an example flowchart of how a user interacts with the Authorization contract to execute functions on an external CosmWasm domain that is connected to the main domain with Polytone:
 
 ![User flowchart](../img/user_flowchart.png)
+
+## EVM
+
+- `sendProcessorMessage(string label, bytes message)`: users submit an ABI‑encoded `ProcessorMessage` (as defined in `IProcessorMessageTypes`) with the target label. The contract verifies the sender against the label’s allowlist and validates the messages against the subroutine’s function set (contract address + function selector or call hash). For SendMsgs/InsertMsgs, the Authorization injects the current `executionId` before forwarding to the Processor. There is no tokenization on EVM; authorization is address/function constrained.

docs/src/authorizations_processors/connectors.md

@@ -1,6 +1,6 @@
 # Connectors
 
-Connectors are a way for the Authorization contract in the main domain to interact with external domains. When adding an `ExternalDomain` to the Authorization contract, depending on the `ExecutionEnvironment` we must specify the Connector information to be used. These connectors are responsible for receiving the message batches from the Authorization contract and trigger the necessary actions for the relayers to pick them up and deliver them to the Processor contract in the `ExternalDomain`. The connector on the `ExternalDomain` will also receive callbacks with the `ExecutionResult` from the Processor contract and send them back to the Authorization contract.
+Connectors enable the Authorization contract to optionally communicate with external domains for advanced multi-chain programs. When adding an `ExternalDomain` to the Authorization contract, depending on the `ExecutionEnvironment` we must specify the Connector information to be used. These connectors are responsible for receiving the message batches from the Authorization contract and trigger the necessary actions for the relayers to pick them up and deliver them to the Processor contract in the `ExternalDomain`. The connector on the `ExternalDomain` will also receive callbacks with the `ExecutionResult` from the Processor contract and send them back to the Authorization contract.
 
 We currently support the following connectors:
 

docs/src/authorizations_processors/encoding.md

@@ -1,6 +1,6 @@
 # Encoding
 
-When messages are passed between the Authorization contract and a Processor contract on a domain that is not using a CosmWasm `ExecutionEnvironment`, we need to encode the messages in a way that the Processor contract and the Libraries it calls can understand them. To do this two new contracts were created: `Encoder Broker` and `Encoder`.
+When a Valence Program needs to communicate with a Processor contract on a non-CosmWasm execution environment, messages must be encoded appropriately for that environment. Two contracts handle this encoding: `Encoder Broker` and `Encoder`.
 
 ## Encoder Broker