Aethel: programmable payment-stream receivables

The payment stream itself becomes the receivable. Aethel does not hard-code a lender, a rating model, a guarantor or a marketplace: providers join through explicit capabilities, sign the artifacts they are responsible for, and can be replaced or combined without changing the stream's payment semantics. It records commercial meaning and lifecycle; authoritative assets and their settlement stay in DeFMI.

source: aethel/README.md · twelve crates, aethel-core at the centre · research implementation, not audited

End to end

flowchart LR
    S["Signed payment stream"] --> R["Register stream"]
    R --> RS["Create receivable series"]
    K["DeKYX
qualified subject"] --> C
    C["Credit providers
submit signed decisions"] --> G
    G["Guarantors
commit coverage"] --> F
    F["Liquidity providers
submit funding quotes"] --> I
    RS --> C
    I["Issue receivable"] --> P["zkPI
settlement instruction"]
    P --> D["DeFMI
asset and cash settlement"]
    I --> M{"Payment stream outcome"}
    M -->|paid| X["Close receivable"]
    M -->|default| A["Default attestation"]
    A --> W["DeCCP
guarantee claim / loss allocation"]
    W --> D

Open provider model

Capabilities do not imply one another. A credit assessment cannot silently act as a guarantee; a guarantor cannot issue a funding quote unless separately authorised. Providers may be suspended or permanently revoked. Key rotation keeps artifacts signed under a formerly valid key verifiable while rejecting new artifacts under the retired key.

Core state

AethelBook is the validated aggregate. Its records are the registered stream and its state, receivable series and policy, credit decisions, guarantee commitments and releases, funding quotes, receivable issuances, default attestations and guarantee claims, and provider definitions. Operations carry stable identifiers, validity windows, nonces, policy digests and signatures; transitions reject duplicates, unexpected versions, wrong capabilities, expired artifacts and inconsistent references.

Qualification and confidentiality

A series may require an anonymous DeKYX presentation before a credit decision or guarantee is accepted, bound to the exact Aethel domain, action, unsigned artifact statement, nonce and expiry; a proof for one decision cannot be replayed for another. Aethel stores only the verified subject-line binding. The guarantee amount may stay confidential: Aethel and DeCCP then exchange commitments, state digests, identifiers and verified transition receipts rather than a plaintext amount.

Settlement

When issuance or a claim moves assets, the host creates a typed zkPI and asks DeFMI to settle it. Aethel changes its final state only after the host has validated the settlement evidence. A deployment can reserve a DeCCP hold when a guarantee is accepted, bind it at issuance, and release or consume it when the obligation closes.

Crates

crates/
├── aethel-types/              shared identifiers, digests, time and signature checks
├── aethel-provider-sdk/       provider capabilities and signed artifacts
├── aethel-core/               stream, receivable, guarantee and issuance semantics
├── aethel-tokenization/       supply caps and external-ledger mint/burn intents
├── aethel-distribution/       circulation admission, venue fills and settlement binding
├── aethel-obligation-wallet/  bounded pre-authorisation and payment retry queue
├── aethel-servicing/          payment evidence, delinquency, cure and default evidence
└── aethel/                    composition boundary and end-to-end tests

cargo metadata --locked --no-deps is the authoritative inventory. A layout diagram is not evidence that a crate was shipped.

Current limits

• The anonymous credential contract is scope-pseudonymous, not issuer-unlinkable.
• Cross-issuer anti-Sybil policy needs a governance or registry decision outside the crate.
• Guarantee claims and releases target full-cover transitions; partial transitions need an extended state model.
• Legal assignment, perfection, tax, accounting and bankruptcy treatment of a receivable are outside the code.