Account Abstraction Telemetry: What to Log (and What Not To) in 2025

Description

By 2025, we’ll see EIP-7702 in action, and ERC-4337 will still be progressing, especially with EntryPoint v0 making some solid moves. 8 and beyond. This change is really changing the game for what we think of as "good" telemetry for smart accounts. Think of this playbook as your trusty guide to figuring out the signals you need to keep track of across wallets, bundlers, paymasters, and all that on-chain action. It's got your back! It also talks about what to skip when it comes to keeping security and privacy in check.

Who this is for

If you're a decision-maker at a startup or a bigger company diving into or planning to grow your blockchain products using account abstraction (AA), you're likely a product lead, a platform owner, or an engineering manager.

Why telemetry for AA changed in 2025

Three Ecosystem Shifts That Shaped AA Observability This Year:

1. The Boom of AI-Driven Insights

Hey there! Let’s chat about something that’s been making waves lately: AI-driven insights. It's amazing how much these technologies have evolved, right? We're seeing more and more businesses tapping into artificial intelligence to gain a deeper understanding of their data. Essentially, AI is helping companies uncover trends and patterns that might have gone unnoticed before.

Think about it: with the right tools, businesses can analyze huge amounts of information in no time. This not only makes decision-making faster but also more informed. As a result, companies can optimize their strategies and connect better with their customers.

It’s pretty exciting to see how AI is reshaping industries and opening up new possibilities for innovation. Can't wait to see what comes next! This year has really brought a wave of AI tools that are changing the game when it comes to analyzing and understanding data. They can quickly go through tons of information and grab those valuable insights faster than ever! It's kind of like having a really clever buddy by your side, helping us untangle all the confusion!

2. Bigger Emphasis on Data Privacy. As worries about data privacy keep rising, companies are really starting to focus on being transparent about how they handle data. This change really highlights the need for observability tools to step up their game. They have to find a way to offer valuable insights while also making sure that user data stays secure and protected. Finding a good balance between being open and respecting privacy is really becoming the standard these days.

3. Integration of Multi-Cloud Environments. With more and more companies jumping on the multi-cloud bandwagon, keeping tabs on everything across different platforms has become super important. This change shows that our tools really need to step up and give us a unified look at all our applications and services, regardless of where they're hosted. It's really about tying everything together for a seamless experience.

Hey everyone! Exciting news--EIP-7702 has officially launched with Pectra, and it went live on the mainnet on May 7, 2025! This update introduces Type-4 “set-code” transactions, which means that externally owned accounts (EOAs) can now hand over execution to contract code for a little while. Pretty cool, right? We're starting to see a bunch of wallets and dapps rolling out 7702 authorizations in pretty large numbers. It's definitely picking up steam! You really need to stay on top of these authorizations and be aware of the risks that go along with them. (theblock.co).

ERC-4337 is still making its way out there, and the majority of providers have now upgraded to EntryPoint v0. 7, with v0. Version 8 is starting to become quite popular, and we're at v0 now. 9 on the way. Just a heads up: the different versions really affect how validation, data packing, and error reporting go down. So, it’s super important to ensure your logging is in tune with the version you’re using! You can check out more details here.

Hey there! Exciting news: the ERC-4337 Shared Mempool has gone from being just a concept to actually happening on the main networks! This change is shaking things up when it comes to inclusion guarantees and what bundlers have to demonstrate regarding health and their ability to resist censorship. (etherspot.io).

Adoption has really skyrocketed! In 2024, we hit over 100 million UserOps, and a whopping 87% of those were backed by paymasters. Pretty impressive, right? As we rolled into late 2024 and headed into 2025, things really started heating up on Base, Polygon, and Optimism! Feel free to use this data to compare it against your own funnels! For more info, take a look here: panewslab.com. You’ll find all the details you need!

The AA telemetry surface (map-first, then instrument)

Keep an eye on signals across six different layers. Every layer comes with a “log this” area where you can jot down important details at the field level. There's also a place for “derived metrics” to keep track of those calculated values, plus a “don’t log” section for anything you’d rather not record.

1) Wallet & Client (SDK, Browser/Mobile)

Log This

