Parameter Encoding

How offer terms travel across covenants — from official docs.

Docs vs reference repo Official docs describe bit-packed parameter tokens and Pre-lock detection. The current simplicity-lending main branch also uses OP_RETURN metadata and IssuanceFactory-minted utility NFTs. Both patterns solve the same problem: immutable offer terms across chained covenant spends.

Why encode parameters in assets?

A lending flow spans multiple covenant transactions. Parameters (amounts, rate, expiry) must survive each spend without trusting an off-chain server. Parameter tokens carry data in the amount field of a 1-unit UTXO (max 51 bits on Liquid).

FIRST_PARAMETERS_NFT (bits 0–50)

Bits	Field	Notes
[0..15]	Interest rate	16-bit; scale 10,000 = 100%
[16..42]	Loan expiration	27-bit block height
[43..46]	Collateral decimals mantissa	4-bit exponent
[47..50]	Principal decimals mantissa	4-bit exponent

SECOND_PARAMETERS_NFT (bits 0–50)

Bits	Field	Notes
[0..24]	Base collateral amount	25-bit integer × mantissa
[25..49]	Base principal amount	25-bit integer × mantissa
[50]	Free	—

Indexer verification (Pre-lock template)

From the docs, a valid offer-initialization tx must:

Have ≥ 5 inputs and ≥ 6 outputs
Include an OP_RETURN with a BIP340 public key
Use parameter UTXOs on inputs 0–1 with amounts matching the bit layout
Recompile the Pre-lock covenant; CMR must match output 0’s script hash

Covenant chain (first implementation)

Create utility tokens — parameter + role NFTs
Lock collateral — borrower constructs lock covenant
Set up lending — lender funds principal
Settle lending — repay or liquidate