docs: final doc version, extend EVM flow documentation

README.md

@@ -7,6 +7,6 @@ Valence programs use a resource model to structure control flow, compiling to ta
 
 ## Status
 
-This project is under heavy development, however portions of the toolchain have stabilized to build programs for cross-chain liquidity deployment and multi-party agreements. Programs may be written in a constrained configuration language or using rust, though developer documentation for the latter is currently quite sparse.
+While this project is no longer under active development, portions of the toolchain have stabilized to build programs for cross-chain liquidity deployment and multi-party agreements. Programs may be written in a constrained configuration language or using rust, though developer documentation for the latter is currently quite sparse.
 
-Valence currently supports connections to Cosmos and EVM domains, with SVM coming soon. Programs currently compile to WASM, with planned support for RISC zk circuits.
+Valence supports connections to Cosmos and EVM domains. Programs currently compile to WASM with support of SP1 zk circuits using the ZK Coprocessor.

docs/src/SUMMARY.md

@@ -9,7 +9,6 @@
     - [Interchain Accounts](./accounts/interchain_accounts.md)
   - [Libraries and Functions](./components/libraries_and_functions.md)
   - [Programs and Authorizations](./components/programs_and_authorizations.md)
-  - [Middleware](./components/middleware.md)
 - [Valence ZK System](./zk/_overview.md)
   - [System Overview](./zk/01_system_overview.md)
   - [Developing Coprocessor Apps](./zk/02_developing_coprocessor_apps.md)
@@ -26,6 +25,7 @@
     - [Instantiation](./authorizations_processors/authorization_instantiation.md)
     - [Owner Actions](./authorizations_processors/authorization_owner_actions.md)
     - [User Actions](./authorizations_processors/authorization_user_actions.md)
+    - [EVM](./authorizations_processors/evm_authorization_contract.md)
   - [Processor Contract](./authorizations_processors/processor_contract.md)
     - [Processor](./authorizations_processors/processor.md)
     - [Lite Processor](./authorizations_processors/lite_processor.md)
@@ -94,5 +94,3 @@
   - [Example without Program Manager](./testing/without_program_manager.md)
   - [Example with Program Manager](./testing/with_program_manager.md)
 - [Security](./security.md)
-- [Deployment](./deployment/_overview.md)
-  - [Local Deployment](./deployment/local.md)

docs/src/authorizations_processors/authorization_instantiation.md

@@ -21,3 +21,5 @@ Once deployed, authorizations can be created and executed on the main domain. To
 - `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.
+
+For more information on how to deploy and interact with the EVM authorization contract, check the [EVM Authorization contract section](./evm_authorization_contract.md).

docs/src/authorizations_processors/evm_authorization_contract.md

@@ -0,0 +1,67 @@
+# EVM Authorization Contract
+
+If a general message passing protocol like Hyperlane wants to be avoided to not require the deployment of additional infrastructure, we also provide a Solidity version of the Authorization contract with similar functionality than the CosmWasm version.
+
+These are the steps to set up our EVM program using the EVM Authorization contract instead of Hyperlane:
+
+1) Deploy `Authorization.sol` providing the program owner, the lite processor address (previously deployed) and a flag specifying if we want to store the callbacks in the contract state or just emit them as events (less gas consumption):
+
+```solidity
+constructor(address _owner, address _processor, bool _storeCallbacks) Ownable(_owner)
+```
+
+2) Once it's deployed, we need to set the authorization contract as an authorized address on the processor.
+
+```solidity
+function addAuthorizedAddress(address _address)
+```
+
+This will allow processing the messages that the newly deployed authorization contract will forward to the processor.
+
+3) Now we can start adding our authorizations:
+
+```solidity
+ /**
+     * @notice Adds standard authorizations for a specific label
+     * @dev Can only be called by the owner
+     * @param _labels Array of labels for the authorizations
+     * @param _users Array of arrays of user addresses associated with each label
+     * @param _authorizationData Array of arrays of authorization data associated with each label
+     */
+    function addStandardAuthorizations(
+        string[] memory _labels,
+        address[][] memory _users,
+        AuthorizationData[][] memory _authorizationData
+    )
+```
+
+This method allows adding multiple authorizations at the same time using arrays, to optimize the gas consumption. The most important part here is the `AuthorizationData`, which is defined as follows:
+
+```solidity
+    /**
+     * @notice Structure representing the data for the authorization label
+     * @dev This structure contains the contract address and the function signature hash
+     * @param contractAddress The address of the contract that is authorized to be called
+     * @param useFunctionSelector Boolean indicating if the function selector should be used instead of callHash
+     * @param functionSelector The function selector of the function that is authorized to be called
+     * @param callHash The function signature hash of the function that is authorized to be called
+     */
+    struct AuthorizationData {
+        address contractAddress;
+        bool useFunctionSelector;
+        bytes4 functionSelector;
+        bytes32 callHash;
+    }
+```
+
+As explained above, we have two ways of defining our authorization: using the function selector or a callHash. If we use a function selector, the authorized address is allowed to execute that specific function with **ANY** arguments. For example, if the function is `transfer(uint256 amount)` the address can specify any amount value when calling the authorization. On the other hand, if we want to restrict the call to a specific value, we provide the call hash so that only those specific call bytes can be executed. For example, we compute the `keccak256` hash of the encoded call data (e.g., `abi.encodeWithSignature("transfer(uint256)", 1000)`) and provide that as the `callHash`. Then the authorized address can **ONLY** call this authorization with that specific value. 
+
+As we can see this is less flexible than the CosmWasm version due to the nature of the Solidity language vs Rust but tends to be enough for most of the programs. If more flexibility is required, the option of using a message passing protocol with our encoding/decoding mechanisms or using the ZK Coprocessor is also available.
+
+4) Now that everything is set up, we can execute our authorization like this:
+
+```solidity
+function sendProcessorMessage(string calldata label, bytes calldata _message) 
+```
+
+We simply need to specify what label we want to execute and the encoded `ProcessorMessage` that will be forwarded to the Processor. This performs all the checks against our AuthorizationData, and if they all pass, the message will be forwarded to the processor, executed, and a callback will be received on the Authorization contract.

docs/src/components/_overview.md

@@ -8,7 +8,6 @@ Valence currently supports CosmWasm and EVM. SVM support coming soon. The rest o
     - [Accounts](../accounts/_overview.md)
     - [Libraries and Functions](./libraries_and_functions.md)
     - [Programs and Authorizations](./programs_and_authorizations.md)
-    - [Middleware](./middleware.md)
 
 2. **Off-chain Execution via ZK Coprocessor**:
 Early specifications for the [Valence ZK System](./../zk/_overview.md). We aim to move as much computation off-chain as possible since off-chain computation is a more scalable approach to building a cross-chain execution environment.

docs/src/introduction.md

@@ -1,7 +1,5 @@
 # Introduction
 
-> 🚧 Valence Protocol architecture and developer documentation is still evolving rapidly. Portions of the toolchain have stabilized to build cross-chain vaults, and extending vaults with multi-party agreements. Send us a message on [X](https://x.com/valencezone) if you'd like to get started!
-
 **Valence** is a unified development environment that enables building *trust-minimized cross-chain DeFi applications*, called **Valence Programs**.
 
 Valence Programs are:

docs/src/security.md

@@ -1,4 +1,2 @@
 # Security
 Valence Programs have been independently audited. Please find audit reports [here](https://github.com/timewave-computer/valence-protocol/tree/main/audits/).
-
-If you believe you've found a security-related issue with Valence Programs, please disclose responsibly by contacting the Timewave team at [security@timewave.computer](mailto:security@timewave.computer).