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.
Aethel · a zkFMI application · 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 zkFMI and never holds the cash.
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
Issuance becomes a typed zkPI instruction. DeFMI settles it and Aethel records the evidence. Paid closes it; default binds a guarantee claim.
Rust state machine12 cratesResearch 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.
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 backed by a DeCCP facility; 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 creates a typed zkPI instruction; DeFMI settles it 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; loss allocation runs in DeCCP, settlement in DeFMI.
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 | |
|---|---|---|---|---|---|---|
StreamAttestorattests a stream and its updates | ||||||
CreditAssessorsigns a decision for one receivable | ||||||
Guarantorcommits cover from an external facility | ||||||
LiquidityProvidersubmits an executable funding quote | ||||||
Servicerperforms permitted servicing actions | ||||||
CredentialIssuervouches for a DeKYX 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 refusedDeKYX presentation 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 | DeKYX issuer | pseudonymous subject reference and a qualification digest |
| Guarantee facility and remaining capacity | DeCCP or the guarantor | opaque hold id and commitment; a settlement digest 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 | DeFMI | note, lock and settlement references; the confirmed root |
| Settlement instruction | zkPI | instruction id, nullifier, domain, proof and signature summary |
Anonymous qualification
A series can require a DeKYX presentation before a decision or guarantee is accepted. 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 DeCCP then exchange commitments, state digests, identifiers and verified transition receipts instead of a plaintext amount.
Settlement with evidence
Issuance and claims become typed zkPI instructions. DeFMI settles; the host validates the evidence; only then does Aethel move to its final state. It never advances on its own say-so.
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 zkPI and DeFMI; Aethel finalises only on confirmed evidence
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
- DeKYX revocation and key rotation reach new operations
- if zkPI or DeFMI 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
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 the adapters to DeKYX, DeCCP, zkPI and DeFMI.
- 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.
- 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
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo fmt --all -- --check
cargo build --workspace --release --locked