Pain → Agitation → Smart Contract Events and Logs

“Why did our dashboards drift and the audit failed?”

• Your data team is busy backfilling those “token_transfer” metrics, but it seems like last week’s totals are out of sync with what we saw yesterday. Plus, the SIEM totally missed those “Paused/Unpaused” switches. Oh, and let’s not forget about that quarterly SOX control that’s tied to the “admin role changed” event--yeah, that one never even fired.
• Here are some of the root causes we keep running into:
  • We often see non-deterministic indexing when chain reorganizations happen; consumers just didn’t catch the JSON-RPC “removed: true” signal on log subscriptions. (geth.ethereum.org)
  • Event design that’s all about search optimization can sometimes lead to lost values (indexed dynamic types get hashed), making forensics a bit of a headache. (docs.solidity.org)
  • Some providers throttle the eth_getLogs ranges, which can lead to teams running backfills for a week and still missing vital windows. (docs.blastapi.io)
  • Those pesky Bloom-filter false positives and historical pruning can really make expectations on coverage and retention confusing. (pureth.guide)
  • Some contracts just don’t emit enough events (or they emit the wrong ones), which messes with SIEM correlation, like role changes and config updates. (openzeppelin.com)

The risk if you “ship anyway”

• Missed deadlines: When backfills get stuck because of provider range limits and reorg replays, we end up with reporting delays and pushed-back go-live dates. You can check out more details here.
• Compliance exposure: If we can’t prove the inclusion of crucial events (like changes to admin policies), it makes SOC2/SOX evidence a slow, manual, and subjective process. Plus, Ethereum clients might prune old receipts over time, which can mess with future reproducibility if we don’t plan for archiving or proofs. More info can be found here.
• Vendor lock-in and hidden run costs: Relying on naive polling can skyrocket RPC and database costs. Meanwhile, dashboards can drift unnoticed due to log signature collisions (for example, the ERC‑20 vs ERC‑721 Transfer share topic0), and re-indexing tasks can turn into a weekly hassle. Dive into more on this here.

7Block Labs’ enterprise methodology for events and logs

We connect the dots between Solidity and data engineering, making sure that legal, finance, and security can rely on solid evidence. Our method covers everything from design to build, verification, and operation.

• Let’s design the event schema for evidence and analytics.
  • First off, we need to clearly define “control events.” This includes things like role changes, configuration thresholds, pause states, and oracle updates. We should also make sure to map them right from the get-go to SOC2/SOX controls and SIEM correlation rules.
  • For dynamic values that you need to search and read, make sure to emit them twice: once as an indexed (searchable hash) and again as unindexed (cleartext). You can find more info on this here.
  • Don’t forget to version critical events (like ConfigUpdatedV1 → V2) to prevent any schema breaks down the line. It’s best to avoid using anonymous events so that topic0 can still be the keccak of the signature, making it filterable. Check out the details here.
• Implement with precise EVM constraints
  • First off, get familiar with the EVM write costs: you’re looking at LOG costing 375 gas plus 375 gas for each topic and 8 gas for every data byte (don’t forget about memory expansion, too!). Adjust your topics and data accordingly. (studylib.net)
  • Next, let’s talk about topics. For non-anonymous events, reserve topic0 using keccak256(signature). Then, you can index up to 3 arguments as topics1-3. Keep in mind that if you have dynamic indexed arguments, they’ll be hashed, so you can’t pull the original value from the topic alone. (docs.ethers.org)
  • If you’re using Solidity version 0.8.15 or newer, take advantage of event.selector to compute topic0 at compile time. This way, you’ll have deterministic signatures across different packages. (soliditylang.org)
• Build ingestion with “exactly-once” semantics
  • For low latency, go ahead and subscribe via eth_subscribe("logs"). To tackle reorgs, just keep an eye on removed:true and sync things up using (blockHash, txHash, logIndex). Check it out more here.
  • When it comes to backfilling, use eth_getLogs in defined block windows according to provider limits (like 500-block ranges). It’s a good idea to shard by contract and topic - this helps you parallelize and cut down on those pesky false alarms from blooms. More details can be found here.
  • For a reliable replay, make sure you’re indexing receipts using the block header’s receiptsRoot, and don’t just rely on RPC results. Plus, get your proofs organized for those attestation workflows. You can learn more about it here.
