Open live demo

Enterprise, Compliance & RWA — Privacy Lane (OpenZeppelin & Nethermind)

Guardian PrivateReceivable

Who is allowed to hold this receivable?

Guardian PrivateReceivable tokenizes a fictional enterprise receivable as a permissioned RWA token on Stellar Testnet. Identity and compliance contracts decide who may receive, hold, or transfer it — compliance officers verify wallets, freeze accounts, pause the asset, and settle the receivable on demand.

Open live demoOpen repositoryGuardian Labs

What is TOTVS?

TOTVS is Brazil's largest business-software company. Its flagship ERP, Protheus, is where a large share of Brazilian companies register and manage accounts receivable: the invoices and duplicatas that this proof of concept represents on-chain. In the latest FGV-Eaesp IT survey, TOTVS holds about 34% of Brazil's overall ERP market (tied with SAP) and about 50% among smaller deployments (up to roughly 180 users), so a receivable modelled on Protheus data reflects how these assets are actually recorded in Brazil.

Source: FGV-Eaesp Annual IT Use Survey (Brazil ERP market share).

The problem

Companies hold receivables that can be financed, assigned, or represented digitally. Enterprise and regulated environments need control over who may receive, hold, or transfer the associated economic rights — a standard public token allows unrestricted transfers and can expose information that should stay private.

Hackathon proof of concept — not a regulated securities platform, a real investment product, a KYC/AML provider, or a system approved for Mainnet.

How compliance is enforced

Every mint and transfer of the token is routed through the same enforcement chain before it settles on-chain.

  1. Rejected while the token is paused.
  2. Rejected if either wallet is frozen — frozen wallets can neither send nor receive.
  3. Checked against the identity-verifier contract — the operation fails unless the wallet is Verified.
  4. Checked against the compliance-policy contract (can_transfer / can_create) for both sender and recipient.
  5. Rejected once the receivable status is Settled.

Demonstration flow

Four minutes, end to end, through the web UI.

  1. Compliance officer verifies Investor A; Investor B stays unverified.
  2. Issuer mints to Investor A — confirmed Testnet transaction.
  3. Mint/transfer to Investor B is rejected: recipient not verified.
  4. Investor B is verified; transfer A → B succeeds.
  5. Freeze Investor B — transfer rejected: wallet frozen — then unfreeze.
  6. Pause the token — transfer rejected: token paused — then unpause.
  7. Settle the receivable — further mint/transfer rejected: receivable settled.

Live on Stellar Testnet

Contracts already deployed for the demo.

NetworkStellar Testnet
TokenPrivate Receivable Participation (PRCV, 7 decimals)
ReceivableRCV-2026-0001

Contract IDs

identity-verifierCCJ52CC6HZJEEL67XLRKSHY4YMFPHV57HWONI2CXLLWIRXNI722ZKASX
compliance-policyCCPUMFWSLIW5XPO7OOIDXXQBYBAGA7FEAN6C657MFNIPRYZ2FCDAKWFV
receivable-rwaCATSFC2TS3ZTWEIHRNH6R3UHVYHQTA4RHFSZ36E2464N5N7MAPWFUWD5

Identity & receivable states

  • VerifiedWallet passed compliance verification and may receive/transfer the token.
  • UnverifiedWallet has not been verified — mint and transfer are rejected.
  • RevokedWallet was verified, then revoked — mint and transfer are rejected.
  • ActiveReceivable is open — mint and transfer are allowed when compliant.
  • SettledReceivable lifecycle is closed — mint and transfer are rejected permanently.