Security & Infrastructure
Security & Infrastructure
Smart contracts
What smart-contract standard does Libertum use?
On EVM (Base Mainnet), the default is ERC-3643 (T-REX) — the Token for Regulated EXchanges standard, originally developed by Tokeny SA. ERC-3643 embeds compliance directly into transfer logic: every transfer checks the sender’s frozen status, the receiver’s identity, and a chain of compliance modules before any tokens move.
Libertum also supports ERC-20 (utility / governance tokens), ERC-721 (one-of-a-kind tokenization), CIP-20 (Cardano native fungible tokens) and CIP-113 (Cardano programmable security tokens, on Preview pending audit).
Have the smart contracts been audited?
The core ERC-3643 (T-REX) suite is based on the audited Tokeny T-REX implementation. Libertum’s deployments and any Libertum-specific extensions (EscrowController, MarketplaceController, Bonding Factory) follow standard industry practice for review and deployment. The Cardano CIP-113 stack is currently undergoing a third-party security audit before mainnet GA.
What contracts does Libertum deploy per offering?
Each ERC-3643 offering deploys a full suite of contracts via the TREXFactory:
- Token — ERC-20-compatible with overridden transfer for compliance
- Identity Registry — wallet → identity mapping
- Identity Registry Storage — shared identity data layer
- Trusted Issuers Registry — approved claim issuers (KYC providers)
- Claim Topics Registry — valid claim types
- Modular Compliance — chains together enabled compliance modules
Plus the per-offering selected compliance modules: Country Allow / Restrict, Supply Limit, Max Balance, Hold Time. All wrapped in UUPS proxies for upgradeability. Deterministic CREATE2 addresses.
What are the public mainnet contract addresses?
Published on the Token Standards & Smart Contracts page. All addresses are public on chain — anyone can verify them on Basescan.
Who controls the contracts after deployment?
Two privilege levels:
- Token Owner — the issuer (typically a hardware wallet or multi-sig). Can change compliance config, change identity registry, transfer ownership.
- Agents — operational wallets that handle mint, freeze, force-transfer, recover. By default the platform’s relayer is an agent for routine operations; the issuer can add or remove agents at any time.
Custody
Where are investor funds held during a subscription?
In the EscrowController smart contract on Base Mainnet (0x8f8aDaD75a3795A952979D85b500baF2364BBC54). Investors approve USDC / USDT to the escrow and call subscribe; funds are held until the offering settles, at which point they’re released to the issuer’s wallet (and tokens are minted / transferred to the investor) or refunded.
Where are tokens held in on-deploy minting?
In a per-issuer custodian wallet managed by Libertum on the issuer’s behalf. The full token supply is minted to the custodian at deployment; tokens transfer out to investors as their orders settle. Custodian-wallet operations are gated by withdrawal limits and auditable per-action.
Can Libertum move my tokens or funds without my consent?
Only in two narrowly-scoped scenarios, both with full audit trail:
- Routine operations the issuer has delegated to the platform’s relayer — minting at order settlement, dividend distribution. These are explicit issuer-authorised flows.
- Compliance interventions — force-transfer, freeze/unfreeze, recovery — performed by an authorised agent under issuer policy, with on-chain events and off-chain audit-log entries for every action.
Libertum has no ability to drain custodian wallets or escrow contracts arbitrarily; every privileged action is bounded by the smart-contract rules and the issuer’s agent assignment.
Authentication & access control
What’s the auth model?
JWT-based with refresh-token rotation. 2FA (TOTP, email or SMS) gates sensitive operations. Idle timeout of 30 minutes on the marketplace, 60 minutes on the admin portal.
What roles exist?
| Role | Access |
|---|---|
| Investor / Institution | Investor surfaces |
| IssuedAdmin (Issuer) | Investor + issuer surfaces |
| Admin | Admin portal full access |
| SubAdmin | Admin portal subset filtered by RBAC permissions |
| TransferAgent | TA portal — cap table, whitelist, force transfers |
What’s the platform admin’s RBAC model?
Sub-admins are configured with a per-module read/write permission matrix. Each sub-admin’s userPermissions array lists, for every module (Users, Offerings, Fee Settings, etc.), whether they have read and/or write access. The admin sidebar filters dynamically by permission.
Observability & reliability
What monitoring does Libertum run?
- Sentry — error tracking per service
- Application logs — captured centrally
- On-chain monitoring — the event indexer is itself a monitoring point; if events stop being indexed, alerting fires
- Vendor dashboards — Stripe, SumSub, DocuSign, Twilio, SendGrid each provide their own observability
Where is Libertum hosted?
Frontends are statically built and served via Cloudflare’s global CDN. Backends are containerised and deployed on managed cloud infrastructure with horizontal scale where warranted. Database is managed (with automated backup); Redis with TLS. Secrets are stored in a managed secret store, never in environment files.
What’s the disaster recovery posture?
Severity classification: SEV-1 (critical: funds at risk / platform offline / key compromised) → SEV-4 (informational). Key recovery scenarios documented and rehearsed:
- Deployer key compromise — transfer ownership to a new secure wallet (multi-sig recommended)
- Database loss — restore from snapshot to last clean checkpoint; replay Kafka events forward to rebuild
- Blockchain RPC outage — automatic failover via the 9-RPC fallback chain
- Stripe outage — card payments queue; fallback to wire / on-chain stablecoin still available
- SumSub outage — new KYC submissions queue; existing approved investors continue uninterrupted
See Roadmap & Support for the public-facing summary.
What if there’s a security incident?
Email [email protected] for responsible disclosure. We follow industry-standard incident response with severity classification, communication plans (internal Slack, status page, email to affected users, regulator notification where required), and post-mortem reviews.