• Show your work when the auditor says “prove it”
  • Logs are stored in the transaction receipts within the receipts trie. You can check their inclusion by comparing it to the block’s receiptsRoot and create a log proof chain (block header → receipt → log). (ethereum.org)
• Focus on retention and portability
  • Think about the long game: clients might get rid of old bodies and receipts (check out the EIP‑4444 guidelines, history expiry, and client pruning), so it’s smart to have an archive endpoint strategy ready for those audit periods. You might also want to materialize proofs right when you're executing controls. (eip.directory)

Where We Fit:

• Smart Contracts and Instrumentation: Check out our smart contract development and custom blockchain development services to get started.
• Security and Compliance Readiness: Stay ahead of the game with our security audit services.
• Data and Enterprise Pipes: We’ve got you covered with our blockchain integration and web3 development services.

---

Deep dive: What smart contract “Events and Logs” really are (without hand-waving)

• Events in Solidity are a neat way to wrap around EVM opcodes LOG0-LOG4. They’re used to write structured data straight into the transaction receipt, but here’s the catch: contracts can’t actually read these logs (it’s intentional!). Off-chain consumers, on the other hand, rely on RPC to grab and sift through them. (docs.soliditylang.org)
• Here’s how it’s structured:
  • topics: You’ve got up to 4 slots here. For non-anonymous events, topic0 is generated with keccak256("Name(type1,type2,…)"), while topics1-3 hold the indexed arguments (value types are stored directly as 32 bytes, and dynamic types get hashed). (docs.ethers.org)
  • data: This is where the ABI-encoded unindexed arguments hang out. (docs.soliditylang.org)
• When it comes to gas economics for logging:
  • The base cost is 375, plus 375 for each topic, and 8 per byte of data. Oh, and don’t forget the memory expansion when you’re encoding stuff. Overall, this is way more cost-effective than storing things persistently, which is why you’ll see “telemetry” fitting nicely into events. (studylib.net)
• Now, filtering at scale can get a bit tricky:
  • Nodes keep a 2048-bit bloom filter for each block header (and for each receipt) based on the log address and each topic to help pre-filter eth_getLogs. Just a heads-up, blooms give you a “possible match,” but not a guarantee. (pureth.guide)
  • As busy blocks increase, you might see more false positives. Teams should be ready for some extra receipt scans and plan accordingly. There’s even been talk about potentially ditching blooms altogether (EIP‑7668), so don’t tie your SLAs to how well blooms perform. (ethereum-magicians.org)

Solidity implementation patterns (Enterprise-grade)

1. Multi-use, easy to search, and reader-friendly

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Config {
    // Versioned event for auditability
    event ThresholdUpdatedV1(
        address indexed actor,      // topic1: who changed it
        bytes32 indexed keyHash,    // topic2: searchable key hash
        string  key,                // data: human-readable key
        uint256 oldValue,           // data
        uint256 newValue            // data
    );

    function update(string memory key, uint256 newValue) external {
        bytes32 keyHash = keccak256(bytes(key));
        // ... apply change, track oldValue ...
        emit ThresholdUpdatedV1(msg.sender, keyHash, key, /*old*/ 100, newValue);
    }
}

• Why: Dynamic strings in indexed fields get hashed; keeping both forms helps maintain readability and allows for topic filters. (docs.ethers.org)

2) Deterministic Signature Management

In the world of cryptography, deterministic signature management is all about ensuring that the same input will always produce the same signature. This method is crucial for maintaining consistency and reliability in various applications. Here's a quick overview of its main features and benefits:

Key Features

• Consistency: Since the signature is generated from a specific input, you can count on getting the same result every time.
• Predictability: It eliminates any surprises when you’re signing transactions or messages because the outcome is entirely based on the input.
• Efficiency: This method can save time and resources, especially when handling multiple transactions that need to be verified.

Benefits

1. Improved Security: Deterministic signatures can protect against certain types of attacks, making them a safer choice.
2. Ease of Verification: With a consistent output, validating signatures becomes more straightforward.
3. Simplicity in Implementation: Developers find it easier to implement because of the predictable nature of the process.

Conclusion

Deterministic signature management plays a vital role in enhancing the security and efficiency of cryptographic systems. By ensuring that the same input always yields the same signature, it helps maintain the integrity of digital communications and transactions.

