Continuum

Continuum lets a verified participant stake MON and receive stMON, a transferable receipt that earns as it is held. Every movement of that receipt re-checks the counterparty’s identity credential on-chain, against a rule registered with Cleanverse.

Three properties define it:

• Liquid. Staking does not lock. stMON is transferable to any eligible counterparty from the moment it is minted.
• Continuously checked. Eligibility is evaluated at every stake, transfer, and exit, not once at signup.
• Non-confiscatory. A revoked holder stops circulating, but keeps principal and yield, and can exit to a verified destination after review.

Most compliant DeFi checks identity once, at the door. After that, nothing that happens to the credential matters. A certificate lapses, a holder is sanctioned, a credential is revoked outright, and the position keeps trading as though nothing changed.

Where a check does exist, it usually lives in the application: an allowlist in a frontend, or a database consulted by one venue. Move the asset somewhere else and the rule does not travel with it.

Continuum puts the check in the asset. The rule holds anywhere the token goes, because the token is what enforces it.

Four checkpoints, each re-reading the credential:

1. 01 · Verify

   A Cleanverse A-Pass (CVI) binds a verified identity to a wallet. Identity documents go to Cleanverse, never to Continuum.

2. 02 · Stake

   Deposit MON, receive stMON at the current rate. Rewards raise the redemption value rather than minting new units, so balances stay constant while their claim grows.

3. 03 · Move

   Transfers re-check the recipient at the token layer. An ineligible recipient causes the transfer to revert on-chain.

4. 04 · Exit

   Eligible holders unstake freely. Revoked holders take the controlled exit.

1. Get testnet MON. You need MON on Monad testnet (chain 10143) for gas and staking. Use a Monad testnet faucet.

2. Connect your wallet. Open the app and connect. Add Monad testnet to your wallet if prompted.

3. Get a credential. Continuum is permissioned, so an unverified wallet cannot stake. On testnet the Verify panel offers one-click demo access: you sign a free message proving you control the wallet, and a sandbox A-Pass is issued to it. This takes about fifteen seconds and is written on-chain.

4. Stake, move, exit. Stake MON for stMON, transfer it to another eligible wallet, and unstake whenever you like.

Cleanverse is a trust network for on-chain finance. It exists so that verified identities and verified digital value can interact under one common framework anchored by regulated financial institutions, turning an open blockchain from a pool of anonymous wallets into infrastructure that can carry regulated activity.

The framework rests on the same foundation as traditional finance, meaning known counterparties and a verified source of funds. It delivers that through three interlocking assurances.

• Cleanverse Verified Identity (CVI). Every transacting wallet is bound to an individual or legal entity holding a verified financial identity, established through a licensed institution. This is the assurance Continuum depends on.
• Cleanverse Verified Asset (CVA). Every digital asset has entered the network through an approved trust pathway and carries evidenced provenance rather than an unknown history.
• Programmed Governance. Before value moves, eligibility is checked against rules the asset issuer sets over the combination of CVI and CVA. Transfers stay continuously traceable, with auditable records in real time.

These assurances are operationalised by the Cleanverse Compliance Protocol (CCP), the programmable layer that executes trust policies consistently across participating institutions, blockchain networks and applications. A policy can govern participant eligibility, trusted counterparties, asset permissions and transfer restrictions.

The defining idea is ordering. Trust is established before value moves, rather than reconstructed after a transaction has already settled.

Remove Cleanverse and there is no product. The integration is enforcement, not display.

Registered compliance pool.Continuum’s ComplianceRouter is registered with the Cleanverse CVI compliance validator on Monad. Registration is authorised by an EIP-191 signature from the contract owner.

A rule we cannot bend. The pool carries a RuleV2 of min_sub_tier 30. A wallet holding a valid, active A-Pass at sub-tier 10 is refused. The threshold lives on Cleanverse’s contract, so Continuum cannot quietly wave anyone through.

On-chain, on every state change. Gated paths call complianceVerify(pool, user) on the validator. That call is a view function and permissionless, so anyone can independently verify any wallet against our pool.

# Check any wallet against the Continuum pool
cast call 0xaC7e5179C2C7f03f209136886c172eb34F161792 \
  "complianceVerify(address,address)(bool)" \
  0x4c0316B790a6a7E194abd06E69e42fdf8c67c5F6 \
  <WALLET> --rpc-url <MONAD_TESTNET_RPC>

Live credential reads.The Verify panel shows the real A-Pass record, covering tier, sub-tier, group, countries and expiry, read through Cleanverse’s query_apass endpoint, proxied server-side so institutional credentials never reach the browser.

Freezing a revoked wallet is straightforward. The harder question is the one a regulator asks immediately afterwards: so you seize the funds?

