Aethel · payment-stream receivables · by æmeth

The payment stream is the receivable.

Aethel takes a payment stream that both parties have signed and turns it into a receivable that independent credit assessors, guarantors, liquidity providers and servicers can act on, each with its own signed authority. It settles through a settlement rail it does not own, zkFMI or any system that returns signed attestations, and never holds the cash.

See the lifecycle ↓Enterprise PoC guide ↗

Built for the teams who run origination, credit, funding and servicing.Nothing here is a marketplace or a lender. Aethel is the state machine those teams plug their own providers into, and the record they can audit afterwards.

01Signed payment stream
Both parties sign the schedule and terms; an attestor confirms it. Every update is a new version.
02Receivable
A series policy admits the stream. A credit decision, a guarantee and a funding quote attach, each signed by a different provider and bound to this receivable only.
03Settlement
The rail witnesses issuance: a settled zkPI instruction on zkFMI, an operator-signed settlement on the attested rail. Aethel records the evidence. Paid closes it; default binds a guarantee claim.

Rust state machine13 crateszkFMI or attested railResearch implementationNot audited

What Aethel is

Not another ledger of invoices. A state machine for obligations.

Aethel does not hard-code a lender, a rating model, a guarantor or a marketplace. It records what a payment stream means commercially, who has decided what about it and where each decision stands, and hands anything that moves value to the settlement layer.

Signed, versioned streams

A stream is registered with its terms, a version and both signatures. Updates are new versions; a stale version cannot be financed, and the same obligation cannot be registered twice under another identifier.

Series with a policy

A receivable series says which streams may be financed and under what rules: whether a guarantee is required, which qualifications the counterparty must prove, what expires when.

Decisions bound to one context

A credit decision, a guarantee and a funding quote each carry the exact receivable, a validity window, a nonce and the provider’s signature. None of them can be replayed for another receivable.

Lifecycle

Five stages. Every transition has a reason to refuse.

The core is deterministic: the same inputs always produce the same state. What makes it useful is what it rejects.

01 · Register
Attest the stream, open a series
The stream attestor confirms the payment stream and its updates. A series defines which streams are eligible and under what policy.
Refusedunsigned stream, or a version that does not matchthe same obligation registered twice
02 · Assess & cover
Signed decisions, committed cover
A credit assessor signs a decision for this receivable. A guarantor commits coverage from a facility the rail vouches for: a DeCCP hold on zkFMI, an operator-signed hold on the attested rail. The amount can stay confidential.
Refusedexpired decisionpolicy requires a guarantee and none is attachedartifact signed under the wrong capability
03 · Fund & issue
Quotes compete, the receivable is issued
Liquidity providers submit executable quotes. Issuance is witnessed by the rail, a settled zkPI instruction or a signed attestation, and Aethel records the evidence.
Refusedfinal state before settlement evidencequote from an unregistered providersupply above the obligation
04 · Service
Evidence in, state out
Payment evidence, delinquency, cure and permitted servicing actions are recorded by the servicer. A retried request applies once.
Refusedthe same settlement result applied twiceservicing action outside the capability
05 · Close or claim
Paid closes. Default claims.
A paid obligation closes the receivable. A default attestation binds evidence to a guarantee claim; the rail allocates the loss and settles it, DeCCP and DeFMI on zkFMI.
Refusedclaim without a default attestationrelease by an unauthorised provider

recordsRegisteredStreamReceivableSeriesCreditDecisionGuaranteeCommitmentFundingQuoteReceivableIssuanceDefaultAttestationGuaranteeClaimProviderDefinition

Open provider model

Six capabilities. None implies another.

Providers register with narrowly scoped capabilities and sign only the artifacts they are responsible for. A credit assessment cannot quietly act as a guarantee; a guarantor cannot issue a funding quote unless separately authorised. One company may hold several capabilities, each granted and revoked on its own.

	Stream attestation	Credit decision	Guarantee	Funding quote	Servicing action	Issuer vouch
`StreamAttestor`attests a stream and its updates
`CreditAssessor`signs a decision for one receivable
`Guarantor`commits cover from an external facility
`LiquidityProvider`submits an executable funding quote
`Servicer`performs permitted servicing actions
`CredentialIssuer`vouches for a qualification issuer key, nothing else

A filled dot is the only artifact that capability may sign. Everything else is refused at the state transition, not by convention.

register → active → suspended → revokedkey rotation: old signatures stay verifiable, new ones under the retired key are refuseda qualification proof, DeKYX presentation or issuer statement, can be required before a decision or guarantee is accepted

Where things live

Aethel holds the meaning. Everything else stays where it is authoritative.

A receivable touches money, identity, guarantees and tokens. Aethel keeps one copy of each, in the system that is the record for it, and stores only references and digests. The same balance, qualification or facility is never copied into a second ledger.

