Private credit receivables on Rayls Sovereign

Private credit 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 in a Rayls Sovereign ledger.

Part 1 - Receivables on Rayls, the use case

What changes when receivables move onchain

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 in a Rayls Sovereign ledger 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 in a Rayls Sovereign ledger 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 Rayls Sovereign ledger, 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 remain the institution's responsibility, exactly as today.

Source of truth for the underlying invoice. Rayls Sovereign does not replace the institution's existing systems. Core banking, ERP and invoicing remain the source of truth, and Rayls Sovereign 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 Auditor View, which means cross-institution receivables activity is visible to the network's designated Private Network Auditor without being public to the other participants. The institution's regulatory obligations apply on Rayls as they do anywhere else.

Part 2: Implementing receivables in a Rayls Sovereign ledger

This section assumes Rayls Sovereign 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 Rayls Sovereign, the Enygma privacy layer, and the protocols for cross-institution 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 in the Rayls Sovereign ledger 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.

Offchain receivables data (invoice number, amount, debtor, due date, terms) is read from the institution's existing systems via API integration with Rayls Sovereign. The institution signs the minting transaction, which is what attests onchain that the token represents a real offchain receivable.

See Minting tokens within Rayls Sovereign.

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 in the Rayls Sovereign ledger alongside the token. It can be private to the institution, exposed to a Rayls Private Network, or, where appropriate, deployed to the Public Chain.

See Deploying smart contracts and Interacting with smart contracts.

Internal activity (transfers between accounts in the same Rayls Sovereign ledger, contract executions that touch only the institution's own state) requires no further setup. It runs locally and is auditable through the 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.

Use	Protocol	Why
Confidential transfer of a receivable to another institution, on a Rayls Private Network or via the Public Chain	Enygma	Default for institutional flows. Confidentiality, anonymity and auditability preserved through the four-property framework. Best suited for fungible receivables.
Fast atomic bridging of a receivable between institutions when full Enygma privacy is not required	Teleport Atomic Protocol	Lighter weight and faster. Message payloads are still encrypted end to end, so the Private Network Hub routes without reading them, but amounts are not hidden from the receiving institution and there is no anonymity set. Intended for cross-institution liquidity rather than confidential settlement.
Coordination, settlement instructions or metadata exchange without moving the token itself	Arbitrary Messages	For offchain agreements, payment notifications, or any communication that does not require an asset transfer.

Before any cross-institution movement, the receivable token must be registered in the Token Registry on the Private Network Hub and approved by the Private Network Operator, which is what assigns it the resourceID that other institutions use to recognise it.

Step 4: Audit and explorer

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

For visibility at the Rayls Private Network level, the Auditor Explorer provides a view across the network. It is run by, and accessible only to, the designated Private Network Auditor, and it reads the Private Network Hub's transaction record rather than any institution's own ledger, decrypting it under Auditor View.

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