event AdminRoleGranted(address indexed account, address indexed sender);

bytes32 constant ADMIN_ROLE_GRANTED_TOPIC = AdminRoleGranted.selector; // >=0.8.15

• At compile time, we link topic0, making sure that subgraph manifests and SIEM parsers are in sync. (soliditylang.org)

3) Skip the Anonymous Events

When it comes to networking and building connections, try to steer clear of events where people are just blending into the crowd without any personal touch. These anonymous gatherings can make it tough to form real relationships. Instead, look for events that encourage interaction and give everyone a chance to share who they are. You'll find that engaging in conversations and getting to know individuals on a deeper level will lead to more meaningful connections!

event RiskSignal(bytes32 indexed code, uint256 level); // filterable by signature
// event anonymous RiskSignal(...); // don’t: removes topic0 signature filter

• Anonymous events can make it tough to filter through everything, which can complicate how we operate. (docs.ethers.org)

4) Standards-aware emissions

• When dealing with ERC‑20 tokens, keep in mind that both Transfer and Approval are required, and those canonical signatures can be pretty important for tools and explorers down the line. Check out more about it here.
• Oh, and don’t be caught off guard--ERC‑20 Transfer and ERC‑721 Transfer actually share the same topic0. You’ll want to decode them based on ABI/context instead of just relying on topic0. For a deeper dive, take a look at this post here.

5) Emerging patterns

• Check out ERC‑7699 “TransferReference” for handling payment references. It records a bytes32 reference alongside a standard transfer, which can be super handy for ERP reconciliation while keeping calldata tidy. You can find more details here.

Indexing and ingestion architecture that survives audits

• Reorg-safe subscriptions
  • Go ahead and use websockets for eth_subscribe("logs"). When you get “removed:true,” just delete or mark the old log as outdated, and then reprocess the new one. To keep things tidy, create a primary key with (blockHash, txHash, logIndex) to make sure you’re not doing the same work twice. (geth.ethereum.org)
• Backfill with guardrails
  • Make sure to respect provider windows (some services only allow 500 blocks at a time); paginate from the oldest blocks to the newest. It’s also a good idea to periodically check your log counts against a reliable explorer topic0 to catch any gaps. (docs.blastapi.io)
• Subgraph topic filters for precise extraction
  • If you’re using The Graph, take advantage of those indexed-argument filters (topic1..topic3) to limit what you’re ingesting to only the addresses and roles that really matter to you. This helps reduce CPU usage and keeps the PostgreSQL database running smoothly. (thegraph.com)
• Bloom realities
  • Blooms are great for speeding up negative lookups, but they can still throw some false positives your way. So, be sure to budget for extra scans and think about using replica sets for archive receipts if you’re under heavy load. (pureth.guide)

Proofs and attestations

• You can authenticate receipts and logs using the per-block receiptsRoot, which is essentially a Merkle‑Patricia trie. When you get a log inclusion proof, it connects your event to a specific canonical block header--this is super useful for SOC2 evidence. Check it out here: (ethereum.org).
• If you want to provide independently verifiable evidence, you’ll want to put together what’s called “log proofs,” which include headers, receipt proofs, and transaction index proofs. This is pretty standard for light-client and ZK inclusion workflows. More info can be found here: (in3.readthedocs.io).

Retention and availability planning

• Production chains are leaning towards clearing out old data and receipts; not every node is going to keep ancient logs forever. It’s a good idea to have at least one archive source or to grab proof when you’re doing your checks. (eip.directory)

Practical RPC snippets

Subscribe (reorg-aware):

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "eth_subscribe",
  "params": [
    "logs",
    {
      "address": ["0xYourContract"],
      "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"] // Transfer
    }
  ]
}

• Your consumer needs to take care of removed: true. (geth.ethereum.org)

Backfill (bounded range):

Backfilling a bounded range involves filling in gaps within a specific limit, creating a more complete dataset. This process can be super helpful when you're dealing with missing values in your data, as it allows for a more accurate analysis.

Here's a quick guide on how to backfill within a bounded range:

