Receivables on Rayls

Receivables financing lets a business unlock working capital tied up in unpaid invoices. A bank or fintech advances most of the invoice value upfront, the customer pays the invoice on its normal terms, and the financier collects the difference as fees. The category covers commercial, consumer credit and government receivables, and it is one of the largest financing markets in the world.

This page covers how receivables work on Rayls, in two parts. The first part is for evaluators assessing receivables as a Rayls use case. The second part is for engineers implementing it on a Privacy Node.

Part 1 - Receivables on Rayls, the use case

What changes when receivables move on-chain

Receivables financing already works. Banks and fintechs have run the workflow for decades. Moving it onto Rayls does not improve the workflow itself; it changes what the underlying asset can do.

A receivable on a Privacy Node is a programmable token, governed by smart contracts the institution has written, settled with the same finality as any other transaction on the chain. That unlocks four things that paper or database receivables cannot do.

• Programmable maturity and execution. The token enforces its own settlement rules. A receivable maturing in 60 days settles automatically against payment when the date arrives, with no reconciliation step.
• Atomic settlement against payment. A token-versus-token exchange between buyer and seller settles in a single transaction, eliminating the gap risk that makes today's receivables sales operationally heavy.
• Fractional ownership. A receivable can be split, pooled with others, and distributed across multiple holders. This is what makes securitisation possible on the same infrastructure that issued the underlying asset.
• Composability. A receivable on a Privacy Node can be used as collateral for a credit facility, posted in a vault, or referenced by another smart contract, without leaving the privacy boundary.

Where receivables sit in a Rayls institution's portfolio

Receivables are the entry use case for several adjacent activities Rayls is designed to support:

• Securitisation. Bundling tokenised receivables and issuing the bundle as an asset-backed security.
• Collateralisation. Posting tokenised receivables as collateral against credit lines.
• Lending and yield generation. Building interest-earning structures on top of held receivables.

Each of these reuses the same Privacy Node, the same Enygma privacy layer and the same Public Chain access path. An institution that operationalises receivables on Rayls has the foundation in place for the rest.

What stays the same

A few things that remain the institution's responsibility, exactly as today.

• Source of truth for the underlying invoice. The Privacy Node does not replace the institution's existing systems. Core banking, ERP and invoicing remain the source of truth, and the Privacy Node integrates with them via API.
• Credit decisioning. Risk assessment, KYC and underwriting happen in the institution's existing systems before a token is minted. Rayls does not interfere with that process.
• Compliance posture. Privacy on Rayls is auditable through the Enygma view-key mechanism, which means receivables activity is visible to authorised auditors without being public to the network. The institution's regulatory obligations apply on Rayls as they do anywhere else.

Part 2 — Implementing receivables on a Privacy Node

This section assumes a Privacy Node is already installed and reachable.

A note before starting

Rayls does not ship a reference smart contract for receivables. The institution writes its own contract, using the standard ERC interfaces below. Rayls provides the Privacy Node, the Enygma privacy layer, and the protocols for cross-node movement. The contract that defines what your receivable is, how it matures, who can hold it, and what happens at settlement is yours to write.

This is deliberate. A receivable is not generic, and the contract logic an institution needs is shaped by the products it offers and the regulatory regime it operates under.

Step 1: Mint the receivable

Receivables are minted on the Privacy Node as ERC tokens. Three standards are supported.

• ERC-20 for fungible receivables, where each token unit is interchangeable. Suitable for pooled or aggregated receivables structures.
• ERC-721 for unique receivables, where each token represents a single specific invoice. Suitable when each receivable has distinct terms or a distinct counterparty.
• ERC-1155 for hybrid cases, where a single contract manages both fungible and non-fungible receivables.

Off-chain receivables data (invoice number, amount, debtor, due date, terms) is read from the institution's existing systems via API integration with the Privacy Node. The institution signs the minting transaction, which is what attests on-chain that the token represents a real off-chain receivable.

See [Minting tokens on a Privacy Node].

Step 2: Define the contract logic

A minted token without contract logic is just a balance. To make it a receivable, the institution deploys a smart contract that enforces:

• Maturity terms. When the receivable settles, against what payment, on what conditions.
• Counterparty rules. Who can hold the token, who can transfer it, under what KYC posture.
• Lifecycle events. Partial payments, defaults, restructurings, write-offs.

This contract runs on the Privacy Node alongside the token. It can be private to the institution, exposed to a Private Network, or, where appropriate, deployed to the Public Chain.

See [Deploy a smart contract] and [Interact with smart contracts].

Internal activity (transfers between accounts on the same Privacy Node, contract executions that touch only the institution's own state) requires no further setup. It runs locally and is auditable through the Privacy Node's block explorer.

Step 3: Move the receivable across institutions

Cross-institution movement happens through one of three protocols. Choose based on what the receivable is doing.

Before any cross-institution movement, the receivable token must be registered in the destination Private Network.

• [Register a token in a Private Network]
• [Send Teleports]
• [Cross-Private Network arbitrary messages]
• [Enygma]

Step 4: Audit and explorer

All token and contract interactions on the Privacy Node are visible through the node's block explorer. Filtering by user, token ID and contract is supported. Where the institution has integrated Blockscout (recommended on the Privacy Node anatomy page), this is the interface in use.

For Private Network-level visibility, the Auditor Explorer provides a view across the network, scoped to authorised auditors through Enygma view keys.

For implementation support, contact the Rayls team. A self-service CLI for Privacy Node setup is on the way for June, and additional automation for receivables-specific workflows will follow.