🔎

Sanction screening of FilCDN clients

Context

To comply with regulations, FilCDN must implement a process ensuring that:

  1. FilCDN (Space Meridian) does not pay sanctioned addresses.
    ✅ This is already implemented.
    Due to the 3 payment rails design, we are never paying anyone (only the client)
  • FilCDN (Space Meridian) does not get paid by sanctioned addresses.
    ❌ This is missing.
    Anyone can make an FWSS deal with FilCDN. While FilCDN will not perform the retrieval service, it will still be paid by a (possibly sanctioned) client.

While the same rules apply to SPs, we agreed that solving sanction screening on the SP side is not a priority right now (see this Slack thread).

The scope of this proposal is a design that ensures that FilCDN will not get paid by sanctioned addresses.

Constraints

  1. There are no on-chain sanction screening oracles available for Filecoin (FEVM).
  1. FilCDN cannot launch on the mainnet without sanction screening in place.

Proposed design

  • FilCDN will periodically call the Chainalysis HTTP API to screen addresses of FilCDN clients.
  • When a client is flagged as sanctioned, FilCDN will terminate all CDN services paid by this client.
  • When a CDN service is terminated for a Filecoin WarmStorage Service deal identified by DataSetId:
    • The storage (PDP) service continues. The PDP payment rail stays open.
    • The cache-miss and CDN payment rails are terminated.
    • The withCDN flag (or metadata entry) is cleared.
  • Only FilCDN is permitted to terminate the CDN service using this new mechanism.
    We can adjust this rule in the future, but such a change requires more research.

Implementation tasks

  • Modify the WarmStorageService contract to add a method allowing FilCDN to terminate only the CDN part of a service deal.
  • On the FilCDN side, implement periodic scanning of clients and trigger cancellation of CDN services.

Alternatives considered

  1. Instead of terminating the payment rails, FilCDN will never settle payment rails with sanctioned clients.

    This raises the concern that if the rail is not terminated, there is some money locked in the rail for past epochs, and FilCDN holds the keys to this money. Therefore, one can argue that FilCDN is already in control of those funds.

  1. Work with a provider like Chainalysis to deploy their sanction screening oracle to FEVM.

    Unfortunately, this would require weeks to months to realise, which is too late for M2.5 (the mainnet launch).

    This would require finding someone with contacts there, reaching out, sync, potentially figure out contract details, etc. Expected time estimate for getting this landed is long.
  1. We implement some kind of “cross-chain bridge solution” to query the Ethereum Chainalysis Oracle from Filecoin.
    This adds complexity and cost. Also longer “wait times” for users and builders as far as I understand, as one would have to bridge over every time to check if it was a sanctioned address.
  • Implement some kind of manual sanctions list that can be updated by a trusted operator or managed locally.
    Would be a bit hacky, but the quickest to unblock M2.5. Not sure how waterproof from an lawyer perspective a manual local list would be.

References