Takedown compliance

​

What the on-chain blacklist means for you

The ContentBlacklist contract is the authoritative takedown mechanism. Entries come from:

• Governance — 24 h compliance window before serving becomes slashable
• Regional governance bodies — region-scoped, 24 h window
• Emergency multisig — immediate effect, 2 h slash grace, 14-day auto-expiry (90 days for CSAM/terrorist categories)

See takedown for the full mechanism. This page is the operator-facing summary.

​

Your compliance responsibilities

As an origin operator:

1. Your origin-backed nodes must poll the blacklist contract. The node process does this automatically on the blacklist sync interval. Monitor decdn_blacklist_sync_lag_seconds — if your node falls behind, you risk serving a blacklisted hash after the compliance window.
2. Stop serving blacklisted hashes within the compliance window. The node process enforces this automatically, but operator-level controls apply too — remove the hash from your backend catalog and delete the ciphertext if appropriate.
3. Maintain a local denylist for direct legal notices. Entries you add yourself (e.g., a DMCA notice served directly to your corporate entity) do not propagate to other nodes.

​

Local denylist

Every node can maintain a local denylist. Entries:

• Do not propagate — only your nodes honor them.
• Do not trigger slashes — for other nodes, the hash is still servable.
• Take effect immediately — no compliance window.

Use this for direct legal notices, in-house compliance rules, or content your provider legal team has decided to pull for non-public reasons. To get the hash out of circulation across the network, you need an on-chain entry. The local denylist only protects you and your nodes.

​

Origin blacklisting

Re-uploading blacklisted content under a fresh hash (via trivial re-encoding) is defeated by origin blacklisting — the on-chain blacklist can also target an operator address. If your operator address is origin-blacklisted:

• Re-uploading requires a new operator identity (fresh stake, new address).
• Your original stake is slashable for any continued violations while origin-blacklisted.

This raises the cost of hash evasion meaningfully — it’s no longer “re-encode and retry,” it’s “new corp, new stake, new identity.”

​

Regional entries

A regional entry (region: DE) applies only to nodes that advertise a matching region in NodeAnnounce. Your origin-backed node in Frankfurt advertising region: DE is bound by DE-regional entries. Your Los Angeles node is not. The gray area — a region: DE node serving a DE-regional entry to a US client — is not fully resolved in the ADR. Your compliance posture should assume the strictest jurisdiction your node’s region subjects you to.

​

Slashing schedule

Blacklist violations use an escalating schedule: 10% / 25% / 50% for first / second / third offense within 90 days (tokenomics). A single inattentive hour of lag on blacklist sync can easily cost 10% of your stake per offending blob served. Treat blacklist sync lag as a P1 monitoring concern.

​

The compliance-window mechanics

• Entry added at time T (on-chain).
• Compliance window ends at T + 24 h.
• Between T and T + 24 h, serving the hash is allowed (absorbs propagation delay).
• After T + 24 h, serving the hash is slashable via submitBlacklistChallenge.

For emergency entries, the 2 h slash grace replaces the 24 h window. Your node must sync the blacklist at least every ~30 minutes to stay safely inside this window.

​

Practical checklist

• Alert on decdn_blacklist_sync_lag_seconds exceeding 30 minutes.
• Alert on decdn_blacklist_version_behind exceeding 1.
• Document an internal process for receiving direct legal notices and adding them to the local denylist.
• Maintain operational ownership of your ingest pipeline so takedown translates to actual content removal from origin, not just a CDN-level block.
• Understand your regional scope (what country codes your nodes advertise).