Primcast
中文

Compliance

Primcast enforces regulatory constraints at independent layers. A restricted party therefore cannot transact however the transaction enters the system, and each asset can apply its own investor rules on top.

Three layers

LayerWhereWhat it stops
1. Sequencer admissionThe Nitro sequencer (ArbOS 61 transaction filtering)Any transaction whose sender, target or any touched address is on the restricted list, and ERC-20/1155 Transfer/Approval events involving a restricted address. The transaction never enters a block.
2. Delayed-inbox enforcementA sentinel watching the Ethereum inbox, plus ArbOS' filtered-transaction managerForce-included transactions involving a sanctioned address. They fail on inclusion and their gas is burned.
3. Application gatesIdentityRegistry facts plus each RWAToken's rulesTransfers, mints, subscriptions, dividend claims and redemptions by ineligible, frozen or sanctioned parties

Where the restricted list comes from

  1. Governance adds a sanction on-chain with IdentityRegistry.addSanction(address, listSource, reason). On-chain gates apply immediately.
  2. The compliance publisher reads the on-chain list, plus an optional static export such as OFAC SDN, every 5 minutes. It writes a list of salted SHA-256 hashes with a fresh salt each time.
  3. The sequencer reloads the list on its next poll.

The on-chain registry is the source of truth. The sequencer list lags it by up to about 5 minutes.

Facts versus rules

IdentityRegistry holds facts about a wallet: KYC status and expiry, accreditation, jurisdiction, registry freeze and sanctions. The rules live on each token: requireKyc, requireAccredited and allowedJurisdictions. Two tokens on the same chain can therefore sell into different markets with the same KYC.

How a token checks a transfer

token status (paused/matured?) → per-token freeze (both parties)
→ for each party, one complianceOf() call:
     sanctioned? → registry-frozen? → is it a venue? (stop here for this party)
     → requireKyc and KYC not valid?
     → receiver only: requireAccredited and not accredited? → jurisdiction not allowed?
→ per-holder cap (venues, system contracts and the token's escrow are exempt)
  • Receiver-only accreditation and jurisdiction. An investor who loses accreditation or moves to a jurisdiction the asset does not allow can still sell: transfer out, including into a DEX pool. Anything the token pays to them applies the receiver rules: new units, dividend claims and redemption payouts. Those wait until eligibility is restored.
  • KYC expiry counts: an expired KYC fails the check exactly like no KYC, for senders and receivers alike. On a KYC-gated token, a holder whose KYC lapsed cannot move units until it is renewed.
  • Errors are specific: Sanctioned, AccountFrozen, KYCRequired, AccreditedRequired, JurisdictionDenied, LimitExceeded.
  • canReceive(to, amount) is the non-reverting version, used by front ends. This portal calls it before letting you subscribe.

Venues (third-party protocols)

A DEX pool or lending market has no identity. The token admin marks such a contract with setVenue(pool, true):

  • The venue itself skips KYC, accreditation, jurisdiction and the holder cap.
  • Every counterparty is still checked. A swap or borrow that would send units to an ineligible wallet reverts exactly like a direct transfer, so a venue passes the rules through rather than opening a hole.
  • Sanctions, registry freeze and per-token freeze still apply to the venue address.
  • By default, venue balances are excluded from dividends, so revenue goes to real holders. A venue that can pass dividends on is opted in with setVenueDividends(pool, true). The Primcast DEX pairs are, and they fold dividends into the pool for liquidity providers.
  • After maturity, units can still leave a venue towards eligible holders, so liquidity providers and borrowers can recover and redeem them. Every other transfer stops.
  • Only contracts can be venues. An unmarked pool needs whatever eligibility the asset requires, and dividends it accrues are stranded.

The Primcast DEX also gates its LP tokens: only wallets the RWA would accept can hold liquidity in an RWA pair.

Forced actions

ActionWhoEvent
Forced transfer between holdersToken admin (issuer) or governanceForceTransferred
Burn (clawback)Token admin or governanceBurned
Per-token freezeToken admin or governanceFrozenSet
Pause / resume a tokenToken admin or governanceTokenStatusSet
Registry-wide freeze of an accountAny registrarAccountFrozen
Sanction an addressGovernanceSanctionAdded

Every privileged action emits an event. The audit trail is the event log, and anyone can rebuild it.

The settlement leg

USDC and USDT are not issued by Primcast. Primcast cannot freeze or seize stablecoin balances; only Circle or Tether can. What Primcast does enforce on the settlement leg is the identity gate at every entry point (Offering.subscribe, distributeDividend, claimDividends, redemptions) and the exclusion of sanctioned parties from payouts. Every payout is pulled by its recipient. If the stablecoin issuer blacklists one holder, only that holder's claim fails.

Known limitations

  • ETH deposits from a restricted address on Ethereum cannot be dropped without stranding ETH in the bridge. The sentinel reports them, and the address still cannot transact on Primcast.
  • Sequencer filtering lags the on-chain list by up to about 5 minutes; on-chain gates are immediate.
  • Sanctions are public. The sequencer list is hashed, but IdentityRegistry sanctions and their history are readable on-chain by design.
  • Subscriptions check only sanctions and KYC. Accreditation, jurisdiction and holder cap are checked when units are minted at claim time. See Offerings.