userOp_id (this is a temporary UUID that we use on the client side). Hey there! We’ve picked up on a couple of things: the chain_id and entrypoint_version are set to v0. 6/v0. 7/v0. 8).
Account Type: 4337_account | 7702_eoa.
signature_scheme: ecdsa | 1271 | p256_webauthn | multisig | session_key.

So, here's the scoop on the signature schemes: we've got ecdsa, which is pretty popular, and then there's 1271, p256_webauthn, multisig, and don’t forget about session_key. Each one has its own vibe and use cases, so it's good to keep them in mind! Hey there! If you're working with 7702, don't forget to log these fields: authorization_list_count, delegate_address, auth_nonce (make sure it's 64-bit), and set tx_type to 0x04. Just a little reminder to keep everything in check! Hey, just a quick heads up: don’t forget to check out the 6492 usage flag when you’re signing those counterfactual contracts (you know, the predeploy signatures). If you’re looking for more info, you can find it over at eips.ethereum.org. Make sure to add in gas_estimate_userop and specify the estimation_method you’re using, whether it’s the simulateValidation method or the heuristic approach.

Submission Options: You can go for shared mempool, use a private bundler, or connect directly through RPC. It’s all about what suits your needs best!

Derived Metrics

Keep an eye on the client_sign_error_rate based on the signature_scheme.
Check out the 7702 authorization acceptance rates compared to rejections (following the wallet policy). To figure out the estimation_error_drift, you just need to take the absolute value of the difference between the simulated gas and the actual gas, and then divide that by the actual gas. So, it looks like this:

estimation_error_drift = abs(simulated_gas − actual_gas) / actual_gas.

Don’t Log

Make sure to leave raw signatures out of your logs. Instead, just save the hashes. Also, don't forget to keep things like passkey attestation blobs, biometrics, seed phrases, device fingerprints, and IP addresses that are linked to wallet addresses off those logs too--that stuff is considered personally identifiable information (PII), and you definitely want to handle it with care! Hey, just a heads up: the CPRA/CCPA classifies IP addresses and account log-ins as personal or sensitive info. So, to play it safe, let’s keep the scope and how long we keep that data to a bare minimum. (oag.ca.gov).

2) Bundler

Log this You’ve got a few key elements here: userOpHash, which is like a unique ID for the operation, then there’s sender, the one making the move. Don’t forget about nonce, that’s the counter to keep things in order. And if there’s a paymaster involved? That’s just an extra layer to consider.
validation_outcome: passed, reverted, or throttled (ERC‑7562). Alright, so here’s the breakdown:
Revert Class: This includes details about the signature, paymaster, init code, aggregator, gas, and 7702 authentication.

Let me know if you need any more info or if there's something specific you want to dive deeper into! So, to calculate the inclusion latency in milliseconds, you just take the time when the operations were submitted and subtract the time when the user operation was received. It's pretty straightforward!

bundle_size, bundle_simulation_pass_rate
mempool_mode: you can choose between shared or private; then there's peer_count, and let's not forget about the gossip_success_rate. So, the entrypoint_version is what you’ll want to use when you're running simulations or submitting your stuff.
Derived metrics
We're looking at the p50/p95 inclusion latency in milliseconds separated by each chain.
The simulation_to_onchain_mismatch_rate refers to any time a handle operation fails after it looked good in the simulation. So, there have been a whopping 7,562 rule violations categorized by code class, like AUTH‑020/030/040, STO‑031/033, and LIM‑010/050, among others. If you're curious about the details, you can check it out at eips.ethereum.org.
Don’t log
Store the complete callData and initCode for each operation. Just hash it for regular use, but if there's an error, hold onto the raw data for a limited time.
We have some peer IPs connected to the sender addresses (but hey, we’ve got to keep things private, right?).

3) Paymaster (Sponsorship & Policy)

Log this
We've got a policy_id, and the decision can be one of three options: approve, deny, or challenge.
- token_pricing_source and price_timestamp
- quoted_token_fee, actual_gas_cost_wei, refund_deltas
- deposit_balance, min_reserve_threshold, stake_status Here are some of the reason_codes you might come across when dealing with denials, such as risk_score_high, unknown_contract, and quota_exceeded.
Derived metrics
Let's check out the approval_rate based on the app_id and chain_id.
- slippage_between_quote_and_actual (%) So, when we talk about "sponsor ROI," we're basically looking at the number of users who stick around after a certain number of days, divided by the total amount spent on gas. Pretty straightforward, right?
Don’t log
You’ll get complete snapshots of ERC-20 allowances for each user. Just make sure to only keep the differences or some anonymized totals.

