Skip to content

pdpv0: document filecoin pay settlement #979

Open
ZenGround0 wants to merge 2 commits intopdpv0from
docs/settlements
Open

pdpv0: document filecoin pay settlement #979
ZenGround0 wants to merge 2 commits intopdpv0from
docs/settlements

Conversation

@ZenGround0
Copy link
Copy Markdown
Collaborator

No description provided.

@github-actions github-actions bot added the team/fs-wg Items being worked on or tracked by the "FS Working Group". See FilOzone/github-mgmt #10 label Feb 12, 2026
@ZenGround0 ZenGround0 changed the base branch from main to pdpv0 February 12, 2026 22:08
Comment thread documentation/en/experimental-features/PDPCURIOSPEC.md Outdated
Comment thread documentation/en/experimental-features/PDPCURIOSPEC.md Outdated
@ZenGround0 ZenGround0 requested a review from rvagg February 25, 2026 20:16
@ZenGround0 ZenGround0 marked this pull request as ready for review February 25, 2026 20:17
@ZenGround0
Copy link
Copy Markdown
Collaborator Author

Im linking to the empty FWSS-terminate section from within settlements. I'll now submit a PR to fill that out.

@BigLep BigLep added this to FOC Mar 10, 2026
@BigLep BigLep moved this to 🐱 Todo in FOC Mar 10, 2026
@BigLep BigLep moved this from 🐱 Todo to ⌨️ In Progress in FOC Mar 10, 2026
@BigLep BigLep moved this from ⌨️ In Progress to 🐱 Todo in FOC Mar 12, 2026
@BigLep BigLep moved this from 🐱 Todo to 🔎 Awaiting review in FOC Mar 19, 2026
@rvagg
Copy link
Copy Markdown
Member

rvagg commented Mar 23, 2026

The settle task is scheduled twice a day through the IAmBored entrypoint

are we still comfortable with that approach given the pain we've had with IAmBored? it doesn't need to be eager but is there a world in which a Curio node never gets bored and never settles?


The settle task is scheduled twice a day through the IAmBored entrypoint. Upon waking up the settle task queries the `eth_keys` table for the first keys it finds with role == `pdp`. The task then queries the provider registry to learn the payee address. `Settle` task then delegates to the `filecoinpayment` library method `SettleLockupPeriod` to attempt to settle all rails in need of settlement that are paying out to the payee address using the FWSS contract as the rail's operator contract.

`SettleLockupPeriod` uses eth call methods on the filecoin-pay contract to lookup all rails operator and payee. The method's purpose is to periodically settle payment rails paying out to the payee address. To achieve this gas and local-resource efficiently the method schedules settlement as lazily as safely possible. It settles rails that have any possibility of client default between this run of the task and the next expected run in 12 hours. To determine this condition each rail's `settledUpTo` and `lockupPeriod` value is inspected. When a rail has not been settled for over one `lockupPeriod` the client can be in default. `SettleLockupPeriod` settles all rails that are within one day of meeting this condition. Additionally all termianted rails in the process of finishing out their last `lockupPeriod` of life are marked for settlement. For more about the details of termination and lockup periods and how this exactly determines default risk see the filecoin-pay [documentation](https://github.com/FilOzone/filecoin-pay/blob/main/README.md#per-rail-lockup-the-guarantee-mechanism).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

settles rails that have any possibility of client default between this run of the task and the next expected run in 12 hours

this is wrong now, since we try and settle when we haven't settled for more than 7 days @ #1089

The logic in SettleLockupPeriod is kind of hard to describe and doesn't fit neatly in here, but here's my go:

On a 12 hour schedule, SettleLockupPeriod looks for rails that it should attempt to settle belonging to the service provider (payee) that are denominated in USDFC. Rails that are candidates for settlement include:

  • Rails that have been terminated, passed their lockup period by no more than 7 days, and is not yet successfully settled
  • Rails that have a lockup period less than one day (special case: settle whenever SettleLockupPeriod is run)
  • Rails that have not been settled since min(lockupPeriod - 1 day, 7 days). In this scheme, we always attempt to settle a rail once every 7 days, and for rails that have a lockup period of less than 7 days we settle them more frequently, but 1 day shorter than their lockup period so as to avoid getting to close to the end of the lockup period.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Also this line also still says "lookup all rails operator and payee", it's more like: "queries all rails by payee and token, then filters to those matching the FWSS operator."

Copy link
Copy Markdown
Member

@rvagg rvagg Mar 23, 2026

Choose a reason for hiding this comment

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

termianted -> terminated (if you're going to keep your original and adjust it)

@rjan90 rjan90 added this to the M4.2: mainnet GA milestone Mar 30, 2026
@BigLep BigLep moved this from 🔎 Awaiting review to ⌨️ In Progress in FOC Apr 7, 2026
@BigLep BigLep moved this from ⌨️ In Progress to 🔎 Awaiting review in FOC Apr 9, 2026
@rjan90
Copy link
Copy Markdown
Collaborator

rjan90 commented Apr 13, 2026

Should we target these changes towards the main branch, now that pdpv0 has been merged into main?

@LexLuthr
Copy link
Copy Markdown
Contributor

The settle task is scheduled twice a day through the IAmBored entrypoint

are we still comfortable with that approach given the pain we've had with IAmBored? it doesn't need to be eager but is there a world in which a Curio node never gets bored and never settles?

Yes, this is very much an issue right now. Upcoming harmony changes should fix this and move towards slightly different architecture. IAmBored was never meant to be this. We got lazy and abused it.

@LexLuthr
Copy link
Copy Markdown
Contributor

Should we target these changes towards the main branch, now that pdpv0 has been merged into main?

I would merge in pdpv0 for now. Plan is to move all docs in one go. Once all docs PR are finished we can easily port over without accidentally leaving any content behind. I will also be restructuring Curio docs after that to get PDP more prominent space within the docs.

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

Labels

team/fs-wg Items being worked on or tracked by the "FS Working Group". See FilOzone/github-mgmt #10

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants