Guardian Labs · Enterprise, Compliance & RWA

Proof of concept on Stellar Testnet

Guardian PrivateReceivable

Who is allowed to hold this receivable? An enterprise receivable tokenized as a permissioned RWA token on Stellar Testnet — identity and compliance contracts decide who may receive, hold or transfer it.

Permissioned RWA Soroban Identity & compliance Stellar Testnet

The problem

Companies hold receivables — invoices, duplicatas, contracted payments — that can be financed, assigned or represented digitally. In enterprise and regulated environments, though, they need control over who may receive, hold or transfer the associated economic rights.

A standard public token does not solve this: it allows unrestricted transfers and can expose information that should stay private. What is missing is the layer that decides, before the operation settles, whether that wallet is allowed.

Tokenizing the receivable is not enough. The rule about who may hold it has to live in the asset itself.

Unrestricted transfer

A standard public token goes to any wallet, verified or not.

Unwanted exposure

Economic information that should stay restricted ends up public.

Lifecycle with no lock

Once settled, the receivable stays transferable unless something stops it.

Compliance off-chain

A rule in a spreadsheet or an external system does not block the on-chain transaction.

The solution: Guardian PrivateReceivable

Guardian PrivateReceivable tokenizes an enterprise receivable as a permissioned RWA token on Stellar Testnet. Identity and compliance policy contracts decide who may receive, hold or transfer it — and the compliance officer verifies wallets, freezes accounts, pauses the asset and settles the receivable on demand.

The rule is not a recommendation: every mint and every transfer is routed through the same enforcement chain before it settles on-chain. If any condition fails, the operation is rejected.

Permission lives in the contracts. If the wallet is not eligible, the transfer does not happen.

Why it is different

Only a verified wallet operates

The identity-verifier contract must mark the wallet as Verified.

Compliance policy in the asset

The compliance-policy contract evaluates can_transfer and can_create for both parties.

Freeze and pause

A frozen wallet can neither send nor receive; a paused token blocks every operation.

Settlement closes the cycle

A receivable in Settled status rejects any mint or transfer from then on.

How compliance is enforced

Every mint and transfer of the token runs 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.
  MINT / TRANSFER
        |
        v
  [ token paused?       ] -- yes --> REJECT
        |  no
  [ wallet frozen?      ] -- yes --> REJECT
        |  no
  [ identity-verifier   ] -- not Verified --> REJECT
        |  Verified
  [ compliance-policy   ] -- not allowed --> REJECT
        |  allowed
  [ receivable Settled? ] -- yes --> REJECT
        |  no
        v
     SETTLES ON-CHAIN (Stellar Testnet)

Demonstration flow

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

1

Verify

The compliance officer verifies Investor A; Investor B stays unverified.

2

Mint

The issuer mints to Investor A — confirmed Testnet transaction.

3

Reject

Mint or transfer to Investor B is rejected: recipient not verified.

4

Allow

Investor B is verified; transfer A → B succeeds.

5

Freeze

Freeze Investor B — transfer rejected, wallet frozen — then unfreeze.

6

Pause

Pause the token — transfer rejected, token paused — then unpause.

7

Settle

Settle the receivable — further mint and transfer are rejected for good.

Identity & receivable states

VerifiedWallet passed compliance verification and may receive or 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.

Environment facts

Network

Stellar Testnet

Token

PRCV · 7 decimals

Receivable

RCV-2026-0001

Specifications

specs/

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

Tokenize the receivable. Keep permission in the asset.

Watch the enforcement chain run: verify, mint, reject, freeze, pause and settle.