updated bullet points

Author: krofax

pages/stack/interop/reading-logs.mdx

@@ -31,6 +31,7 @@ This enables developers to:
 
 *   **Reference existing logs**: Allows contracts to verify and use logs that were already emitted, without requiring those logs to have been sent as cross-chain messages.
 *   **Consistent trust model**: Uses the same trust assumptions as the underlying OP Stack infrastructure.
+*   **Trust-minimized security**: Leverages the existing Superchain security model with no additional trust assumptions, unlike traditional oracle solutions that require trusting external validators.
 *   **Flexibility**: Can be used to validate events from another chain or even the local chain.
 
 ## How it works
@@ -116,25 +117,6 @@ sequenceDiagram
 
 8.  If validation is successful, the DeFi application grants the user access based on the verified attestation.
 
-### Conceptual approach for attestation verification
-
-When implementing an attestation verification system using `CrossL2Inbox`, you would need to:
-
-1.  **Create an Identifier struct** that uniquely identifies the attestation event:
-    *   Include the source chain ID where the attestation was created
-    *   Specify the EAS contract address (origin) that emitted the event
-    *   Include other necessary parameters to identify the specific log
-
-2.  **Validate the attestation event**:
-    *   Call the `validateMessage()` function on the CrossL2Inbox contract
-    *   Pass the identifier struct and a hash of the attestation event data
-    *   Handle potential validation failures in your contract logic
-
-3.  **Process the validated attestation**:
-    *   Once validated, your contract can trust that the attestation exists on the source chain
-    *   Extract relevant data from the attestation to inform your application's logic
-    *   Implement business rules based on the verified attestation (e.g., grant access, enable features)
-
 The primary benefit of this approach is that it allows your contract to verify attestations that already exist on another chain without requiring those attestations to have been explicitly sent as cross-chain messages.
 
 ## Implementation guide