4) On-chain Results (EntryPoint & Account Events)

Alright, let’s get this info down (from receipts and events): So, when we're talking about UserOperationEvent, there are a few key fields you should know about: the sender, paymaster, the actual gas cost, and whether or not the whole thing was successful. For handleOps, keep an eye on the gas used for each operation and bundle.

Make sure to jot down the EntryPoint address and the code hash. This little step can really help you keep track of any updates or version changes!
Derived Metrics:
Here's a breakdown of actualGasCost, organized by account type and chain. Sure! Let's whip up a heatmap to visualize the reasons for failure in relation to the revert class from the bundler. This will help us easily identify patterns and understand what's going wrong.
Version Anchors:
- v0.6: 0x5FF1…2789;
- v0.7: 0x0000…7032;
v0. If you're dealing with sizes 8 and up, just keep in mind that they can differ depending on the provider. Don't forget to keep a registry too! For more info, feel free to head over to alchemy.com. You'll find a lot of useful stuff there!

5) EIP‑7702 Telemetry (Type‑4 Set‑Code)

Log this So, we've got this piece of data where tx_type is set to 0x04. Then, there’s the length of the authorization_list to consider. For every authorization, we need to look at a few things: first, there’s the delegate_address, which takes up 20 bytes, and then there's the auth_nonce, which is a 64-bit unsigned integer (u64).
delegate_contract_hash (this is the EXTCODEHASH when you submitted it). Hey, just wondering, was that change rolled back? If it was, do you know why?
Derived Metrics
Keep an eye on how the adoption of 7702 has been changing over time. Also, take a look at how different auth lengths are being distributed. And don’t forget to monitor the rate of those “unknown delegates”! Let’s break it down into two categories: first-party delegate data and third-party data (which we often refer to as allowlist data).
Context We're really curious to see how the waves of 7702 adoption roll out after the Pectra upgrade. It’s worth noting that there were actually thousands of authorizations right in that first week!
Oh, and don’t forget to pay attention to how changes in wallet user experience are making authorization prompts a lot more noticeable. Let's start keeping an eye on those "unsafe prompt accepted" events in wallets. This could really help us reduce scams and protect ourselves better. If you're curious to learn more, you can take a look at all the details right here.

6) Network & Mempool Propagation

Log this
Is shared_mempool_enabled set to true or false?
What’s the peers_count looking like?
How are the gossip_msg_in and gossip_msg_out rates doing?
Check the re-broadcast_count before we include it, and see if alternate_bundler_observed is true or false.
Derived metrics
Censorship Resistance Proxy: This basically looks at what percentage of UserOps are picked up by a different operator instead of the one that originally submitted them.
Time Until Peers First Notice You (p95).
Context So, guess what? The Shared Mempool made its big debut on the mainnet--covering Ethereum, Arbitrum, and Optimism--back in late 2024! Exciting times ahead for all of us in the crypto world! So, there are some exciting plans in the works for gossip health metrics and multi-bundler routing! If you want to dive deeper into this topic, check it out here. Happy reading!

What not to log (privacy, security, and legal)

Steer clear of collecting: things like seeds, private keys, raw passkey materials, biometric templates, session keys, any email content, plain text authentication tokens, or full IP address mappings linked to wallet addresses. Honestly, it’s just not worth it.
Keep it simple: For those raw user-signed payloads, all you really need to do is save the keccak256 hash. When it comes to callData/initCode, it’s best to stick with hashing as the default. Only save the raw data if something goes wrong.
Treat device IDs and IPs like they're top secret: In California, stuff like account log-ins, exact locations, and your credentials are seen as “sensitive personal information.” So, it's important to be careful with them! “Hey, it’s definitely smart to give users a way to opt out and have some boundaries on how long you keep their data.” (oag.ca.gov).

