typo train

AGENTS.md

@@ -185,6 +185,18 @@ Internal developer documentation exists mostly in the Linear initiative: https:/
 * See also the RFCs within the contained projects, especially those that are Completed
   - For instance [RFC: TezosX Blocks format](https://linear.app/tezos/document/rfc-tezosx-blocks-format-40cdbfca134e) in project [Tezos X blocks](https://linear.app/tezos/project/tezos-x-blocks-1a1f20746dee)
 
+## Verifying governance contract addresses
+
+The governance contract addresses are not hardcoded as static constants — they are written to kernel storage during migration steps. The authoritative source is the most recent kernel's `migration.rs` file in the Etherlink source code at `~/gitlab/tezos/etherlink/`.
+
+To find the current mainnet addresses:
+
+1. Identify the most recent kernel directory (e.g. `kernel_farfadet_r6_su`, `kernel_ebisu`, etc.) — typically the one with the highest suffix.
+2. Open `<kernel_dir>/kernel/src/migration.rs` and look for the last `StorageVersion::V<N>` blocks that write to `KERNEL_GOVERNANCE`, `KERNEL_SECURITY_GOVERNANCE`, and `SEQUENCER_GOVERNANCE`. Note that these can be set in separate migration steps, so check all of them and take the last value written for each.
+3. Compare those addresses against what the doc uses.
+
+Do **not** rely on `governance-metrics/src/configuration.ml` — it contains named constants for the governance metrics tool and can lag behind the kernel migrations.
+
 ## Documentation guidelines
 
 ### General guidelines

docs/evm/bridging/bridging-fa-transactions.md

@@ -14,6 +14,8 @@ It takes a few transactions to bridge a token from layer 1 to Etherlink EVM<!--T
 - A transaction to initiate the deposit
 - A transaction to claim the tokens on Etherlink EVM<!--TEVM-->
 
+This process is similar to the process of depositing XTZ tokens, as described in [Bridging to Tezos](/evm/bridging/bridging-tezos).
+
 Follow these steps to deposit FA-compliant tokens from layer 1 to Etherlink EVM<!--TEVM-->:
 
 1. Give the token bridge helper contract access to the tokens, depending on the type of token:

docs/evm/bridging/bridging-tezos.md

@@ -17,8 +17,8 @@ Both operations rely on automated, transparent, and audited smart contracts inst
 These bridges are permissionless, meaning that anyone can use them without restrictions or the intervention of a third party.
 They are also trustless, meaning that they rely on automated, transparent, and audited smart contracts installed on Etherlink and Tezos.
 
-- [Mainnet Tezos bridge](https://bridge.etherlink.com/tezos)
-- [Shadownet Testnet Tezos bridge](https://shadownet.bridge.etherlink.com/tezos)
+- [Mainnet XTZ bridge](https://bridge.etherlink.com/tezos)
+- [Shadownet Testnet XTZ bridge](https://shadownet.bridge.etherlink.com/tezos)
 
 <CementingDelayNote />
 
@@ -76,7 +76,11 @@ The request includes the tez to bridge, the address of the Etherlink<!--TX--> Sm
 1. The Smart Rollup nodes put the deposit transaction in the delayed inbox.
 1. The sequencer requests the state of Etherlink<!--TX--> from a Smart Rollup node and receives the delayed inbox.
 1. The sequencer creates a corresponding transaction on Etherlink EVM<!--TEVM--> to transfer XTZ from the [null address](https://explorer.etherlink.com/address/0x0000000000000000000000000000000000000000) to the user's address.
-1. The sequencer adds this transaction to an Etherlink EVM<!--TEVM--> block as in the usual transaction lifecycle described in [Architecture](/network/architecture).
+1. Depending on the target account, the sequencer handles the deposit in different ways:
+   - If the target account is a user account (also known as an externally owned account), the sequencer creates a transaction that calls the [XTZ bridge precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) (`0xff0...0001`) that transfers the XTZ to the user account.
+   - If the target account is a smart contract or EIP-7702 smart account, the sequencer calls the XTZ bridge precompiled contract to queue but not execute a transaction to transfer the XTZ.
+   Then, any user can call the `claim` function to execute the transaction and send the XTZ to the smart contract or smart account and call its code.
+   An automated system run by Optimistic Labs monitors the queued transactions and calls the `claim` function on behalf of depositors, so the process is transparent to bridge users.
 
 This diagram is an overview of the deposit process:
 
@@ -150,7 +154,7 @@ This diagram is an overview of the deposit process:
 
 The withdrawal process (moving XTZ from Etherlink EVM<!--TEVM--> to tez on Tezos layer 1) follows these general steps:
 
-1. An Etherlink EVM<!--TEVM--> user sends XTZ and their layer 1 address to the [withdrawal precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) in the Etherlink<!--TX--> Smart Rollup via an EVM node<!--TXN-->.
+1. An Etherlink EVM<!--TEVM--> user sends XTZ and their layer 1 address to the [XTZ precompiled contract](https://explorer.etherlink.com/address/0xff00000000000000000000000000000000000001) in the Etherlink<!--TX--> Smart Rollup via an EVM node<!--TXN-->.
 1. The contract locks the XTZ.
 1. The contract creates a transaction to the exchanger contract's `burn` entrypoint and puts this transaction in the Smart Rollup outbox.
 This outbox message becomes part of Etherlink<!--TX-->'s commitment to its state.

docs/evm/nac-usage.md

@@ -192,3 +192,31 @@ Malformed addresses never revert: they are reported as Unknown (`kind == 0`) or
 ### Infrastructure failures
 
 A 5xx response from the Michelson runtime indicates a kernel-internal error (storage I/O failure, host fault). This is treated as a block-level abort rather than a catchable revert, meaning the entire block is rolled back. These failures are not caused by contract logic and are not catchable by EVM code.
+
+## Observability
+
+The EVM gateway precompile emits two events for cross-runtime calls involving the EVM interface. Both are emitted at the gateway precompile address and carry a `crossRuntimeCallId` field that correlates with the Michelson-side markers described in the [Michelson nac-usage](/michelson/nac-usage#observability) page.
+
+### `CrossRuntimeCallSent`
+
+Emitted on every outgoing call (EVM → other runtime), before execution:
+
+| Field | Type | Description |
+|---|---|---|
+| `crossRuntimeCallId` | `string` | Unique identifier for this call |
+| `targetRuntime` | `string` | Name of the target runtime (e.g. `"tezos"`) |
+| `targetAddress` | `string` | Address of the target contract |
+| `amount` | `uint256` | Amount of tez forwarded with the call |
+
+### `CrossRuntimeCallReceived`
+
+Emitted on every incoming call (other runtime → EVM), before execution:
+
+| Field | Type | Description |
+|---|---|---|
+| `crossRuntimeCallId` | `string` | Unique identifier for this call |
+| `sourceRuntime` | `string` | Native runtime of the originating address (follows the transitive origin on nested calls, e.g. `"ethereum"` for an EVM → Michelson → EVM chain) |
+| `senderAddress` | `string` | Immediate caller — the EVM alias of the Michelson sender |
+| `sourceAddress` | `string` | Transitive origin — the original address at the start of the cross-runtime chain |
+| `targetAddress` | `string` | Address of the called EVM contract |
+| `amount` | `uint256` | Amount of tez forwarded with the call |

docs/governance/how-is-etherlink-governed.md

@@ -48,8 +48,8 @@ This table shows the period lengths as of the Ganesha kernel update and the Tezo
 
 Period | Length | Approximate time
 --- | --- | ---
-Proposal | 50400 layer 1 blocks | About 4.5 days
-Promotion | 50400 layer 1 blocks | About 4.5 days
+Proposal | 67200 layer 1 blocks | About 4.5 days
+Promotion | 67200 layer 1 blocks | About 4.5 days
 Cooldown | 86400 seconds | About 1 day
 
 Note that these periods can vary.
@@ -63,7 +63,7 @@ Any baker can submit kernel upgrade proposals and upvote proposals, with the wei
 Bakers can submit and upvote up to 20 proposals in a single Proposal period.
 
 At the end of the period, if a proposal has enough voting power to meet a certain percentage of the total voting power, it moves to the next phase.
-As of the Ebisu update, the leading proposal must gather support from at least 1% of the total voting power to move to the next phase.
+As of the Ganesha update, the leading proposal must gather support from at least 1% of the total voting power to move to the next phase.
 If no proposal gathers adequate support, a new Proposal period begins.
 
 ### 2. Promotion period
@@ -77,7 +77,7 @@ To pass, the proposal must meet both of these requirements:
 - Supermajority: The total voting power of the Yea votes must reach a supermajority.
 
 The thresholds for these requirements are stored in the governance contract.
-This table shows the requirements as of the Ebisu kernel update:
+This table shows the requirements as of the Ganesha kernel update:
 
 Requirement | Threshold
 --- | ---
@@ -121,8 +121,8 @@ This table shows the period lengths as of the Ganesha kernel update and the Tezo
 
 Period | Length | Approximate time
 --- | --- | ---
-Proposal | 3600 layer 1 blocks | About 8 hours
-Promotion | 3600 layer 1 blocks | About 8 hours
+Proposal | 4800 layer 1 blocks | About 8 hours
+Promotion | 4800 layer 1 blocks | About 8 hours
 Cooldown | 86400 seconds | About 1 day
 
 Like the slow governance periods, these periods can vary based on the timing of layer 1 blocks and when users activate the new kernel at the end of the Cooldown period.
@@ -132,7 +132,7 @@ Like the slow governance periods, these periods can vary based on the timing of
 The differences in thresholds in the security governance process ensure expedited resolution of urgent issues while upholding integrity by demanding higher quorum to prevent potential nefarious actions.
 
 The thresholds for the quorum and supermajority requirements are stored in the governance contract.
-This table shows the requirements as of the Ebisu kernel update:
+This table shows the requirements as of the Ganesha kernel update:
 
 Period | Requirement | Threshold
 --- | --- | ---
@@ -149,19 +149,19 @@ A separate sequencer governance contract handles the selection process for Ether
 Similar to the kernel governance processes, the sequencer voting process has Proposal, Promotion, and Cooldown periods.
 In this process, bakers propose and vote on the account that operates the sequencer.
 
-The lengths of the periods are stored in the [sequencer governance contract](https://better-call.dev/mainnet/KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh).
+The lengths of the periods are stored in the [sequencer governance contract](https://better-call.dev/mainnet/KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw).
 This table shows the period lengths as of the Ganesha kernel update and the Tezos Ushuaia protocol:
 
 Period | Length | Approximate time
 --- | --- | ---
-Proposal | 50400 layer 1 blocks | About 4.5 days
-Promotion | 50400 layer 1 blocks | About 4.5 days
+Proposal | 67200 layer 1 blocks | About 4.5 days
+Promotion | 67200 layer 1 blocks | About 4.5 days
 Cooldown | 86400 seconds | About 1 day
 
 ### Thresholds
 
 The thresholds for the quorum and supermajority requirements are stored in the governance contract.
-This table shows the requirements as of the Ebisu kernel update:
+This table shows the requirements as of the Ganesha kernel update:
 
 Period | Requirement | Threshold
 --- | --- | ---

docs/governance/overview.mdx

@@ -45,7 +45,7 @@ You need the address of the correct governance contract (and sometimes the addre
 </tr>
 <tr>
 <td>Sequencer operator</td>
-<td><InlineCopy code="KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" href="https://better-call.dev/mainnet/KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" abbreviate="6,4"></InlineCopy></td>
+<td><InlineCopy code="KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" href="https://better-call.dev/mainnet/KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" abbreviate="6,4"></InlineCopy></td>
 </tr>
 <tr>
 <td>Voting keys</td>

docs/governance/sequencer-upgrades.md

@@ -15,7 +15,7 @@ For example, this Octez client command calls this view for the kernel governance
 
 ```bash
 octez-client -E https://mainnet.ecadinfra.com \
-  run view get_voting_state on contract KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh
+  run view get_voting_state on contract KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw
 ```
 
 The view returns information about the current governance period.
@@ -28,7 +28,7 @@ You can also subscribe to the `voting_finished` event to be notified when the Pr
 To propose an account to be the sequencer operator, bakers can call the `new_proposal` entrypoint of the governance contract during the Proposal period:
 
 ```bash
-octez-client transfer 0 from my_wallet to KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh \
+octez-client transfer 0 from my_wallet to KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw \
   --entrypoint new_proposal \
   --arg 'Pair "<PUBLIC_KEY>" <L2_ADDRESS>'
 ```
@@ -43,7 +43,7 @@ The command takes these parameters:
 For example:
 
 ```bash
-octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from my_wallet \
+octez-client call KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw from my_wallet \
   --entrypoint new_proposal \
   --arg 'Pair "<PUBLIC_KEY>" <L2_ADDRESS>'
 ```
@@ -53,7 +53,7 @@ To upvote a proposed sequencer operator during a Proposal period, go to the [gov
 As an alternative, call the `upvote_proposal` entrypoint with the same parameters as the `new_proposal` entrypoint:
 
 ```bash
-octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from my_wallet \
+octez-client call KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw from my_wallet \
   --entrypoint upvote_proposal \
   --arg 'Pair "<PUBLIC_KEY>" <L2_ADDRESS>'
 ```
@@ -67,7 +67,7 @@ When a proposal is in the Promotion period, you can vote for or against it by go
 As an alternative, you can vote for or against it or pass on voting by calling the `vote` entrypoint of the governance contract:
 
 ```bash
-octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from my_wallet \
+octez-client call KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw from my_wallet \
   --entrypoint "vote" --arg '"yea"'
 ```
 
@@ -80,7 +80,7 @@ The command takes these parameters:
 For example:
 
 ```bash
-octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from tz1RLPEeMxbJYQBFbXYw8WHdXjeUjnG5ZXNq \
+octez-client call KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw from tz1RLPEeMxbJYQBFbXYw8WHdXjeUjnG5ZXNq \
   --entrypoint "vote" --arg '"yea"'
 ```
 
@@ -89,7 +89,7 @@ octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from tz1RLPEeMxbJYQBFbXYw
 After a proposed account wins a vote, any account can trigger the change and enable that account to run the sequencer by calling the governance contract's `trigger_committee_upgrade` entrypoint:
 
 ```bash
-octez-client call KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh from my_wallet \
+octez-client call KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw from my_wallet \
   --entrypoint "trigger_committee_upgrade" \
   --arg '"sr1Ghq66tYK9y3r8CC1Tf8i8m5nxh8nTvZEf"'
 ```

docs/governance/voting-key.md

@@ -79,7 +79,7 @@ As a result, the voting key can vote on those contracts but not on the kernel fa
 ```bash
 octez-client call KT1Ut6kfrTV9tK967tDYgQPMvy9t578iN7iH from <MY_BAKER> \
   --entrypoint propose_voting_key \
-  --arg '(Pair "<MY_VOTING_KEY>" True (Some { "KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" ; "KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" }))'
+  --arg '(Pair "<MY_VOTING_KEY>" True (Some { "KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" ; "KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" }))'
 ```
 
 Then, to claim voting rights, go to the [governance web site](https://governance.etherlink.com), connect your voting key with the **Connect** button at the top right of the page, and use the connection dialog to claim rights.
@@ -111,7 +111,7 @@ For example, from the code of the contract you can see that the parameter to pas
 This command compiles an expression of this CameLIGO type to Michelson to propose rights for two contracts:
 
 ```bash
-ligo compile expression cameligo '("<MY_VOTING_KEY>" : address), True, (Some (Set.literal [("KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" : address); ("KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" : address)]) : (address set) option)'
+ligo compile expression cameligo '("<MY_VOTING_KEY>" : address), True, (Some (Set.literal [("KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" : address); ("KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" : address)]) : (address set) option)'
 ```
 
 You can use the result as the parameter to pass to the `propose_voting_key` entrypoint.
@@ -120,7 +120,7 @@ Here is the result of the command:
 ```michelson
 (Pair "<MY_VOTING_KEY>"
       True
-      (Some { "KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" ;
+      (Some { "KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" ;
               "KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" }))
 ```
 
@@ -129,7 +129,7 @@ Here is the resulting `octez-client` command:
 ```bash
 octez-client call KT1Ut6kfrTV9tK967tDYgQPMvy9t578iN7iH from <MY_BAKER> \
   --entrypoint propose_voting_key \
-  --arg '(Pair "<MY_VOTING_KEY>" True (Some { "KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" ; "KT1KiVz8ZpHo3HpE1GCP5HLgywPDRwVUkCFh" }))'
+  --arg '(Pair "<MY_VOTING_KEY>" True (Some { "KT1AXRU3wLc87WNhLhVGrgqDGubLACUMUgPb" ; "KT1DkQFmACvsUtnx8B4jirnp2CRi1cWSiELw" }))'
 ```
 :::
 

docs/michelson/nac-usage.md

@@ -317,3 +317,14 @@ A view failure (EVM revert, missing view, type mismatch) surfaces as `None` from
 ### `originOf` and `resolveAddress`
 
 Malformed addresses never fail: they are reported as Unknown (`Left Unit`) or `None`. Both views fail the operation with `(Pair "INVALID_RUNTIME_ID" n)` when a runtime id `n` is neither `0` nor `1`.
+
+## Observability
+
+For every cross-runtime call involving the Michelson interface, the kernel emits two synthetic internal operations on the Michelson side that bracket the call. They are distinguished from user-issued `EMIT` operations by their **null sender**:
+
+| Event tag | When emitted |
+|---|---|
+| `cross_runtime_call` | Before the cross-runtime call executes |
+| `cross_runtime_call_end` | After the cross-runtime call returns |
+
+The `crossRuntimeCallId` carried in the corresponding EVM-side events (`CrossRuntimeCallSent` / `CrossRuntimeCallReceived`, described in the [EVM nac-usage](/evm/nac-usage#observability) page) can be used to correlate these Michelson markers with their EVM counterparts.

docs/overview/index.md

@@ -44,7 +44,7 @@ Leveraging the Tezos 2-block finality guarantee and the high-speed execution of
     <tr>
       <td>Arbitrum One</td>
       <td>~ <a class="deemphasize-disadvantage" href="https://arbiscan.io/" target="_blank" rel="noopener noreferrer">300 ms</a></td>
-      <td>~ <a class="deemphasize-disadvantage" href="https://arbiscan.io/batches" target="_blank" rel="noopener noreferrer">3 minutes</a></td>
+      <td>~ <a class="deemphasize-disadvantage" href="https://arbiscan.io/batches" target="_blank" rel="noopener noreferrer">2 minutes</a></td>
     </tr>
   </tbody>
 </table>