01/29/26 - Actionables

[codybutz]

• Cody & Kristian - Review kernel spec, provide any comments as GitHub issues.
• Dom - Re-review kernel spec, continue development.
• Cody - Create a better product specification of the bot.
  Each item due by 2/5

[brokri-lgtm]

From the review of the kernel spec. cc @waalge

We rule out the use of more than one validator. ... These disadvantages seem relative small and this is probably worth considering further, resources permitting.

The only advantages sound to me to be only getting the own_hash. We still need to query the own_input to verify it's an authenticated input using an NFT, so just getting the payment credential from it is a negligible extra cost IMO. No need to consider multiple validators IMHO.

Re the types defined here https://github.com/IndigoProtocol/latest-price-feed/blob/dev/docs/kernel-spec.md#types

No need to define both Price(WrappedInt, Timestamp) and also type PriceDatum {..., we can just use the Price(.... However, let's add a test to serialise price with some predefined parameters and expect it equals the CBOR we expect.

Also, both datums and redeemers are defined by parameters being unnamed, I think using named parameters is less prone to error, e.g. Defer {own_index: Int, aux_index: Int} instead of Defer(Int, Int), the serialisation is the same and I'm not aware of difference in performance, even if there is it's probably too minimal for the cost of better readability.

There is one end of life transaction, a burn. In a burn, the Price and Aux are spent, and NFTs burnt. This is included for tidying up, and can be disabled in production if desired.

Yeah, I don't think we need to consider burn at all. I'd keep it minimal and not consider burning.

Feed data is configured at init to correspond to one of the following: a single Orcfax Fact Statement; a reciprocal; a product of two.
For example, Orcfax provides, say, ADA-USD and BTC-USD feed. Then, it must be possible to produce a LPF for ADA-USD, USD-ADA, and ADA-BTC.

We're internally discussing to optimise the oracle updates by having everything connected in ADA on protocol level. I.e. we won't need a single BTC-USD price oracle rather 2 oracle USD-ADA, BTC-ADA. It will help to keep the number of oracles down with multiple assets... Still it might need some transformations in place, e.g. the reciprocal, maybe even the product depending on orcfax's feeds....
It's still a matter of discussions, but giving you a heads up.

If datum, redeemer are (Aux, Update(own_index, price_in, price_out)) ... rules ...

The rules listed there lack the check for the price NFT. It really must be checked that it's retained at the validator's address in the correct UTXO..
Not gonna focus much on the logic there, will properly review/audit the implementation.