Skip to content

Conversation

@JustinBeBoy
Copy link
Contributor

@JustinBeBoy JustinBeBoy commented Dec 28, 2025

Close #3457

This PR:

  • fix incorrect usd fee error when sending usdc.
  • Add a polling-based scanner with block-range chunking to retrieve transaction history.

Screen Shot:

  • USD fee:

p1 p2 p3

  • Transaction history

before:

p1 p2

after:

pr1

Copy link
Member

@peterzen peterzen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you for working on this @JustinBeBoy .

@JustinBeBoy
Copy link
Contributor Author

LGTM. Thank you for working on this @JustinBeBoy .

There's still an issue regarding the transaction history that I'm trying to resolve.

@JoeGruffins
Copy link
Member

Looks good. I notice there is a usd price here for the base coin but not for the token. Under Amount. Can you try to fix it too?

image image

@JustinBeBoy
Copy link
Contributor Author

Looks good. I notice there is a usd price here for the base coin but not for the token. Under Amount. Can you try to fix it too?

image image

Let me fix it.

@JoeGruffins
Copy link
Member

I'm not sure the transactions not showing up is a bug. Will put more on the issue.

@JoeGruffins
Copy link
Member

JoeGruffins commented Dec 29, 2025

As @martonp said on the issue, we might not be able to get the incoming transactions. If you just fix the amounts with this pr it's fine. Maybe a note in the UI about not showing incoming transactions if you are ok with making that. Don't worry about it too much as may be impossible currently.

@JustinBeBoy
Copy link
Contributor Author

Looks good. I notice there is a usd price here for the base coin but not for the token. Under Amount. Can you try to fix it too?

image image

I've researched this issue, and it might not be a bug, but rather that rate sources could be disabled or failing (network error, API rate limit), hiding the USD element. It seems that stablecoins like USDC might not be supported by all APIs.

@JoeGruffins
Copy link
Member

I've researched this issue, and it might not be a bug, but rather that rate sources could be disabled or failing (network error, API rate limit), hiding the USD element. It seems that stablecoins like USDC might not be supported by all APIs.

Ok no big deal. If it's not a bug just leave it.

@JustinBeBoy JustinBeBoy marked this pull request as ready for review January 6, 2026 04:51
Copilot AI review requested due to automatic review settings January 6, 2026 04:51
@JustinBeBoy
Copy link
Contributor Author

@JoeGruffins please help me review and test it.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a bug where the USD fee estimate was calculated incorrectly when sending USDC or other token assets. The issue occurred because tokens pay transaction fees in their parent asset (e.g., USDC on Polygon pays fees in MATIC), but the USD conversion was incorrectly using the token's fiat rate instead of the parent asset's rate.

Key Changes:

  • Fixed USD fee calculation to use the parent asset's fiat rate and unit info when sending tokens
  • Added polling-based transaction history scanner (per PR description, but not visible in provided diffs)

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@JustinBeBoy JustinBeBoy force-pushed the udsc_polygon_irregularities branch from b9894e1 to af4a3bc Compare January 6, 2026 08:05
Comment on lines +7314 to +7319
// Create IERC20 filterer to parse Transfer event
// We can pass nil for filterer since we're only parsing, not filtering
filterer, err := erc20.NewIERC20Filterer(w.tokenAddr, nil)
if err != nil {
return fmt.Errorf("error creating IERC20 filterer: %w", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like filterer can be a field of the assetWallet and you don't need to make it every time just when creating the asset wallet.

Comment on lines +7373 to +7374
w.log.Errorf("Error getting last scan block for asset %d: %v", w.assetID, err)
return fmt.Errorf("error getting last scan block: %w", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this log twice? If so no need for the extra log.

return nil
}

func (db *tTxDB) GetLastIncomingScanBlock(assetID *uint32) (uint64, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func (db *tTxDB) GetLastIncomingScanBlock(assetID *uint32) (uint64, error) {
func (db *tTxDB) LastIncomingScanBlock(assetID *uint32) (uint64, error) {

Can leave out the Get in golang.

Comment on lines +5298 to 5303
// Scan incoming ETH transfers for base wallet
// Note: ETH scanning is expensive and may be skipped in production
// For now, we focus on token transfers which use event logs
if err := eth.scanIncomingETHTransfers(ctx, bestHdr.Number.Uint64()); err != nil {
eth.log.Errorf("Error scanning incoming ETH transfers: %v", err)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this doesn't do anything currently. Can remove all code related to it.

Scanning every block for transactions is not feasible. There are over 24 million blocks atm and the block time is 12 seconds. We MUST have the transactions already indexed, somehow, somewhere. Probably would need to just ask a block explorer.

if tip > 1000 {
startBlock = tip - 1000
} else {
startBlock = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not scanning from block zero. That's 4,800 requests to the node if 5000 chunks and 24 million blocks. This is not feasible. Am I mistaking something?

It looks better than the eth transactions, but I think here too we need an indexer to query or it's just too much to have the wallet do.

Would like an opinion from @martonp on this

Copy link
Member

@JoeGruffins JoeGruffins Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry, it's only going 1000 blocks back if initial sync. It should be from the app birthday though... eth would be making 3600 blocks a day? idk...

@JoeGruffins JoeGruffins requested a review from martonp January 7, 2026 02:42
transactionReceipt(ctx context.Context, txHash common.Hash) (*types.Receipt, error)
transactionAndReceipt(ctx context.Context, txHash common.Hash) (*types.Receipt, *types.Transaction, error)
nonce(ctx context.Context) (confirmed, next *big.Int, err error)
FilterLogs(ctx context.Context, query ethereum.FilterQuery) ([]types.Log, error)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would need to be lower case and go through *multiRPCClient which can be used to pick good providers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

USDC/Polygon wallet irregularities

3 participants