Hey there! Just a quick reminder to keep those data minimization and storage limits in mind. It’s super important to stick to the guidelines laid out in GDPR Article. Keep it simple and don’t hold onto more info than you really need! You're fully tuned in during your telemetry processes. (gdpr.org).

Field‑level logging: concrete examples

Check out these super useful JSON patterns that you can quickly snag and incorporate into your logging schemas!

1) Bundler Validation Attempt (ERC-7562-Aware)

{
  "ts": "2025-12-01T16:20:07Z",
  "component": "bundler",
  "entrypoint_version": "v0.8",
  "chain_id": 8453,
  "userOpHash": "0x…",
  "sender": "0xabc…",
  "nonce": "3",
  "paymaster": "0xdef…",
  "mempool": "shared",
  "validation": {
    "outcome": "reverted",
    "revert_class": "paymaster",
    "erc7562_rules": ["STO-033"],
    "simulation_ms": 57
  },
  "bundle": {
    "id": "bdl_20251201_00042",
    "size": 36
  }
}

Alright, so what you want to do is tie the “revert_class” to the simulation results from ERC‑4337. Don’t forget to throw in any important bits from the ERC‑7562 code, along with any storage details or local rule identifiers you might need for troubleshooting later on. This way, you’ll have everything covered and ready to go! Want to dive into the details? Just head over to this link: (eips.ethereum.org).

2) Paymaster Policy Decision

When it comes to figuring out the Paymaster policy, there are a few important things to think about. The main aim is to make sure the policy does what it’s supposed to do while also being fair and efficient for everyone involved.

Key Considerations

1. Transparency: It’s really key for everything we do to be clear and open. We really want everyone to be in the loop about how decisions are made and what factors play into those choices.

2. Efficiency: This policy is all about making operations run more smoothly and quickly. It's designed to cut through the clutter and help things flow better. We really need to pinpoint any bottlenecks and sort them out. Let’s get to the bottom of this!

3. Flexibility: Things can shift really fast out there, so we’ve got to be ready to change our policy accordingly. Let’s keep an open mind about updating the policy whenever we get new feedback or see changes happening in the field.

4. Getting Everyone Involved: It’s super important to chat with all the folks who will be impacted by the policy. Let's make sure their voices are heard! Let's make sure we get everyone's thoughts and opinions so we can really hear all the voices out there.

Next Steps

Check Out the Current Policy: Let’s dive into the current policy and see if there are any spots that could use a little refresh.
Get Feedback: We’re going to touch base with stakeholders to hear their thoughts and any ideas they might have. You might gather this information through surveys, casual meetings, or even just some friendly conversations.
Draft Revisions: After we get your feedback, we'll whip up a revised draft of the policy.
Approval Process: After the draft is all set, it'll make its way through the required reviews and get the green light from the right folks.

Conclusion

When we really hone in on these areas, we can ensure that the Paymaster policy not only hits its goals but also works well for everyone involved. I’m really excited for us to team up and get this done! Let’s make it happen!

{
  "ts": "2025-12-01T16:20:08Z",
  "component": "paymaster",
  "policy_id": "pm_gasless_v5",
  "chain_id": 8453,
  "app_id": "game_xyz",
  "decision": "deny",
  "reason_codes": ["quota_exceeded", "unknown_contract"],
  "quoted_token_fee": "1.23 USDC",
  "pricing_source": "oracle_7",
  "deposit_balance_eth": "32.1",
  "min_reserve_eth": "25.0"
}

3) 7702 Authorization Observability

So, when we chat about 7702 authorization observability, we're really getting into the nitty-gritty of how we can track the authorizations that fall under Section 7702 of the Internal Revenue Code. It’s all about keeping tabs on those approvals! This is really crucial for making sure we're following the rules and getting a clear picture of how data moves around. Here’s a quick breakdown:.

So, what’s Section 7702 all about? So, Section 7702 basically lays out the rules that life insurance policies need to follow if they want to score some sweet tax benefits. This legislation is super important for both insurance companies and the folks who hold the policies.
Why Observability Matters When we talk about observability here, we're really focusing on the ability to keep an eye on and dig into the authorizations linked to these contracts. By staying on top of this, companies can:
Make sure they're following all the legal stuff.
Easily catch any problems or inconsistencies.
Use data insights to guide your decisions with confidence.
Tips for Doing Observability Right. To nail this, it’s a good idea to set up a few important habits.

