docs(edits): edit docs to update circuit

docs/docs/develop/solana-avs-mainnet.md

@@ -33,7 +33,7 @@ cargo install --git https://github.com/composableFi/emulated-light-client --bran
 2. Check if the validator CLI is installed using the following command. The current version should be returned as a value indicating successful installation.
 ```
 validator --version
-> 0.0.1
+> 0.0.5
 ```
 3. Set up the rpc url with your validator keypair using the command below (note that the program ID is already added). Use a custom 
 rpc since the Solana public rpc is not good enough to send transactions and will usually be dropped frequently. Keypair path is the path to your keypair json file. [For Example](https://github.com/ComposableFi/emulated-light-client/blob/2313bbd4c1f838ce36b894e781ede5eb63b7c698/solana/solana-ibc/keypair.json)
@@ -59,8 +59,7 @@ The token address can be any one of the whitelisted tokens under the restaking l
 Validator stake -a 25000000000 -t <token-address> —rpc-url <RPC_URL> --ws-url <WS_URL> --program-id <PROGRAM_ID> --keypair-path <KEYPAIR_PATH>
 ```
 
-
-1. Once the config file is set, run the validator: 
+5. Once the config file is set, run the validator: 
 ```
 validator run
 ```

docs/docs/technology/ibc.md

@@ -13,13 +13,13 @@ In every communication between two applications, there is a **relayer**, an off-
 To implement IBC on a blockchain, various components are required. This section highlights three essential components. First, an implementation of the IBC protocol in the programming language that the underlying blockchain uses. Second, a light client and finally, you'll need an IBC-Relayer designed to be compatible with the chain.
 
 ### IBC Implementations
-This refers to the connection and packet level integration of the IBC implementation. It enables the protocol to establish handshake-based connections to securely process and interpret IBC opaque data packets between different blockchains. In production, there are only two implementations of this core IBC functionality. The first implementation is the original `ibc-go`, which is specifically designed for Cosmos SDK chains written in Golang. The second implementation is [`ibc-rs`](https://github.com/ComposableFi/centauri/tree/master/ibc/modules), an implementation of the IBC protocol for Rust based blockchains. It's worth noting that, among all the IBC-enabled chains in production, the majority use `ibc-go`, with the exceptions being Composable Polkadot, Picasso, and Composable Cosmos.
+This refers to the connection and packet level integration of the IBC implementation. It enables the protocol to establish handshake-based connections to securely process and interpret IBC opaque data packets between different blockchains. In production, there are three implementations of this core IBC functionality. The first implementation is the original `ibc-go`, which is specifically designed for Cosmos SDK chains written in Golang. The second is [`ibc-rs`](https://github.com/ComposableFi/centauri/tree/master/ibc/modules), an implementation of the IBC protocol for Rust based blockchains and currently live on Polkadot. The third is `ibc-solidity`, implemented for Ethereum and EVM interactions. It's worth noting that, among all the IBC-enabled chains in production, the majority use `ibc-go`, with the exceptions being the networks Picasso has extended IBC to - Ethereum, Solana, Composable Polkadot and Picasso Kusama.
 
 ### [Light Clients](./ibc/light-clients.md) 
 
 Light clients serve as a lightweight, trustless mechanism for verifying the state of connected blockchains. They are essential components of the IBC protocol as they facilitate secure and efficient cross-chain interactions without the necessity of fully synchronizing and managing the complete history of every connected blockchain. Composable possesses extensive experience in writing multiple light clients for various blockchains with the intention of enabling communication via the IBC protocol.
 
-Composable's implementation of IBC on Picasso and Composable utilizes the [grandpa light client](https://github.com/ComposableFi/centauri/tree/master/light-clients/ics10-grandpa). The Grandpa protocol is Polkadot and Kusama's consensus mechanism used to finalize blocks on its relay chains. `GRANDPA` enables the verification of finality proofs of Parachain headers. 
+The implementation of IBC on Picasso Kusama and Composable Polkadot utilizes the [grandpa light client](https://github.com/ComposableFi/centauri/tree/master/light-clients/ics10-grandpa). The Grandpa protocol is Polkadot and Kusama's consensus mechanism used to finalize blocks on its relay chains. `GRANDPA` enables the verification of finality proofs of Parachain headers. 
 
 The `ICS-8 client` enables light client implementations written in CosmWasm to run natively on blockchains built with the Cosmos SDK. The Grandpa light client is constructed using the `GRANDPA` protocol and written in CosmWasm, therefore, enabling the tracking of finality for Polkadot and Kusama parachains on Cosmos chains through CosmWasm contracts.
 

docs/docs/technology/ibc/ethereum.md

@@ -17,29 +17,17 @@ Composable has made substantial progress in developing light clients for network
 Casper is Ethereum's PoS consensus protocol implemented within ETH 2.0. In Casper, validators participate in block creation and validation based on the amount of stake they lock up as collateral. This PoS system was adopted to enhance the security, scalability, and energy efficiency of Ethereum by reducing the need for computationally intensive mining while rewarding validators with transaction fees.
 :::
 
-The Casper Light Client relies on the **Sync Committee**, which comprises 512 validators who undergo random selection once every sync committee period, approximately equal to one day. While a validator is actively participating in the sync committee, their primary responsibility entails consistently signing the block header representing the current chain head during each slot. The Sync Committee is a succinct way of getting a sample to verify a subset of the signatures of Ethereum. 
+The Casper Light Client relies on the **Sync Committee**, which comprises 512 validators who undergo random selection once every sync committee period, approximately equal to one day. While a validator is actively participating in the sync committee, their primary responsibility entails consistently signing the block header representing the current chain head during each slot. The Sync Committee is a succinct way of using a sample to verify a subset of the signatures of Ethereum. 
 
-A Tendermint light client is deployed on Ethereum as a smart contract and responsible for verifying the validity of block headers from Picasso and ensuring that the consensus state of the source blockchain is consistent with the header being presented. These headers contain data such as block hashes, timestamps, and state roots. It will be too expensive to verify signatures from  the validator set of Picasso, therefore, ZK-Snarks are used to verify all signatures in succinct proofs. Read more on light clients [here](light-clients.md).
+Previously, validating the Tendermint consensus protocol within the EVM posed a challenge due to the absence of an Ed25519 precompile, the default signature scheme used in Cosmos chains using the Tendermint consensus. Existing Solidity implementations for this verification incurred gas costs averaging around 25 million. However, zero-knowledge proofs serve as a precompile for the EVM, enabling developers to integrate highly intricate computations seamlessly. Picasso's zkIBC bridge to Ethereum employs [TendermintX](https://github.com/succinctlabs/tendermintx) to verify all signatures in succinct proofs. 
 
-## ZK Circuit
-Wthin the [Hyperspace](hyperspace-relayer.md) operation on Ethereum, a **zero-knowledge (ZK) circuit** is employed to optimise and sustain the cost of the relayer. A ZK circuit is a program capable of generating a proof when given a set of inputs. This proof can then be verified to ensure the correctness of each computational step executed within the circuit. 
-
-The ZK circuit involves a **prover** and **verifier**. Similar to Hyperspace, the prover is a permissionless off-chain component that anyone can run. The verifier lives on-chain as a smart contract on Ethereum. The role of the verifier is to verify proofs submitted by the prover, in this case, a succinct proof of client updates from the Composable Cosmos chain.
-
-:::tip
-Verifiers receive proofs from provers and subsequently validate these claims, resulting in the generation of zero-knowledge proofs. For an in-depth explanation of this process, [read here](https://ethereum.org/en/developers/docs/zksnarks).
-:::
-
-In particular, the IBC connection to Ethereum currently operates with a Groth16 SNARK circuit specialized in verifying signatures of the Ed25519 signature scheme. The proving times stand at 2 minutes, thanks to Rapid SNARK, an accelerated prover software.
+The deployment of smart contracts and circuits by Succinct for TendermintX is operational in production, with each client update for the IBC implementation on Ethereum costing approximately 650,000 gas. These client updates include headers of Picasso and data such as block hashes, timestamps, and state roots. 
 
 :::info
 The Ed25519 signature scheme is a cryptographic algorithm used for digital signatures and adopted by majority of Blockchains. It is based on the elliptic curve cryptography and provides strong security with relatively short key sizes. The scheme is named after the Edwards curve Curve25519, which is used as the underlying mathematical structure. Ed25519 offers efficient signing and verification operations, making it popular for various applications such as secure communication protocols, cryptocurrencies, and digital authentication systems.
 :::
 
-In the next release, Succinct Lab's TendermintX ZK Tendermint light client circuit designed will be integrated to enhance the efficiency of relaying costs and accelerate client update speeds on Ethereum.
-
 ## IBC implementation in Solidity
 Building upon the existing IBC implementation in Solidity by [Hyperledger Labs](https://github.com/hyperledger-labs/yui-ibc-solidity), the contracts that have been deployed are optimised for a production-ready environment tailored for Ethereum. 
 
 The ownership of the IBC contracts deployed on Ethereum for Picasso is presently held by a [team multisig wallet](https://etherscan.io/address/0xcbcfccb93b14e5cc55917a56f67f419f259e0813), with plans to transition control to PICA governance in the forthcoming release. This decision reflects the unprecedented nature of implementing IBC for the first time on Ethereum, emphasizing the need for a stable initial launch. Updates regarding any contract upgrades will be shared in our Discord community.
-

docs/docs/technology/restaking/sol-ibc-avs.md

@@ -32,7 +32,7 @@ Validators produce blocks with state proofs, relayed to the counterparty chain.
 The validator network will be directed by majority where it is the responsibility of active validators to maintain uptime and sign corresponding payloads of transactions.
 
 #### Bonding
-Joining as a validator will require a bonded stake to keep participation gated from malicious actors easily onboarding. The size of the bond will be 500 SOL.
+Joining as a validator will require a bonded stake to keep participation gated from malicious actors easily onboarding. The size of the bond will be 25 SOL.
 
 #### (Re) Staking
 The validator set will be able to utilize liquid staking derivatives (LSD) of SOL, as well as LP tokens for this initiative. The following assets will be deemed acceptable collateral for staking as a validator: SOL, mSOL, jitoSO and bSOL.