Skip to main content

Retroactive Flagging

Traditional compliance systems operate on a pass/fail basis at the time of a transaction. Bermuda goes further with retroactive flagging: a deposit that was accepted earlier can still be constrained later if the depositor address is subsequently flagged.

How It Works

When a previously accepted depositor address is later flagged, Bermuda updates how the associated shielded lineage is treated:

  1. Depositor addresses are re-screened — The compliance engine periodically checks previously accepted depositors again against the active policy.
  2. Flagged addresses are mapped to deposit_id values — Because deposit-time metadata records which depositor address was associated with each deposit_id, the system can identify which deposit_id lineage must be added to blacklist state and later constrained at withdrawal.
  3. Blacklist state is updated — The compliance engine rebuilds or extends the blacklist state and publishes the updated blacklist root used by withdrawal proofs.
  4. Withdrawal paths change accordingly — Funds associated with that blacklisted lineage can lose the private withdrawal path and be forced onto the public path instead.

Evolving Threats

This is what makes Bermuda retroactively compliant: a deposit can be authorized at entry, yet handled differently at withdrawal if the depositor is flagged later.

That matters because an address that appears acceptable at deposit time may later be flagged through:

  • Updated sanctions lists (OFAC, EU, UN)
  • Law enforcement investigations
  • New on-chain forensic analysis
  • Cross-chain intelligence sharing
  • Other changes in policy inputs

Bermuda can respond to those later decisions without turning the entire shielded pool into a public surveillance system.

Key Properties

  • Targeted — Only the deposit_id lineage associated with the later-flagged depositor is affected.
  • Privacy-preserving — Unrelated users do not lose privacy or reveal their activity.
  • On-chain enforceable — The updated blacklist root becomes part of the withdrawal-time rule set.
  • Auditable — Flagged transactions create a compliance trail for regulators and auditors.
  • Configurable — Integrators define which intelligence feeds and update frequencies to use.