1. Logging: Just a heads up to ensure that all authorizations are recorded correctly. Thanks! This covers stuff like who gave the thumbs up for what and when it all went down.

2. Monitoring: Get some real-time monitoring systems in place that can ping you when something seems off with the authorization process.

3. Reporting: Create detailed reports that showcase trends and patterns in how authorizations are being handled.

If you really dive into these practices, you'll boost your organization's observability big time. This means you'll have a much easier time making sure everything's compliant and running smoothly!

{
  "ts": "2025-12-01T16:20:10Z",
  "component": "wallet",
  "tx_type": "0x04",
  "authorization_list_length": 1,
  "delegate_address": "0x7f…",
  "auth_nonce": 9,
  "delegate_codehash": "0x4b…",
  "policy": {
    "allowlisted_delegate": false,
    "user_prompted_read_contract": true,
    "blocked_patterns": []
  },
  "submitted_via": "canonical_txpool"
}

Hey, take a look at Codehash if you want to spot any delegates that might be faking it! You might want to watch the length of the authorization list to catch any weird multi-delegate prompts that seem off. EIP-7702 breaks down the tuple format and gives us the scoop on Type-4 encoding details. If you want to dive deeper into it, check it out here. Happy reading!

Version‑aware logging and alerts (4337 v0.6 → v0.8+)

Hey, just a quick reminder to jot down the EntryPoint version for every simulation and bundle you work on. It'll save you some headaches later on! Most providers typically display addresses for version 0. 6 and v0. 7, but with v0. With version 8, there are some cool new optimizations and updated validation rules to consider. It's really crucial to set up alerting rules for each version to avoid any pesky false positives. For example, the behavior after an operation (postOp) and the structured errors can vary quite a bit, so having those rules in place helps a ton! (alchemy.com).

Keep an eye on those deprecation timelines! A few providers are thinking about gradually moving away from v0. It's a good idea to start thinking ahead to around 2026, especially since support is expected to be around that time. When you're in the middle of a migration, setting up a dual-stack can really come in handy. It’s also a good idea to keep an eye out and alert yourself if any user operations are trying to get sent to a version that’s no longer supported. You don’t want to run into any surprises there! (alchemy.com).

Make sure to have a quick reference for all the EntryPoint addresses for each chain. It’ll come in super handy! For v0. 6 and v0. So, the addresses are pretty much set in stone, you know? And then there's v0. The folks who take care of the project publish versions 8 and later. Oh, and one more thing - make sure you check those code hashes when you fire things up! It's super important. You can find more details over at alchemy.com.

Shared Mempool metrics to adopt

So, if you’re diving into the ERC-4337 Shared Mempool, here’s what you need to know:

Make sure to monitor the peer_count, along with the gossip_in_rate, gossip_out_rate, and peer_reputation. Hey there! So, you might want to keep an eye on origin_bundler and included_by_bundler. These metrics help you understand how well your users' operations are getting included by others, which is pretty much a measure of censorship resistance. It's a good way to see how often they're getting a nod in the community!

Go ahead and set up some alert thresholds:
If you notice that the gossip_in_rate takes a nosedive of more than 50% for 5 minutes, that's your cue to dig in and start checking things out. Hey, just a heads up--if you notice that the p95 inclusion_latency is going over 60 seconds on L2s that typically run without a hitch, that’s definitely a warning sign. Hey there! Just a reminder to keep track of the networks you're working with -- think Ethereum, Arbitrum, and Optimism. Also, don’t forget about Polygon; its status can shift, so it’s good to stay updated. Make sure to include some health metrics for each of these networks, too! Take a look at this: (etherspot.io). You won’t want to miss it!

Don’t skip ERC‑7562 conformance telemetry

