[ZK Stack] - Displaying deposit history with thirdweb accounts

[franjohn21]

Team or Project

Treasure

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.75.0

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Hey folks --

I'm running into issues trying to display deposit/withdrawal history for a given address. I am seeing the Deposit transaction show up under an intermediary address when used with Thirdweb.

Expected Behavior

I would ideally like the block explorer API to categorize this as a deposit transaction for the recipient (or sender). 0xb7d834d0c50b03982783dc53274c4fab761e04e5 eg. https://block-explorer.topaz.treasurescan.io/address/0xb7d834d0c50b03982783dc53274c4fab761e04e5/transfers?type=deposit&page=1&limit=10)

Current Behavior

What i'm seeing is that the Deposit transaction is attributed to an intermediary address (vs the destination/sending address). Here's an example:

Scenario: deposit magic for address 0xb7d834d0c50b03982783dc53274c4fab761e04e5 from Sepolia to Treasure Topaz via Thirdweb.

• Sepolia deposit for address 0xb7d834d0c50b03982783dc53274c4fab761e04e5.
• Within the NewPriorityRequest event emitted I see a reference to e528132f0f0b8cad2c4b241b032154526f10de17
• The L2 Block explorer only shows the Transfer transaction for 0xba4d3e1053af06b227de842bca0bb2729b092c23 , not the deposit. Link
• The L2 block explorer categorizes the Deposit transaction under 0xe528132f0f0b8cad2c4b241b032154526f10de17 Link

Questions:

• can the block explorer API return the deposit transaction under the intended recipient (ba4d3e1053af06b227de842bca0bb2729b092c23)
• can I somehow retrieve this intermediary address (0xe528132f0f0b8cad2c4b241b032154526f10de17) so I know where to find the deposit transactions? is it deterministic for a given wallet address/chain?

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

Thank you for detailing the issue you're encountering with displaying deposit and withdrawal history in the Block Explorer when using Thirdweb.

Regarding your questions:

1. Displaying Deposit Transactions Under Intended Recipient/Sender: The Block Explorer is designed to show transactions based on the actual on-chain data. If the deposit transaction is showing under an intermediary address, it suggests that this address is part of the transaction path, possibly as a contract handling the deposits before they reach the final recipient. Unfortunately, the Block Explorer cannot alter how transactions are displayed unless the underlying data it receives changes. This behavior is determined by how the smart contracts for the deposits are coded.

2. Retrieving Intermediary Address: If the intermediary address (0xe528132f0f0b8cad2c4b241b032154526f10de17) is consistently used in the transaction process, it might be a contract address used by Thirdweb for handling deposits. This address is likely deterministic if it's part of a deployed contract's design. However, without specific details on how Thirdweb manages these addresses, it's challenging to confirm if every transaction or wallet will use the same intermediary address. You might need to consult Thirdweb's documentation or support for clarity on this behavior.

For a more tailored solution, you might consider reaching out to Thirdweb to understand if there's a way they can modify the transaction flow or provide additional APIs that could help in correctly attributing transactions to the intended addresses directly in your Block Explorer setup.

For further discussions and support, you can also visit the ZKsync developers discussions on Github.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[franjohn21]

Alright I believe this is either due to refundRecipient or something else but I've figured out the address can be determined by the applyL1ToL2Alias function

[dutterbutter]

Hello @franjohn21 👋

Following up here, can you provide clarity what the current issue / feature request is? I see you've discovered applyL1ToL2Alias function so just want to see if anything has changed. Thanks!

[dutterbutter]

Closing due to staleness, feel free to re-open if needed!