There is no claims department, no committee, and no admin key.
A default either produces a valid proof of who is owed, or it does not.
The contract verifies that one proof on Stellar, then pays from the reserve.
Underwriters deposit collateral into a non-custodial vault and earn premiums. Cover sold can never exceed the reserve, checked on every purchase.
Bondholders buy cover against default and pay a premium. The amount each holder buys stays private, stored only as a Poseidon commitment.
Anyone runs the settlement program off-chain. It reads the on-chain payment record and proves who is owed, by a published formula, in zero knowledge.
The contract verifies the proof on Stellar and releases each payout from the reserve. A verified proof is the only thing that can move it.
The formula is published and version-pinned.
The proof attests that the payouts followed it exactly.
For an epoch, each owed party has an expected coupon. The settlement program reconstructs, from observed chain data, the qualifying payments that actually arrived on an asset-received basis. The difference is the shortfall.
If the issuer paid in full, the shortfall is zero, every payout is zero, and there is nothing to settle. The program will not produce a proof for a non-default, so no payout can be authorized. That is the property that keeps the design honest: protection that did not trigger cannot be claimed.
And, just as importantly, what it does not.
The proof attests that the published settlement program ran over the supplied inputs and produced exactly these payouts. It binds the result to the positions committed on-chain, to the instrument's pinned rules, and to the payment snapshot it was given. Tamper with any of those and verification fails.
The contract checks a single Groth16 proof using Stellar's native BN254 pairing host function. One verification authorizes the whole settlement.
A proof guarantees correct computation over the inputs it was supplied, not that those inputs are the canonical truth of the world. The honest trust assumption is the integrity of the payment snapshot fed to the program.
On this build the snapshot is assembled from observed chain data; a production deployment hardens that source. Parallar states this plainly rather than overclaiming that a proof certifies reality.
Protection over credit is not new.
What is new is who is allowed to decide a payout.
| Who authorizes a payout | Positions | Funding | Portable | |
|---|---|---|---|---|
| Parallar | a verified proof, no party can override | confidential (commitments only) | funded by construction (cover ≤ reserve) | yes, an on-chain asset |
| DeFi cover mutual | a discretionary member vote | public | shared pool, discretionary | limited |
| TradFi CDS desk | a committee plus a counterparty promise | private, off-chain | counterparty credit | OTC, bilateral |
| Embedded tranche | the issuer's capital structure | n/a | structural subordination | non-portable |
Four contracts, separated on purpose.
Each instrument is an instance, not a fork.
A registry holds instrument types; the factory deploys an instance by cloning a generic vault and settlement contract and cross-binding them. Adding a second instrument is one transaction.
Holds the reserve and the private cover commitments. Deposits and withdrawals are open; only a verified settlement can move funds to a payee. Solvency is enforced on every purchase.
Verifies one proof against the instrument's pinned image id, checks the bindings, and executes the payouts. No admin path, no pause-and-pay, no override.
The per-type rules, compiled to a zkVM image. New rules mean a new type entry with a new image id; live instruments stay pinned to theirs forever. Rules are never upgraded in place.