ERC-7562 sets some important boundaries during the validation phase to help prevent Denial of Service attacks. It focuses on things like controlling who can access storage or code, handling reputations, and keeping an eye on maximum sizes. These measures are designed to strengthen security and ensure smoother operations. Make sure you keep an eye on these counters: AUTH‑020, AUTH‑030, AUTH‑040, STO‑031, STO‑033, and LIM‑010, LIM‑020, LIM‑030, LIM‑040, LIM‑050. They're pretty important! It's super important to set up some guidelines for state transitions--like putting in place bans and throttling. Also, throwing in “opsSeen vs opsIncluded” can really help illustrate that you’re being upfront and playing it straight. If you’re managing infrastructure, here are the key metrics that other players in the ecosystem will be keeping an eye on. (eips.ethereum.org).

Practical dashboards and queries you can ship this quarter

Check out BigQuery on the Optimism Superchain, where you can explore the public 4337 dataset.
You can easily track paymaster gas expenses by label all in one go! Plus, you can expand on this to do some cohort analysis or set up budget alerts if you want.

SELECT
  labels.name AS paymaster_label,
  SUM(CAST(opdata.actualGasCost AS NUMERIC)) AS gas_wei
FROM `your_dataset.optimism_superchain_4337_account_abstraction_data.useroperationevent_logs_v2` AS opdata
LEFT JOIN `4337metrics.labels` AS labels
  ON opdata.paymaster = labels.paymaster
WHERE opdata.dt = "2025-04-09"
  AND opdata.paymaster != "0x0000000000000000000000000000000000000000"
GROUP BY paymaster_label;

Take a look at this easy step-by-step guide on how to create your own custom 4337 metrics using public datasets and labeled addresses. Hey there! If you’re looking for all the nitty-gritty details, just swing by docs.erc4337.io. There’s a ton of info waiting for you!

Bundler Test Conformance Hey! Just a quick reminder to share your latest results from the ecosystem’s bundler test matrix. Also, don't forget to export those results into Grafana. Thanks! Just a heads up: make sure to watch out for any regressions when you update to the new 4337 versions. Take a look at this link: bundlers.erc4337.io. You might find something interesting there!

SLOs that correlate with AA business outcomes

Adopt SLOs that Connect Directly to UX and Cost:

When you're putting together Service Level Objectives (SLOs), it's really essential to connect them with user experience (UX) and keeping costs in check. This connection makes sure that your service doesn't just hit those technical marks but also keeps users happy and stays on budget too. So, here's a simple way to tackle it:

1. Pinpoint Important User Journeys: First things first, take some time to understand the key routes your users follow when they’re engaging with your product. You want to get a good grasp on how they navigate through it! Concentrate on the moments that truly mean something to them.

2. Gauge User Experience Metrics: Figure out which metrics really capture the essence of user experience, like:

Response Time: So, how fast does the system get back to you when you make a request?
Error Rate: So, how often do user interactions actually end up with mistakes? What’s the percentage?
Uptime: So, how reliable is your service for users? How often is it up and running?

3. Keep an Eye on Costs: It’s super important to find a sweet spot between user experience and budget. Staying efficient with services doesn’t have to come at the cost of quality. Consider these factors:.

Cost per Transaction: What’s the price tag for each time a user interacts with us?
Resource Allocation: Are you making the most of your resources while still keeping the user experience top-notch?

4. Set SMART SLOs: You've gotta nail down your goals so they’re Specific, Measurable, Achievable, Relevant, and Time-bound. Trust me, it really helps to keep everything focused and on track! For example:.

Let’s aim to get our response time down to under 200 milliseconds for 95% of user requests by the end of next quarter.
Keep the error rate for important user transactions under 1% all year round.

5. Keep an Eye on Things: Since user needs and costs can shift over time, it’s super important to revisit your SLOs every now and then. Just a little check-in can go a long way! Keep an open mind and be ready to tweak things based on what users have to say and the latest financial reports.

When you link your SLOs to user experience and costs, you strike a nice balance that boosts user satisfaction without breaking the bank. It’s all about keeping things enjoyable for users while being smart with your spending! It's really all about making sure your service not only meets high standards but also provides great value!

Inclusion latency (p95): Our goal is to keep it to 60 seconds or less for L2 and 120 seconds or less for L1. We measure this time from when a user hits that submit button on an operation to the moment they get the green light that the UserOperationEvent was successful.
Simulation accuracy: Our goal is to keep the gap between the simulated and real values within 15% at the 90th percentile.
Paymaster approval rate: We should aim to keep this at 90% or higher for approved flows. Just make sure that any difference between the quoted gas and what we actually use doesn't go over 10%.
7702 “unsafe prompt” abandonment: We’re aiming for more than 70% of users to reject any non-approved delegates. Don’t forget to configure this in the wallet prompt!
Shared Mempool reachability: It’s important that at least 95% of our peers can be reached during peak times.

