updated docs

Turupawn · Turupawn · commit b4a22056763c · 2026-01-14T13:00:59.000-06:00
diff --git a/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx b/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx
@@ -37,9 +37,7 @@ We support the `cancun` EVM target and the latest Solidity version `0.8.26`.
 
 ## EVM Precompiles
 
-The `RIPEMD-160` (address `0x3`), `blake2f` (address `0x9`), and `point evaluation` (address `0x0a`) precompiles are currently not supported. Calls to unsupported precompiled contracts will revert.
-
-All other EVM precompiles are fully supported and behave the same as Ethereum.
+Most precompiled contracts are supported. For a complete and up-to-date list of supported precompiles and any differences from Ethereum, see [rollup.codes/scroll](https://www.rollup.codes/scroll). Calls to unsupported precompiled contracts will revert.
 
 ## Block Time
 
diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx
@@ -9,7 +9,9 @@ excerpt: "The Enforced Transaction contract enables sending transactions between
 
 import Aside from "../../../../../components/Aside.astro"
 
-In future upgrades to Scroll, the Enforced Transaction contract will enable sending transactions between L1 and L2 with the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
+The Enforced Transaction contract enables sending transactions from L1 to L2 with the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
+
+For enforced transactions, the L2 sender will be the same as the L1 sender. This means a user can initiate an L2 transaction directly from their wallet via L1, allowing them to withdraw tokens or call other contracts on L2 even if the sequencer is unresponsive.
 
 ## Enforced Transactions API
 
diff --git a/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx b/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx
@@ -121,7 +121,7 @@ The deposited ETH of `value` amount is locked in the `L1ScrollMessenger` contrac
 Enforced Transactions allow users to bypass the `L1ScrollMessenger` and send messages directly to the `L1MessageQueue`. This provides a censorship-resistance mechanism, ensuring users can always force transaction inclusion on L2.
 </Aside>
 
-The `EnforcedTxGateway` contract provides two `sendTransaction` functions to send an enforced transaction. In the first function, the sender of the generated `L1MessageTx` transaction is the transaction sender. On the other hand, the second function uses the passed `sender` address as the sender of the `L1MessageTx` transaction. This allows a third party to send an enforced transaction on behalf of the user and pay the relay fee. Note that the second function requires providing a valid signature of the generated `L1MessageTx` transaction that matches the `sender` address. Both `sendTransaction` functions enforce the sender to be an EOA account.
+The `EnforcedTxGateway` contract provides two `sendTransaction` functions to send an enforced transaction. In the first function, the sender of the generated `L1MessageTx` transaction is the transaction sender, meaning the L2 sender will be the same as the L1 sender, allowing a user to initiate an L2 transaction directly from their wallet via L1. On the other hand, the second function uses the passed `sender` address as the sender of the `L1MessageTx` transaction. This allows a third party to send an enforced transaction on behalf of the user and pay the relay fee. Note that the second function requires providing a valid signature of the generated `L1MessageTx` transaction that matches the `sender` address. Both `sendTransaction` functions enforce the sender to be an EOA account.
 
 <ToggleElement anchor="sendTransaction function signatures">
 <div slot="title"><code>sendTransaction</code> function signatures</div>
diff --git a/src/content/docs/en/technology/chain/differences.mdx b/src/content/docs/en/technology/chain/differences.mdx
@@ -19,13 +19,7 @@ import Aside from "../../../../../components/Aside.astro"
 
 ## Precompiled Contracts
 
-| Address | Name               | Scroll behavior   |
-| ------- | ------------------ | ----------------- |
-| `0x03`  | `RIPEMD-160`       | Not supported.    |
-| `0x09`  | `blake2f`          | Not supported.    |
-| `0x0a`  | `point evaluation` | Not supported as a precompile. Blob verification is done in ZK circuits. |
-
-The remaining precompiled contracts have the same behavior as Ethereum.
+Most precompiled contracts are supported. For a complete and up-to-date list of supported precompiles and any differences from Ethereum, see [rollup.codes/scroll](https://www.rollup.codes/scroll).
 
 ## EIPs
 
diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx
@@ -14,14 +14,13 @@ A transaction is a cryptographically signed message that initiates a state trans
 
 ## Transaction Type
 
-Currently, Scroll supports four types of transactions.
+Currently, Scroll supports five types of transactions.
 
 - Pre-EIP-155 Transaction: This is to support the [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) contract.
 - Legacy Transaction (refer to [EIP-155](https://eips.ethereum.org/EIPS/eip-155))
 - [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) Transaction (Type 2): Supported since the [Curie upgrade](/technology/overview/scroll-upgrades/curie-upgrade). Scroll uses a modified EIP-1559 fee market where the sequencer sets the L2 base fee based on the L1 base fee, and ETH is not burned.
 - `L1MessageTx` Typed Transaction (Type: `0x7E`): This is a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction introduced in Scroll as described below. This transaction type is for transactions initiated on L1.
-
-Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) access list transactions are not yet supported on Scroll.
+- [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) Access List Transaction (Type 1): Supported since the [Curie upgrade](/technology/overview/scroll-upgrades/curie-upgrade).
 
 ### L1 Message Transaction
 