1. Identify the Range: First, determine the limits within which you want to fill in the missing values. This could be based on time, a particular variable, or any other criteria relevant to your data.
2. Select the Data: Choose the dataset where you need to backfill the missing values. Make sure you have a good understanding of its structure.
3. Apply Backfill: You can use various programming techniques to backfill the values. For example, in Python, you might use pandas like this:

   import pandas as pd
   
   # Create a sample DataFrame
   df = pd.DataFrame({
       'date': pd.date_range('2023-01-01', periods=10),
       'value': [1, None, None, 4, None, 6, None, None, 9, 10]
   })
   
   # Set the date as index
   df.set_index('date', inplace=True)
   
   # Backfill within a bounded range (e.g., up to a specific date)
   df['value'] = df['value'].fillna(method='bfill', limit=2)
   
   print(df)

4. Check Your Results: After backfilling, it's a good idea to review the dataset to ensure that the missing values were filled in appropriately. Look for any anomalies or unexpected results.
5. Document Your Process: Always keep a record of how you backfilled the data. This can help others understand your methodology and ensure reproducibility.

Using this method, you can easily improve the quality of your datasets and make them much more reliable for analysis. Happy data wrangling!

curl -s -X POST $RPC \
  -H "content-type: application/json" \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"eth_getLogs",
    "params":[{"fromBlock":"0xA1B2C3","toBlock":"0xA1B6C7",
               "topics":["0xddf252ad1be2c89b6...3b3ef"]}] }'
'

• Break down your chunk ranges to fit within your provider’s limit (like, say, 500 blocks) and run those in parallel across different addresses. Check out the details here: (docs.blastapi.io)

---

Brief, in-depth technical notes executives actually care about

• Money savers
  • Events are like “cheap telemetry”: it’s 375 + 375 per topic + 8 per byte compared to persistent SSTORE, which can cost you thousands of gas. So, design your events rather than storing every single analytics field. (studylib.net)
  • Only emit the indexed fields that you really need. Make sure to include dynamic fields you’ll need to search later in an unindexed way too, to avoid extra read-path calls. (docs.ethers.org)
• Reliability levers
  • Think of logs as append-only, but remember they’re not really final until you get N confirmations. Make sure to codify your SLA (like 12 confirmations) into your analytics and SIEM alerts.
  • Keep track of canonical identifiers like blockHash, txHash, and logIndex; don’t try to come up with your own deduplication keys.
• SOC2/SOX alignment
  • Link each “control event” to a control ID and retention policy. If you’re not running an archive node, make sure to capture log proofs while the change window is open, or mirror them to an immutable store connected to the receiptsRoot. (ethereum.org)
• ZK and cross-org verification
  • For those high-assurance workflows, you can wrap log inclusion proofs as attestations and check them in a different system (or rollup). This way, you get “trust-minimized” audit evidence without having to expose your entire node setup. (in3.readthedocs.io)
• Explorer parity
  • Topic0 is a hash, and multiple standards can end up colliding in signatures (like ERC‑20/721 Transfers). So, align your ABI catalogs (think topic0 databases) across your data lake, SIEM parsers, and subgraphs. (github.com)

---

1) ERC‑20 Transfer with Reconciliations

Transferring ERC-20 tokens is pretty straightforward, but keeping your records straight is just as important. Let’s break it down:

• What’s an ERC-20 token?
  Think of it as a digital asset that lives on the Ethereum blockchain. These tokens follow a specific standard that's widely accepted, making it easy to send and receive them across various platforms.
• How to Transfer ERC-20 Tokens:
  To send ERC-20 tokens, you’ll need a compatible wallet. Here’s a quick step-by-step guide:
  1. Open your wallet app.
  2. Navigate to the "Send" option.
  3. Enter the recipient's wallet address.
  4. Specify the amount you want to send.
  5. Double-check everything (you don’t want to send it to the wrong address!).
  6. Confirm the transaction.
• Reconciliation Process:
  After making your transfer, you'll want to keep everything in check. Here’s how you can reconcile your transactions:
  • Check Your Blockchain Explorer:
    Use something like Etherscan to verify that your transaction went through. Just plug in your wallet address and see the transaction history.
  • Maintain a Record:
    It’s a great idea to jot down every transaction--dates, amounts, addresses, and any fees. This way, you can keep tabs on everything.
  • Automate with Tools:
    There are tools and software out there that can help automate your tracking and reconciliation. Check out platforms like TokenTax for a more streamlined experience.

