RFC: application-layer BTC/Taproot Asset DvP and a future Lightning path

[DigitalGekko77]

BNNS currently demonstrates a bilateral BTC/Taproot Asset Delivery versus Payment transaction on regtest using existing Taproot Assets mechanisms. Exact quantities are agreed by peers; both asset legs confirm in one Bitcoin transaction or nothing is broadcast. The design requests no BOLT or Bitcoin consensus change.

Lightning settlement is explicitly not implemented. I would value an LDK architecture review of the future direction: could LDK custom messages, onion messages, and payment APIs provide transport and negotiation for an asset-aware atomic exchange while Taproot Assets supplies the asset proof and transfer logic? Or should such a path remain entirely within an asset-channel layer above LDK?

The intended constraints are:

• no fiat or external delivery leg;
• exact signed BTC and Taproot Asset quantities, so no price oracle;
• no permanent coordinator, custodian, arbitrator, or leverage;
• failure before complete atomic settlement must leave confirmed ownership unchanged;
• no claim that issuer or redemption risk becomes trustless.

Which timeout, liveness, proof-availability, and failure invariants would be required before attempting a prototype? I am looking for critical architecture feedback, not proposing a BOLT change at this stage.

The current review update adds a claims-and-maturity matrix, explicit holdout/free-option limits, crash-consistent proof requirements, and fee/pinning/package-relay assumptions. Protocol baseline: 4332b639acced6d0117efe76c702e798ec2ddd26.

Canonical public mirror and current limitations:
https://pointofart.ru/bnns/

Focused review request:
https://pointofart.ru/bnns/docs/developer-review-request.md

GitHub mirror (the author account is currently hidden from logged-out visitors pending Support review):
https://github.com/DigitalGekko77/bnns-protocol