Compliance Enforcement

Libertum enforces compliance constraints in code, not just in documentation. This chapter walks through the chain end-to-end.

1. KYC pipeline

Investor clicks "Complete KYC"
     ↓
Frontend → backend → SumSub access token issued (project-scoped, single-use)
     ↓
SumSub iframe loads in browser
     ↓
Investor submits ID + selfie + (jurisdiction docs)
     ↓
SumSub processes (machine + manual review)
     ↓
Webhook → backend → kycStatus = IN_PROGRESS
     ↓
Webhook → backend → kycStatus = APPROVED or REJECTED
     ↓
On APPROVED, the platform registers the investor on the IdentityRegistry contract
(via the relayer, against the offering's identity infrastructure)

Approved KYC unlocks the ability to place primary orders, but does not by itself authorise transactions in any specific offering — wallet whitelisting comes next.

2. Whitelist gating

Even after KYC is APPROVED:

1. Investor connects a wallet.
2. The platform creates a whitelist request linked to {investor identity, wallet address, offering}.
3. Email goes to the issuer’s transfer agent: review needed.
4. TA opens the Transfer Agent portal → Wallet Whitelist → reviews.
5. TA approves or rejects.
6. If approved: the platform calls the offering’s IdentityRegistry to register the wallet. The investor is now eligible to receive tokens for that offering.

3. On-chain transfer validation

When an investor (or an agent on their behalf) calls transfer(to, amount) on an ERC-3643 Token:

1. Is sender frozen? → revert if yes.

2. Does sender have enough non-frozen balance? → check freezePartialTokens.

3. Is receiver in IdentityRegistry? → revert if no.

4. For each compliance module enabled on Modular Compliance:

   • Country Allow: receiver’s country claim in allow-list?

   • Country Restrict: receiver’s country claim NOT in block-list?

   • Supply Limit: total supply + (mint amount, if mint) ≤ cap?

   • Max Balance: receiver’s resulting balance ≤ cap?

   • Hold Time: tokens being moved older than hold-time?

5. All pass → execute transfer; emit Transfer event.

6. Any fail → revert.

This happens before any tokens move. There is no after-the-fact compliance check — the chain itself rejects non-compliant transfers.

4. Force transfer override

forcedTransfer(from, to, amount) skips step 1 (sender frozen) and step 2 (sufficient non-frozen balance) — so an agent can move tokens out of a frozen or partially-frozen wallet in legitimate compliance scenarios. Steps 3 and 4 still apply: receiver must be verified, all compliance modules must still pass. This is the critical safety: a force transfer can never put tokens in a non-compliant wallet.

recoveryAddress(lostWallet, newWallet, identity) is similar but performs the IdentityRegistry update atomically with the transfer — re-linking the new wallet to the same identity in one operation.

5. Audit trail surfaces

Every compliance action produces multiple audit records:

• On-chain event (immutable). Examples: Transfer, AddressFrozen, AddressUnfrozen, TokensFrozen, RecoveryAddress.
• Off-chain database record with actor, timestamp, decision, reason.
• Issuer’s Transfer Journal — UI surface that combines both.
• Investor’s Transaction History — investor-facing slice of the same data.
• SumSub webhook log — every KYC decision archived.

External auditors get a full picture by combining off-chain exports with on-chain event indexing — both views agree because the event indexer writes to the database only when the on-chain event is observed and confirmed.

6. What Libertum does NOT do

• Libertum is a technology provider, not a broker-dealer. Securities-law obligations (registration, exemption analysis, prospectus content, jurisdiction-specific disclaimers) remain with the issuer and their counsel.
• No automated tax advice. The Statements & Tax module produces transaction statements; tax classification and filing remain the investor’s responsibility.
• No custody of investor cash directly outside of payment-rail intermediaries (Stripe, bank transfers to issuer accounts, on-chain stablecoin escrow).