Continuum’s answer is no.

1. 01 · Revoked

   The position freezes for circulation on the next transaction. Transfers revert. Nothing is taken.

2. 02 · Under review

   The holder submits a redemption request nominating a verified destination wallet. A compliance officer reviews it.

3. 03 · Settled

   Eligibility is re-checked at approval and again at settlement. The receipt is burned and the underlying asset is delivered to the nominated wallet, principal plus earned yield.

If the nominated destination stops being eligible between approval and settlement, the request is deferred rather than settled to an ineligible wallet. Value is never released to a destination that fails the check at the moment of release.

Four contracts, plus the Cleanverse validator:

         ┌──────────────────────────────┐
         │  Cleanverse CVI validator    │  (Cleanverse)
         │  complianceVerify(pool,user)  │
         └───────────────▲──────────────┘
                         │ view call
         ┌───────────────┴──────────────┐
         │      ComplianceRouter        │  implements ICleanverseIdentity
         │  local registry + validator  │
         └───▲───────────▲───────────▲──┘
             │           │           │
        ┌────┴───┐  ┌────┴─────┐  ┌──┴──────────────┐
        │ StMON  │  │  Vault   │  │ RedemptionQueue │
        └────────┘  └──────────┘  └─────────────────┘

ComplianceRouter implements the same identity interface the protocol contracts already depended on, so StMON, the vault, and the queue bind to it unchanged. It consults two sources and combines them according to a mode:

• LocalOnly, registry only, validator ignored
• ValidatorOnly, Cleanverse is authoritative
• RequireBoth, both must pass (current setting)
• EitherPasses, either suffices

The validator call is wrapped, because complianceVerify reverts for a pool that is not registered. An unreachable validator therefore degrades by mode rather than bricking every gated path: fail-closed for the strict modes, ignored for the permissive ones.

Revocation deliberately stays local. The validator answers pass or fail only, and it has no notion of a known-but-revoked holder. That distinction is exactly what makes a controlled exit possible rather than indistinguishable from a stranger being refused.

Monad testnet, chain 10143. All verifiable on-chain.

What enforces what:

• Eligibility is enforced in the contracts. The interface cannot grant access the chain would refuse, and refusing in the UI would not stop a direct contract call, so the check lives where it cannot be bypassed.
• The Cleanverse rule is stored on Cleanverse’s validator. Continuum cannot edit it from its own contracts.
• Compliance calls fail closed. If the validator cannot answer, strict modes refuse rather than permit.

Privileged roles:

• Owner. Can set the router mode, pause the vault, revoke credentials in the local registry, and act as compliance officer on redemption requests.
• Operator. A deliberately narrow role used by the demo-access endpoint. It can admit a wallet to the local registry and nothing else: it cannot revoke, cannot change the compliance mode, and cannot touch the vault.

Demo access is constrained: it requires a wallet signature proving control of the address, is rate limited per address and per requester, is capped in total issuance, and can be switched off entirely by configuration.

The app exposes read endpoints you can call directly. Institutional credentials stay server-side and are never returned.

GET /api/cleanverse/apass?address=0x...

{
  "address":    "0x...",
  "chain":      "monad",
  "registered": true,
  "verified":   true,
  "frozen":     false,
  "expired":    false,
  "tier":       50,
  "subTier":    60,
  "group":      null,
  "subGroup":   "AB",
  "countries":  [],
  "expiresAt":  "2027-08-06",
  "note":       "A-Pass is active."
}

Prefer to trust the chain over our server? Call the validator directly. See Cleanverse integration. Everything the interface asserts is independently checkable.

Continuum works end to end on Monad testnet. It is not production software, and the reasons are worth stating plainly.

1. Sandbox credentials are not real KYC. Cleanverse relaxed its KYC requirement for the hackathon, which is the only reason one-click demo access can work. In production, an A-Pass is an institutional attestation: a licensed member asserts it verified the person and cites the provider and reference. Issuing one for an anonymous wallet would be a false attestation, precisely what the credential exists to prevent. The real path is Cleanverse KYC registration, or becoming a Gateway Member with genuine KYC references.

2. Rewards are simulated. Testnet yield is a deterministic drip that raises redemption value. There is no validator delegation behind it.

3. The local registry is scaffolding.It exists so revocation can be demonstrated on command, and because it expresses a known-but-revoked state the validator’s pass/fail answer cannot. A production deployment would make Cleanverse the sole authority.

4. Roles are not yet separated. On testnet, one party holds both the holder and compliance-officer keys. In production these are necessarily different parties.

5. stMON is a receipt, not a CVA.Cleanverse’s A-Token issuance is an approval-gated flow we did not complete. The CCP guide’s contract-template route is the documented upgrade path.