chore: update docs (#5140)

Author: hussein-aitlahcen

docs/src/content/docs/ucs/03.mdx

@@ -7,10 +7,9 @@ import Mermaid from "#/components/Mermaid.astro";
 `ucs03-zkgm-0` is the most advanced and recommended protocol to use for
 
 - message passing
-- transfers (assets and NFTs)
+- asset transfers
 - intents
 - storage proofs
-- staking and governance
 
 It's the most gas-efficient version and suitable for almost all use cases.
 
@@ -96,10 +95,8 @@ Each instruction has a version and opcode to allow for protocol evolution.
 Its features include:
 - batching
 - forward/callback envelopes
-- channel multiplexing
-- fungible assets transfer
-- non-fungible assets transfer
-- staking and governance
+- channel routing
+- fungible asset transfers
 
 ## Packet
 
@@ -172,17 +169,12 @@ Fields:
   - 0x01: [Call](#0x01---call)
   - 0x02: [Batch](#0x02---batch)
   - 0x03: [TokenOrder](#0x03---token-order)
-  - 0x04: [Stake](#0x04---stake)
-  - 0x05: [Unstake](#0x05---unstake)
-  - 0x06: [WithdrawStake](#0x06---withdraw-stake)
-  - 0x07: [WithdrawRewards](#0x07---withdraw-rewards)
 
 - `operand`: Instruction-specific data as `bytes`
   - Forward: Path, timeouts and instruction to forward
   - Call: Sender, callback mode and contract call data
   - Batch: Array of instructions to execute atomically
   - TokenOrder: Transfer details like tokens, amounts and parties
-  - Stake/Unstake/WithdrawStake/WithdrawRewards: Staking operation parameters
 
 :::note
 
@@ -280,13 +272,14 @@ Fields:
   - Interpreted by target contract's implementation
   - Available in both standard and eureka modes
 
-The multiplexcall instruction has two modes:
+The Call instruction has two modes:
 
 1. Standard Mode (eureka = false):
    - Target must implement IZkgmable interface
    - Calls `onZkgm(path, sourceChannel, destChannel, sender, calldata)` on target
    - Returns success acknowledgement immediately
    - Fire-and-forget style, no callback to sender
+   - **ProxyAccount Auto-Creation**: If the target address matches a predictable ProxyAccount address derived from the sender, path, and channel, the ProxyAccount is automatically created before the call is executed
 
 2. IBC Mode (eureka = true):
    - Calls `onRecvPacket(packet, relayer, relayerMsg)` on target
@@ -298,6 +291,64 @@ If the target contract is invalid or calls fail:
 - Standard mode returns failure acknowledgement
 - IBC mode propagates target's error response
 
+#### ProxyAccount
+
+ProxyAccount is a smart contract wallet that enables cross-chain account abstraction. It allows users to control accounts on remote chains through the ZKGM protocol.
+
+**Key Features:**
+- **Deterministic Addresses**: ProxyAccount addresses are derived deterministically from the sender address, channel ID and path, ensuring the same sender always gets the same ProxyAccount address
+- **Auto-Creation**: When a Call instruction targets a ProxyAccount address that doesn't exist yet, the protocol automatically deploys it before executing the call
+- **Multi-Admin Support**: Supports both local admins (on the same chain) and remote admins (on other chains)
+- **Upgradeable**: Implements UUPS pattern for upgradeability on EVM
+- **Multicall Support**: Can execute multiple calls in a single transaction
+
+**Address Prediction:**
+```solidity
+function predictProxyAccount(
+    uint256 path,
+    uint32 channel,
+    bytes calldata sender
+) external returns (address, bytes32);
+```
+
+The ProxyAccount address is computed as:
+1. Salt = `keccak256(abi.encode(path, channelId, sender))`
+2. Address = `CREATE3.predictDeterministicAddress(salt)`
+
+**Remote Control:**
+When called via zkgm (eureka = false), the ProxyAccount:
+1. Verifies the caller is the authorized zkgm contract
+2. Checks if the sender is a registered remote admin for the given path/channel
+3. Decodes the message as `(address target, uint256 value, bytes payload)`
+4. Executes the call to the target contract
+
+**Example Usage:**
+```solidity
+// On source chain, prepare a call to be executed via ProxyAccount
+bytes memory proxyCalldata = abi.encode(
+    targetContract,     // Contract to call on destination
+    0,                  // ETH value to send
+    abi.encodeCall(     // The actual function call
+        IERC20.transfer,
+        (recipient, amount)
+    )
+);
+
+// Prepare a call instruction to submit.
+Call memory call = Call({
+    sender: abi.encodePacked(msg.sender),
+    eureka: false,
+    contractAddress: abi.encodePacked(proxyAccountAddress),
+    contractCalldata: proxyCalldata
+});
+```
+
+This enables users to:
+- Own and control accounts on any chain without deploying contracts in advance
+- Execute arbitrary transactions on remote chains
+- Manage assets and interact with DeFi protocols cross-chain
+- Maintain consistent account addresses across deployments
+
 :::tip
 Example of a contract implementing `IZkgmable`:
 ```solidity
@@ -365,13 +416,13 @@ struct Batch {
 
 Fields:
 - `instructions`: Array of [Instructions](#instruction) to execute atomically
-  - Only specific instructions allowed (Call, TokenOrder, Stake, Unstake, WithdrawStake)
+  - Only specific instructions allowed (Call, TokenOrder)
   - Executed in sequential order
   - All must succeed or entire batch reverts
   - Individual acknowledgements collected in array
   - Minimum 2 instructions required
 
-This allows atomic composition of transfers, contract calls, and staking operations in a single transaction.
+This allows atomic composition of transfers and contract calls in a single transaction.
 
 <Mermaid
   content={`
@@ -385,7 +436,7 @@ sequenceDiagram
 
 :::tip
 
-In combination with forward envelopes or multiplexing, this batching mechanism is very useful to call contract before/after message execution (transfer an asset, swap it then stake the final asset).
+In combination with forward envelopes, this batching mechanism is very useful to call contract before/after message execution (transfer an asset, swap it, then execute another operation with the final asset).
 
 :::
 
@@ -962,159 +1013,6 @@ If any of the order in the `orders` list is failing on execution, the whole pack
 
 :::
 
-### 0x04 - Stake
-
-The stake instruction uses opcode `0x04` and requires version `INSTR_VERSION_0`.
-
-```solidity
-struct Stake {
-    uint256 tokenId;                      // NFT token ID for the staking position
-    bytes governanceToken;                // Governance token address
-    bytes governanceTokenWrapped;         // Wrapped governance token address
-    bytes sender;                         // Source chain sender address
-    bytes beneficiary;                    // Address that will receive the staking NFT
-    bytes validator;                      // Validator address to stake with
-    uint256 amount;                       // Amount to stake
-}
-```
-
-The stake instruction allows cross-chain staking of governance tokens with validators. The process:
-1. Tokens are locked on the source chain
-2. Staking is initiated on the destination chain
-3. A staking position NFT is minted to the beneficiary
-4. The NFT represents ownership of the staked position and can be used to manage it
-
-<Mermaid
-  content={`
-sequenceDiagram
-    participant S as Sender
-    participant B as Beneficiary
-    participant Chain1 as Source Chain
-    participant Chain2 as Destination Chain
-    participant V as Validator
-
-    S ->> Chain1: Send Stake Instruction
-    Chain1 ->> Chain1: Lock Governance Tokens
-    Chain1 ->> Chain2: Stake Packet
-    Chain2 ->> V: Delegate Tokens
-    Chain2 ->> Chain2: Mint Staking NFT
-    Chain2 ->> Chain1: Success Acknowledgement
-    Chain1 ->> B: Transfer NFT
-`}/>
-
-### 0x05 - Unstake
-
-The unstake instruction uses opcode `0x05` and requires version `INSTR_VERSION_0`.
-
-```solidity
-struct Unstake {
-    uint256 tokenId;                      // NFT token ID for the staking position
-    bytes governanceToken;                // Governance token address
-    bytes governanceTokenWrapped;         // Wrapped governance token address
-    bytes sender;                         // Source chain sender address
-    bytes validator;                      // Validator address to unstake from
-}
-```
-
-The unstake instruction initiates the unbonding process for staked tokens. When successful:
-1. The staking position enters the UNSTAKING state
-2. The unstakingCompletion time is set
-3. The NFT is returned to the sender
-4. After completion time, tokens can be withdrawn
-
-<Mermaid
-  content={`
-sequenceDiagram
-    participant S as Sender/NFT Owner
-    participant Chain1 as Source Chain
-    participant Chain2 as Destination Chain
-    participant V as Validator
-
-    S ->> Chain1: Send Unstake Instruction
-    Chain1 ->> Chain1: Lock NFT
-    Chain1 ->> Chain2: Unstake Packet
-    Chain2 ->> V: Begin Unbonding
-    Chain2 ->> Chain1: Acknowledgement with Completion Time
-    Chain1 ->> Chain1: Set NFT to UNSTAKING state
-    Chain1 ->> Chain1: Record unstakingCompletion time
-    Chain1 ->> S: Return NFT
-`}/>
-
-### 0x06 - Withdraw Stake
-
-The withdraw stake instruction uses opcode `0x06` and requires version `INSTR_VERSION_0`.
-
-```solidity
-struct WithdrawStake {
-    uint256 tokenId;                      // NFT token ID for the staking position
-    bytes governanceToken;                // Governance token address
-    bytes governanceTokenWrapped;         // Wrapped governance token address
-    bytes sender;                         // Source chain sender address
-    bytes beneficiary;                    // Address that will receive the tokens
-}
-```
-
-The withdraw stake instruction allows a user to claim their tokens after the unbonding period. On success:
-1. The staking position enters the UNSTAKED state
-2. The staked tokens are transferred to the beneficiary
-3. Any rewards are also transferred
-4. If there was slashing, the appropriate amount is burned
-
-<Mermaid
-  content={`
-sequenceDiagram
-    participant S as Sender/NFT Owner
-    participant B as Beneficiary
-    participant Chain1 as Source Chain
-    participant Chain2 as Destination Chain
-
-    S ->> Chain1: Send WithdrawStake Instruction
-    Note right of S: Must be after unbonding period
-    Chain1 ->> Chain1: Lock NFT
-    Chain1 ->> Chain2: WithdrawStake Packet
-    Chain2 ->> Chain2: Unbond Tokens
-    Chain2 ->> Chain1: Acknowledgement with Final Amount
-    Chain1 ->> Chain1: Set NFT to UNSTAKED state
-    Chain1 ->> B: Transfer Tokens + Rewards
-    Chain1 ->> Chain1: Burn NFT
-`}/>
-
-### 0x07 - Withdraw Rewards
-
-The withdraw rewards instruction uses opcode `0x07` and requires version `INSTR_VERSION_0`.
-
-```solidity
-struct WithdrawRewards {
-    uint256 tokenId;                      // NFT token ID for the staking position
-    bytes governanceToken;                // Governance token address
-    bytes governanceTokenWrapped;         // Wrapped governance token address
-    bytes validator;                      // Validator address
-    bytes sender;                         // Source chain sender address
-    bytes beneficiary;                    // Address that will receive the rewards
-}
-```
-
-The withdraw rewards instruction allows claiming rewards without unstaking. On success:
-1. The staking position remains in the STAKED state
-2. Any accumulated rewards are transferred to the beneficiary
-3. The NFT is returned to the sender
-
-<Mermaid
-  content={`
-sequenceDiagram
-    participant S as Sender/NFT Owner
-    participant B as Beneficiary
-    participant Chain1 as Source Chain
-    participant Chain2 as Destination Chain
-
-    S ->> Chain1: Send WithdrawRewards Instruction
-    Chain1 ->> Chain1: Lock NFT
-    Chain1 ->> Chain2: WithdrawRewards Packet
-    Chain2 ->> Chain2: Calculate Rewards
-    Chain2 ->> Chain1: Acknowledgement with Reward Amount
-    Chain1 ->> B: Mint/Transfer Rewards
-    Chain1 ->> S: Return NFT
-`}/>
 
 ## Implementations