feat: collect auction FIL burned stats

[pyropy]

Adds call handlers for burnForFees method and fixes fee handling for settlements and one-time payments.

Closes #70

TODO

• Ensure deployment passes indexing (there seems to be a Goldsky bug atm)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
filecoin-pay-explorer	Ready	Preview, Comment	Feb 25, 2026 8:49am

[silent-cipher]

Looks good overall, but I have a concern around deployment support.

Goldsky doesn’t currently support trace_filter on calibration, and the fix on mainnet hasn’t landed yet. Since subgraph indexing fails when call handlers are enabled without full RPC support, how are we planning to move forward here? I don’t think we can safely merge this until call handlers are fully supported.

[pyropy]

Looks good overall, but I have a concern around deployment support.

Goldsky doesn’t currently support trace_filter on calibration, and the fix on mainnet hasn’t landed yet. Since subgraph indexing fails when call handlers are enabled without full RPC support, how are we planning to move forward here? I don’t think we can safely merge this until call handlers are fully supported.

Apparently fix has been landed to lotus and the RPC providers have been updated

It might be good to deploy this subgraph independently to test the changes first before merging so we make sure that fix indeed works.

[silent-cipher]

Based on our discussion with Goldsky, call handlers aren’t supported on calibration. Even after the fix, they’ll only be enabled on mainnet.

[pyropy]

Based on our discussion with Goldsky, call handlers aren’t supported on calibration. Even after the fix, they’ll only be enabled on mainnet.

@silent-cipher based on the conversation with the Goldsky team the traces have been enabled for the calibration network.

[silent-cipher]

I tried deploying the subgraph from this branch on both networks, but it fails to index with errors. This suggests that traces haven’t been fully enabled by Goldsky yet -

Error querying traces error = Decoder error: Error("invalid type: null, expected a sequence", line: 0, column: 0) from = 3120650 to = 3120650, sgd: 124450, subgraph_id: QmWXRGPjUQXLcKZJKitC5t658B9JRiyd4oqMMKd6qxSogU

Trying again after trace_filter RPC call for block range: [3120650..3120650] failed (attempt #9) with result Err(Decoder error: Error("invalid type: null, expected a sequence", line: 0, column: 0)), sgd: 124450, subgraph_id: QmWXRGPjUQXLcKZJKitC5t658B9JRiyd4oqMMKd6qxSogU

[BigLep]

@silent-cipher @rjan90 : what's the latest here? Are we unblocked now?

[rjan90]

Latest here is that Glif was running an older version of Lotus on Mainnet. They said they would update to the Lotus v1.35.0 release yesterday.

Following up with them here

[rjan90]

The private endpoints Goldsky was using from Protofire is now returning the correct [ ] result. Endpoints in question:

Mainnet:
https://filecoin.chain.love/load-balancer?token=XXX
https://node.glif.io/fvm-archive/lotus/rpc/v1?token=XXX

Calibnet:
calibration.node.glif.io/archive/lotus/rpc/v1

They are also using calibration.filfox.info/rpc/v1 which has not been updated to the latest Lotus release yet. I have sent an email to contacts at filfox, and in Slack here. But have not gotten a response from the yet

[pyropy]

@silent-cipher would you be able to redeploy the subgraph with the features added in the PR?

[silent-cipher]

I’ve redeployed the subgraph on mainnet with the changes from the PR. However, it seems to be stuck, and I’m seeing the following debug logs:

Trying again after trace_filter RPC call for block range: [5421623..5421672] failed (attempt #3) with result Err(failed to send request: error sending request for url ([REDACTED])), sgd: 125779, subgraph_id: QmS5CahkaGiNPxQQuN6kroR4Ez9vFgj5nLgkqBqAsrwHyt

Error querying traces error = failed to send request: error sending request for url (http://erpc-proxy.erpc.svc.cluster.local:4000/main/evm/314) from = 5421623 to = 5421672, sgd: 125779, subgraph_id: QmS5CahkaGiNPxQQuN6kroR4Ez9vFgj5nLgkqBqAsrwHyt

[BigLep]

would you be able to redeploy the subgraph with the features added in the PR?

Separate issue, but this seems like a bug that we need to ask an individual developer to redeploy a subragph (I assume through the Goldsky UI). How hard would it be to have a gitops deployment pipeline?

[silent-cipher]

How hard would it be to have a gitops deployment pipeline?

It’s actually not very hard to set up a GitOps deployment pipeline. Goldsky already provides a gh action to deploy the subgraph.

The bigger consideration is the release strategy. Since the ui depends on the subgraph url (configured via vercel env), we’d need to:

• Deploy a new subgraph version
• Wait for it to fully sync with the current chain
• Update the vercel environment variable with the new subgraph url
• Then promote the ui to production

So gitops is doable. We just need to carefully design the sequencing to avoid breaking production during sync time.

[pyropy]

I’ve redeployed the subgraph on mainnet with the changes from the PR. However, it seems to be stuck, and I’m seeing the following debug logs:

Trying again after trace_filter RPC call for block range: [5421623..5421672] failed (attempt #3) with result Err(failed to send request: error sending request for url ([REDACTED])), sgd: 125779, subgraph_id: QmS5CahkaGiNPxQQuN6kroR4Ez9vFgj5nLgkqBqAsrwHyt

Error querying traces error = failed to send request: error sending request for url (http://erpc-proxy.erpc.svc.cluster.local:4000/main/evm/314) from = 5421623 to = 5421672, sgd: 125779, subgraph_id: QmS5CahkaGiNPxQQuN6kroR4Ez9vFgj5nLgkqBqAsrwHyt

Did it got unstuck by any chance? Could the Goldsky be the issue again?

[juliangruber]

I'm following up with Goldsky on this

[juliangruber]

This is being investigated on the Goldsky & FilOz side