feature request: user rebate when service/provider fails the SLA (escrow & slashing)

[jennijuju]

In many real-world use cases, clients want to go beyond simply paying for fulfilled services — they also expect compensation or rebates when service quality is degraded or when SLAs are not met, despite an agreed deal.

To support this, we should explore whether the FWS payment system can be extended in the future to include:

• Optional escrow deposits from the service provider (or creator) as part of the payment rail setup

• Automated slashing of the provider's escrow/or upon rail settlement if the service fails to meet its SLA

• Configurable rebate logic for slashed funds — e.g.:

  • A portion is refunded to the client
  • Some is retained by the creator
  • Some may be burned

This allows more robust, trust-minimized outcomes for service users while incentivizing high-quality performance from providers.

👉 Note: This is not something we intend to build immediately, but we’d love to gather more use cases and signals from teams or applications that would benefit from this type of feature. Please comment or share your thoughts!

[Chaitu-Tatipamula]

i would like to work on this issue!, is this open to work now?

[jennijuju]

i would like to work on this issue!, is this open to work now?

i think we need more user/product feedback before working on this. There are some other contract work we’d need for the upcoming hackathon - will reach out on slack to coordinate.

[rjan90]

This is a P1 task to define the payment use cases in the M2: Pandora Alpha on Mainnet milestone, and ensure they're supported ahead of the audit. However we do not need to implement it in the M2-milestone.

[aarshkshah1992]

Note that the Payment contract does not natively support escrow and slashing. If we want to do this natively in the Payments contract so that the UX/DX is seamless for users and service contract builders, this will need a fair amount of design and implementation work and I would suggest we do that ONLY if there's a strong user ask.

Having said that, this can be done today with some heavy lifting by the service contract using the idea of a "reverse payment rail". Here's a design sketch but the details will heavily vary based on the UX/feature set the service contract wants to implement for escrow & slashing.

---

1. When a new proofset is created/"deal is made", the Service contract creates a Payment rail with the SP as the payer and client as the payee (if the slashed amount needs to be burnt, then the payee will be the "burn address"). The Service contract locks a specific amount in this rail using the modifyRailLockup (if the locked escrow amount should be a flat amount) OR modifyRailRate (if the escrow is rolling rate based). Proofset creation/root addition etc only succeeds if this rail lockup/rate is changed successfully i.e. SP has the funds deposited already in the Payments contract for this lockup.

2. The Arbitrer/Validator on the above rail will be the service contract itself (or it can configure another validator contract that will make decisions wrt slashing)

3. When the Service contract notices a fault from the SP (for eg: in PDP, this would be when SP does NOT submit a PDP proof on time) -> it can slash the SP using one of two mechanisms:
   a) Use modifyRailPayment to draw a one time payment from the fixed lockup that was configured during proofset creation in step 1 (if the design is for a "fixed escrow amount").
   b) Service contract increase the rate of the reverse rail everytime a new root is added to the proofset using modifyRailPayment (this approach scales the escrow amount the SP has to lock in proportion to the data stored). So the service contract for now can simply update the validator/arbitrer state to record this fault/faulted epochs. Later, anybody can call settleRail for this reverse rail on the Payments contract. This call will consult the validator contract which will pay out the payee of the reverse rail for all the faulted/slashed epochs (remaining will be refunded to the SP for the elapsed epochs).

4. If at any point, the SP does not have enough funds to increase the rate/lockup of the reverse rail, the Service contract can mark the SP as delinquent and revert their add roots/txns etc till they deposit more funds in the Payments contract.

---

This approach has rough edges around the UX/DX. The SP needs to ensure they have enough funds in the Payments contract for their escrow lockup, the escrow can only be per rail not per service, service contract needs to handle failure cases such as an SP being in debt and not having enough funds to put up more collateral for a proofset, termination of reverse rails etc.

But the above can definitely be implemented with a careful design. All the payments tooling we're gonna build can be used to introspect reverse rails as well.