By following these steps and keeping a close eye on your transfers, you’ll have a clear picture of your transactions and maintain accurate records. Don’t forget to stay updated with any changes in the ERC-20 standards or token practices!

event Transfer(address indexed from, address indexed to, uint256 value);
// Optional add-on per ERC‑7699:
event TransferReference(bytes32 indexed loggedReference);

• Emit the usual Transfer for wallets and explorers. Also, make sure to log a reference (like the keccak of the invoice number, order number, etc.) to help reconcile with ERP systems, all while keeping the raw strings private on-chain. (eips.ethereum.org)

2) Admin Lifecycle for SIEM Correlation

Managing the admin lifecycle for SIEM (Security Information and Event Management) correlation is crucial to maintaining a secure environment. Here are the key stages of this process:

1. Onboarding Users
   • Create user accounts for new admins.
   • Assign appropriate roles and permissions based on their responsibilities.
   • Ensure they have access to the necessary tools and training.
2. Ongoing Management
   • Regularly review user roles and permissions.
   • Make updates as needed, especially when an admin's responsibilities change.
   • Conduct periodic security awareness training to keep admins informed about the latest threats and best practices.
3. Monitoring Activities
   • Use SIEM tools to monitor admin actions and detect any suspicious behavior.
   • Set up alerts for any activities that deviate from normal patterns.
4. Offboarding Users
   • Promptly disable or delete accounts for admins who are no longer with the organization.
   • Review and revoke any access to critical systems and data.
   • Conduct exit interviews to gather any knowledge transfer that might be needed.
5. Continuous Improvement
   • Regularly assess the effectiveness of your SIEM correlation strategies.
   • Use feedback from admins to enhance the onboarding and offboarding processes.
   • Stay up-to-date with the latest SIEM technologies and best practices.

By following these steps, you can help ensure that your SIEM correlation efforts are effective and that your organization's data remains secure.

event RoleGranted(bytes32 indexed role, address indexed account, address indexed sender);
event RoleRevoked(bytes32 indexed role, address indexed account, address indexed sender);
event Paused(address indexed by);
event Unpaused(address indexed by);

• SIEM rule: set up an alert whenever the role changes to DEFAULT_ADMIN_ROLE or when Paused is emitted; also, link it with the receiptsRoot proof for quarterly records. (docs.openzeppelin.com)

3) Subgraph Topic Filters to Cut Down on Noise

When you're diving into data analysis, sometimes it can feel like you’re swimming in a sea of noise. That's where subgraph topic filters come in handy! They help you focus on what really matters. Here’s how you can use them effectively:

• Narrow your scope: By applying filters to specific topics, you can zero in on the information that’s most relevant to your research or project.
• Improve clarity: Reducing noise means clearer insights. Once you filter out the distractions, the data trends and patterns become way easier to spot.
• Save time: With less irrelevant data to sift through, you can analyze and interpret your results faster.

To get started, you might want to consider using parameters that suit your needs. Here’s a quick example:

# Example of filtering a subgraph
filtered_data = subgraph.filter(topic='your_topic_here')

Utilizing these filters can really elevate your data analysis game!

eventHandlers:
  - event: RoleGranted(indexed bytes32,indexed address,indexed address)
    handler: handleRoleGranted
    topic1: ['0x00...00'] # DEFAULT_ADMIN_ROLE

• You handle a lot fewer events while still maintaining the same level of accuracy. (thegraph.com)

---

Emerging practices to watch

• The ERC‑7699 “TransferReference” is picking up steam for payment reconciliation. It’s super handy for ERP connections and procurement processes that need a solid, unchangeable reference. Check it out here: (eips.ethereum.org).
• There are ongoing discussions about possibly removing or reworking bloom filters. The key takeaway? Don’t tie your SLAs to how well these filters perform; just make sure you’ve got efficient receipt scans and indexing in place. More details can be found here: (ethereum-magicians.org).
• Client-side pruning and history expiry are becoming the norm. Make sure you have a plan for archive/era retrieval or proofs to keep those compliance deadlines on track. For more information, visit: (geth.ethereum.org).

---

How 7Block executes (and what you get in 90 days)

• Weeks 1-2: Schema and Control Mapping Workshop
  • Identify the state changes that matter most for SOC2/SOX and BI KPIs; design event signatures, versions, and proof requirements that we can work with.
• Weeks 3-6: Solidity Implementation and Audits
  • Instrument the contracts; add dual-readable/searchable fields; set up "critical control" events; and carry out a focused review through our security audit services.
• Weeks 4-8: Data Plane and SIEM Integration
  • Create reorg-safe subscriptions and backfill workers; implement subgraph topic filters; make sure we have proof materialization for control events; and connect Splunk/Datadog rules through our blockchain integration.
• Weeks 8-12: Scale and Handoff
  • Develop an archive/retention plan; set up dashboards; create runbooks; and prepare procurement-ready documentation along with SOC2 evidence packs.

Related capabilities:

• End-to-end delivery: Check out our custom blockchain development services and web3 development services.
• Product buildouts: We specialize in dApp development to help bring your ideas to life.
• DeFi analytics stacks: Dive into our DeFi development services for all your decentralized finance needs.

GTM Proof Points (Typical 90-Day Pilot Outcomes)

• You can expect a 30-60% drop in ETH/RPC costs for backfills by using topic filters and range chunking.
• We’re seeing over 99.95% accuracy in log ingestion, even during reorgs, which we measure against receiptsRoot.
• Getting ready for audits is way quicker now--what used to take weeks is down to just days thanks to our packaged log proofs and control event catalogs.

---

Implementation checklist (save/print)

• Event Design
  • Make sure all important state transitions kick out one versioned, non-anonymous event.
  • Emit dynamic values in both indexed (hash) and unindexed (cleartext) formats when necessary.
  • Precompute topic0 in the codebase where it makes sense (event.selector, ≥0.8.15) (soliditylang.org)
• Solidity
  • Take a close look at the gas budget (375 base + 375/topic + 8/byte data) and run tests using realistic payloads (studylib.net).
  • Don't depend on events for on-chain logic (remember, contracts can’t read logs) (docs.soliditylang.org).
• Ingestion
  • Set up Websocket subscriptions with removed:true handling; create an idempotent sink keyed by (blockHash, txHash, logIndex) (geth.ethereum.org).
  • Implement backfill workers that utilize provider-aware range chunking and parity checks against explorer topic0 (docs.blastapi.io).
  • Configure subgraph topic filters for dimensions with high cardinality (thegraph.com).
• Proofs and Retention
  • Document the ReceiptsRoot verification path for auditors; make sure to store proof artifacts.
  • Plan for an archive node or a retrieval strategy for pruned history (in the context of EIP‑4444) (eip.directory).

---

If you're looking for reliable events and logs that your BI, SIEM, and auditors can count on--without burning through your budget or timeline--we're here to help you define, create, and validate it all from start to finish.

Book a 90-Day Pilot Strategy Call

Looking to kickstart your project or business? Let's chat! A 90-Day Pilot Strategy Call could be just what you need. Here’s what to expect:

• Personalized Consultation: We’ll dive deep into your specific needs and goals.
• Tailored Action Plan: Get a clear roadmap for the next 90 days.
• Expert Insights: Benefit from industry best practices and proven strategies.

Ready to take the plunge? Schedule your call here. Can't wait to help you make some magic happen!

Key references for your engineering team:
- Events/logs structure, topics, and dynamic hashing: Solidity ABI and docs. ([docs.solidity.org](https://docs.solidity.org/en/latest/abi-spec.html?utm_source=7blocklabs.com))
- Gas costs for LOG opcodes: Yellow Paper schedule. ([studylib.net](https://studylib.net/doc/27453445/yellow-paper?utm_source=7blocklabs.com))
- Subscriptions and reorg semantics: Geth RPC pubsub. ([geth.ethereum.org](https://geth.ethereum.org/docs/interacting-with-geth/rpc/pubsub?utm_source=7blocklabs.com))
- Bloom filters and limitations: 2048-bit blooms, false positives, and ongoing discussions. ([pureth.guide](https://pureth.guide/logs-bloom/?utm_source=7blocklabs.com))
- ERC‑20 canonical events; ERC‑7699 extension. ([eips.ethereum.org](https://eips.ethereum.org/EIPS/eip-20?utm_source=7blocklabs.com))
- ReceiptsRoot and proofs: Ethereum tries and log proof methodology. ([ethereum.org](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/?utm_source=7blocklabs.com))