Primcast
中文

Trust & security

Every system asks its users to trust someone. This page lists exactly whom Primcast asks you to trust, what each party can do, and what you can verify for yourself.

Who can do what

PartyCanCannotVisible through
Governance Safe (multisig)Upgrade every application contract and every token at once, with no timelock; upgrade ArbOS and the rollup contracts; appoint and remove issuers and registrars; add and remove sanctions; allowlist settlement tokens; slash and unjail providers; every token-admin power; replace a token's admin; set feesMove USDC or USDT out of wallets it does not control (without an upgrade that grants it)Safe transactions, Upgraded and ownership events, every domain event
Issuer (token admin)Mint to eligible wallets, burn, force-transfer, freeze, pause or mature, change terms (redemption price, maturity, jurisdictions, cap), approve venues, distribute, fund or cancel redemptions, create or cancel offerings, withdraw proceedsChange requireKyc, settlement token, symbol or decimals; bypass sanctions; touch other issuers' tokensToken events (Minted, Burned, ForceTransferred, TokenUpdated, …)
RegistrarWrite any account's KYC, accreditation, jurisdiction and expiry; freeze or unfreeze any accountSanction, mint or move fundsAccountSet, AccountFrozen, AccountUnfrozen
Sequencer operatorOrder transactions; delay or refuse them for up to 24 h; see pending order flowForge transactions or state (validators and Ethereum catch that); stop force-inclusion by non-sanctioned usersPosted batches on Ethereum
Validators (allow-listed at launch)Assert the chain's stateGet a wrong state confirmed while one honest validator challenges itAssertions on Ethereum
Data providersPost readings for their own devices, and values to topicsPost for devices they do not operateReadingSubmitted, ValueSubmitted
Keepers (anyone)Close due offerings, mature tokens, trigger issuer-approved dividendsAnything else; a stuck keeper only delaysTransactions

Upgrades

  • Application contracts are proxies owned by the Safe. RWAToken upgrades go through one beacon and change every token at once.
  • There is no timelock and no mandatory notice period. An upgrade takes effect when the Safe executes it. In principle it can change the rules of any token, including the handling of escrowed offering funds and redemption pools.
  • Process commitment: storage layout is append-only and checked in CI. Each upgrade is rehearsed on testnet before mainnet, and upgrades are announced to issuers and holders in advance. This is operational policy, not something the chain enforces.
  • The rollup itself (ArbOS, core contracts) is upgraded through the same Safe via Arbitrum's UpgradeExecutor.
  • Primcast DEX pairs and router are not upgradeable.

The absence of a timelock is the single most important trust assumption on Primcast. In practice you trust the Safe signers as you would trust the operator of a traditional registry, with the difference that every action they take is public and permanent on-chain.

Emergency controls

SituationControlEffect
Problem with one assetRWAToken.setStatus(Paused)Blocks transfers, mints and redemption requests; dividend claims still work
Problem with a stablecoinSystemRegistry.setSettlementToken(token, false)No new tokens or offerings on it; existing positions keep working
Problem with an offeringOffering.cancelOfferingInvestors can claim full refunds
Bad data providerAssetHub.slashProvider, revokeDeviceBond slashed, jailed after repeated infractions; device permanently revoked
Sanctioned partyIdentityRegistry.addSanctionImmediate on-chain block; sequencer block within about 5 minutes
Chain emergencyStop the sequencerChain halts; funds remain withdrawable through Ethereum after the delay

Third-party venues such as other pools or lending markets are not Primcast's to pause. Pausing the token is what stops trading in it.

What you can verify yourself

  • Rules and balances: every contract is public and verified on the explorer. canReceive, claimableDividends, getRedemption and getOffering answer questions directly from chain state.
  • History: every privileged action emits an event. This portal and any indexer rebuild the audit trail from logs.
  • Deployment: addresses are published on the Network page and in the repository's deployments/<chainId>.json.
  • Chain integrity: batches and assertions are on Ethereum. Anyone can run a full node, and later a validator, to check them.

Engineering controls

  • Unit, fuzz and invariant tests for every contract, plus an end-to-end smoke test that walks the whole issuer path against a live node.
  • A storage-layout check in CI for every upgradeable contract.
  • A separate key for each operational role (deployer, batch poster, validator, compliance filterer); the Safe is the executor of the chain owner; the deployer's rights are revoked after launch.

Audits

No third-party audit report is linked here yet. Audit reports will be listed on this page when they are published. Until then, treat the contracts as unaudited.