Emerging best practices for instrumentation

You can totally use OpenTelemetry with zero-code eBPF on your Go or Node services. This means you'll easily get those basic HTTP/RPC traces without having to tinker with your app code at all! How cool is that? You can also throw in custom spans for particular AA lifecycle steps like simulateValidation, handleOps, and the sponsorship decision. Just a quick note: once everything's set up properly, you can expect to see about 2-5% CPU overhead. (opentelemetry.io).

Hey there! Just a quick tip: when you're naming your attributes, try to stick to the OTel semantic conventions whenever possible. For example, go with things like rpc.system="jsonrpc" or net.peer.name, and don't forget about http. It really helps keep everything neat and consistent! *). When you're working on those AA-specific fields, just remember to keep it consistent with the prefixes. You’ll want to use aa.userop.hash, aa.validation.revert_class, and aa.erc7562.rule. It helps keep everything organized! (github.com).

Hey there! If your wallets are set up with passkeys or using those ERC-1271 or ERC-6492 signatures, what you’ll want to do is simply log the algorithm family--like p256_webauthn--and the signature_hash. Just a heads-up, it’s best to avoid logging any raw attestations. Keep it simple and secure! (eips.ethereum.org).

Make sure to keep an eye on the latest map of the networks and the EntryPoint versions you're working with. It's always good to stay updated! Many providers are currently using version 0. 7 and v0. Just a heads-up! If your client sends version 0, make sure to set up those alerts, especially for the 8 side-by-side. It's super important to stay on top of it! There are 6 user operations that lead to a version 0. 8-only setup. (alchemy.com).

How to detect real risk sooner (telemetry patterns that work)

7702 Delegate Drift
Watch out for any tweaks in the delegate_codehash for any delegate_address that’s on the allowlist. Malware often likes to play tricks by using those “look-alike” delegates. Don't forget to use EXTCODEHASH when you submit your stuff! (eips.ethereum.org).
Validation Instability
Keep an eye out for any "passes sim, reverts on-chain" situations by tracking the different revert classes. If you notice any spikes, it could indicate that something's not quite right with the node state or that there are some discrepancies in the 7562 rules--especially those pesky storage access rules. (eips.ethereum.org).
Sponsorship Exploits
Take a look at how the quoted_token_fee stacks up against the actualGasCost as time goes on. If you see a quick gap opening up between the two, it might be a clue that there’s something fishy going on with the call data patterns or maybe some price oracle drift. Keep your eyes peeled!
Censorship Symptoms
Hey there! If you notice that your shared_mempool peers are dropping down to almost zero but your RPC is still chugging along just fine, it might be a good idea to switch things up and use multi-provider relays. Don't forget to keep an eye on those resubmissions too! This way, you'll be able to figure out if the bundler is actually censoring stuff or if it’s just a problem with the network. (docs.erc4337.io).

A 60‑day rollout plan you can copy

Weeks 1-2: Assess your AA footprint. Make a quick note of the chains you’re working with, the EntryPoint versions, bundler providers, paymasters, and the wallet SDKs you’re using. Just a heads up--don't forget to mention if you’re using 7702 (on/off).
Weeks 3-4: Start implementing basic schemas. Alright, first things first--let’s get those three JSON logs set up. Next, you’ll want to throw in some OpenTelemetry auto-instrumentation for your API edges. Once that's all set, go ahead and link everything up to Prometheus or Grafana, or whatever APM you like best. You’ve got this! (opentelemetry.io).
Weeks 5-6: Let's dive into the Shared Mempool and explore those 7562 metrics. Just a heads-up: don't forget to monitor how everyone’s doing with their health, check out the gossip levels floating around, and pay attention to how quickly people are being included in things. Oh, and make sure to export those 7562 rule counters while you're at it! (docs.erc4337.io).
Weeks 7-8: Tweak those SLOs and alerts. All right, here’s the plan: let’s set some thresholds for each chain. Don’t forget to sprinkle in those budget alerts for the paymasters, too! And hey, we definitely need to make sure we add that 7702 delegate drift alert into the mix.
Weeks 9-10: Show how valuable the product is. Let’s connect the dots between how much you’re spending on sponsorships and how well users stick around by day seven. Keep an eye on those “unsafe prompt” drop-offs, too. And don’t forget to check out your user experience wins--like comparing the 95th percentile latency to your conversion rates.