Information	System of record	What Aethel keeps
Payment stream, series, remaining principal	Aethel	both signatures, versions, terms, current state
Credit decision	the assessor signs · Aethel accepts as state	signed decision, target, version, validity, provider reference
Legal name, registration number, KYB evidence	Qualification port · DeKYX issuer, or an attesting issuer	pseudonymous subject reference and a qualification digest
Guarantee facility and remaining capacity	Settlement rail · DeCCP, or the guarantor’s operator	opaque backing reference and commitment; settlement evidence on release or claim
Token holdings per holder	DeFMI or another asset ledger	supply caps and mint/burn intents with the ledger receipt; no per-holder balances
Cash, securities, collateral	Settlement rail · DeFMI, or the operator’s ledger	backing references and settlement evidence; the confirmed root on zkFMI
Settlement instruction	Settlement rail · zkPI on zkFMI, a signed attestation otherwise	instruction id, nullifier, domain and proof digest; or the attestation digest

Anonymous qualification

A series can require a qualification through the port before a decision or guarantee is accepted: a DeKYX presentation on zkFMI, an issuer-signed statement on the attested rail. It is bound to this domain, action, artifact statement, nonce and expiry, so a proof for one decision cannot be replayed for another. Aethel keeps only the verified subject-line binding, never a legal name.

Confidential cover

The guarantee amount may stay confidential. Aethel and the rail then exchange commitments, state digests, identifiers and verified transition receipts instead of a plaintext amount; on zkFMI that counterpart is DeCCP.

Settlement with evidence

Issuance, releases and claims are verified by the settlement rail before the book moves. On zkFMI they become typed zkPI instructions that DeFMI settles; on the attested rail an operator-signed settlement is the witness. Aethel never advances on its own say-so.

Settlement rails

Two ports. Two rails shipped. The business crates depend on neither.

Everything Aethel does not own is reached through two ports in the core: a settlement rail that vouches for backings and witnesses issuance, release and claim, and a qualification port that says who stands behind an anonymous line. The rail is chosen per deployment. The book, the artifacts and the tests are the same on either.

zkFMI rail

aethel-defmi-host · aethel-dekyx

zkPI instructions settled by DeFMI, DeCCP holds for confidential cover, DeKYX presentations for anonymous qualification. Requires the hybrid signature suite, Ed25519 + ML-DSA-65.

Attested rail

aethel-rail-attested

Operator-signed holds, reservations and settlements; issuer-signed qualification statements. Ed25519 only, and no zkFMI crate in its dependency graph. A conventional settlement system that can sign its records is enough.

SettlementRail

Is this guarantee or funding backing live? Does this witness settle exactly this issuance, release or claim?

QualificationPort

Who stands behind this anonymous line, and does the proof bind to this decision and nothing else?

nine business crates: no zkfmi, zkpi, defmi, deccp, dekyx or qomm in the normal dependency graphsignatures: Ed25519 by default, hybrid behind a cargo featurea series policy may restrict which kinds of obligation it financesswitching rails changes the host, not the book

Enterprise PoC

Run it with your own roles, your own keys, and the failures you expect.

The PoC guide walks from a signed stream to settlement, lists the failure cases that must be refused, the evidence to keep and example acceptance criteria. Roles are separated by key even when one team plays all of them; otherwise the separation of authority cannot be tested.

The minimal scenario

Create a payment stream both parties sign, with subject references instead of raw identities
Register credit providers: keys, qualification conditions, decision validity, model version
Compose the receivable: matching version, unexpired decision, guarantee where the policy requires one
Fund and tokenise: supply never above the obligation, no reuse of redeemed rights
Service and collect: retries apply once, outcomes flow to holders once
Settle through the chosen rail; Aethel finalises only on evidence the rail has verified

Must be refused

financing after the credit decision expired
issuing a guarantee-required product without a guarantee
a guarantee released by an unauthorised provider
acquiring tokens with a revoked qualification
the same stream registered twice under another identifier
a new decision signed with a rotated-out key
the same settlement result received twice
tokens above the remaining obligation

Acceptance, at minimum

authority for credit, guarantee and funding is independent
a required guarantee cannot be substituted by a credit decision
qualification revocation and key rotation reach new operations
if the rail refuses or fails, Aethel’s settlement state does not finalise
after a retry, one business request applies exactly once
every material transition audits back to the input version and signature

Enterprise PoC guide (Japanese) ↗Source ↗Aethel on zkfmi.com ↗

Status and limits

A research implementation, with the edges marked.

Not audited for production use.
Aethel is an embeddable state machine, not a server. The host application supplies authenticated APIs, persistence, concurrency control, key management, and a settlement rail and qualification port. The repository ships two of each: zkFMI (zkPI, DeFMI, DeCCP, DeKYX) and an attested rail backed by operator-signed records that depends on no zkFMI crate.
Qualification is scope-pseudonymous, not issuer-unlinkable. Cross-issuer anti-Sybil policy is a governance decision outside the crate.
Guarantee claims and releases are full-cover transitions; partial cover needs an extended state model.
Legal assignment, perfection, tax, accounting and bankruptcy treatment of a receivable are outside the code and specific to each deployment.
Records are at wire version 2. Earlier snapshots are refused rather than migrated, because nothing is deployed yet.
Passing the build gates is not a substitute for an independent cryptographic, financial, state-machine, host and integration audit.

# the four gates, on Linux with the locked dependency graph · last run 2026-09-13, rust 1.97, 74 tests
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo fmt --all -- --check
cargo build --workspace --release --locked
cargo tree -p aethel --edges normal   # no zkfmi, zkpi, defmi, deccp, dekyx