Common pitfalls to avoid (and how to fix them)

Keeping track of the raw calldata for each UserOp.
Fix: How about we set things up to hash by default? We’ll just keep the raw data on hand in case anything goes sideways, and we can set it to stick around for about 7 days. By doing this, we’re looking out for our users and making sure we don’t go over budget.
Combining different EntryPoint versions in one service without any labels.
Fix: Let’s go ahead and add an entrypoint_version field across the board. This will really help us keep track of dashboards and alerts based on their version, making things a lot easier to manage. If you want to dive deeper, take a look at this resource: (alchemy.com). It's got all the details you need!
Ignoring 7702 completely
Fix: Just a heads-up! Even if 7702 transactions aren't on your radar, keep in mind that users can still give the green light to third-party delegates. It's super important that we catch this and send out warnings in the user experience. Let's keep everyone in the loop! Make sure to keep an eye on the Type-4 volume for your app, too! More info here: (theblock.co).
Thinking of bundlers as a mystery box.
Tip: It’s a good idea to go with providers that share their mempool and simulation metrics. Trust me, it makes things a lot easier! Another option is to set up your own bundler and then share the results of the conformance tests. Get started here: (bundlers.erc4337.io).

Appendix: concrete reference points

Hey, make sure to take a look at the EIP-7702 transaction breakdown--it’s got that Type 0x04 with the authorization_list tuples. Also, don’t forget to check out some important security tips, like the delegate code, nonce, and propagation stuff. It’s all pretty crucial! Here are the important fields you’ll want to keep an eye on for your 7702 logs. If you're interested and want to explore more, check this out: (eips.ethereum.org).

Hey, just a quick reminder to keep the ERC‑7562 validation scope rules in mind! Hey, don’t forget to keep an eye on the AUTH, STO, and LIM classes. Just flag them if you notice anything off! If you want to dive deeper into this, check out this link: eips.ethereum.org. It's got all the details you need!

Make sure to stay updated on the EntryPoint versions and keep an eye on those address anchors! You've got v0. 6/v0. 7 that have set addresses, and v0. Version 8 is rolling out some exciting updates! You'll notice improved validation rules and tweaks to gas penalties. By the way, it’s super helpful to keep your own registry! More info here: (alchemy.com).

Hey, just a heads-up! You should really keep an eye on the status of the Shared Mempool and what it means for design. Those propagation metrics are super important now. Check it out: (etherspot.io).

If you're looking for help with eBPF auto-instrumentation or stabilizing RPC semantic conventions, OpenTelemetry is here for you! Feel free to use this to help make your traces consistent across all your different tech stacks. It's a great way to keep everything organized! More details here: (opentelemetry.io).

Here's a quick market update for you: We're expecting to see more than 100 million UserOps in 2024! Pretty impressive, right? Of those, about 87% are expected to be sponsored by paymasters. Exciting times ahead! Just a heads up as you work on those paymaster budgets and figure out ROI--think of this as your guiding star. It’ll really help steer you in the right direction! Want the latest updates? Check it out here: (panewslab.com).

The bottom line

By 2025, when we talk about “good AA telemetry,” it really comes down to a few key things. First off, you want to make sure you’ve got version-aware logging set up across the 4337/7702 stack. That way, you’ll be able to track those Shared Mempool propagation metrics effectively. You’ll also want to keep tabs on ERC‑7562 conformance counters and get a solid grasp on paymaster economics. And let's not forget the biggie: ensuring that sensitive user data stays out of the mix. It's all about keeping things efficient and secure! If you stick to the schemas, SLOs, and alerts we've outlined in this guide, you'll not only boost your platform's performance, but you'll also give your product and finance teams some solid tools to improve user experience and keep an eye on gas costs as account abstraction keeps moving forward.