Conversation
Add three new optional NUT specs based on the Gnosis Conditional Token Framework: - NUT-28: Conditional token redemption via oracle-attested outcome keysets - NUT-29: Conditional token split and merge for trading positions - NUT-30: Numeric outcome conditions with digit decomposition Includes test vectors, error codes, and README updates.
joemphilips
force-pushed
the
nuts_for_prediction_markets
branch
from
2657a60 to
3f6850a
Compare
joemphilips
changed the title
|
Reference implementation (WIP): cashubtc/cdk#1648 |
joemphilips
force-pushed
the
nuts_for_prediction_markets
branch
from
673ee64 to
ee15247
Compare
…ation, and outcome_collection_id algorithm
joemphilips
force-pushed
the
nuts_for_prediction_markets
branch
from
ee15247 to
63af400
Compare
…tion_id Relax NUT-03 swap constraint from "same keyset ID" to "same outcome_collection_id" so mints can rotate signing keys for conditional keysets without stranding user tokens. Update error 13016 description to reflect the new semantics.
Avoids locking in NUT numbers before they are officially assigned. Updates all cross-references, link definitions, README table entries, error_codes.md, and CLAUDE.md accordingly.
|
@joemphilips have you taken a look at this PR: #128? its a previous standard for DLCs in cashu. you might want to take a look |
|
Hi @lescuer97, thanks for pointing it out. Yes, I've read it. I didn't go into detail because the approach is quite different from mine. IIUC, PR #128 proposes an My concern with that approach is that it's primarily suited for bilateral contracts (two parties
They're not in conflict. In fact, both can share the same oracle infrastructure (DLC oracle |
joemphilips
force-pushed
the
nuts_for_prediction_markets
branch
from
ed0d852 to
94336aa
Compare
joemphilips
force-pushed
the
nuts_for_prediction_markets
branch
from
94336aa to
16b650c
Compare
…ationale Replace vague "left to implementers" pagination notes with concrete cursor-based pagination using since/limit on both GET /v1/conditions and GET /v1/conditional_keysets. Add status filter (repeatable) for conditions and active filter for keysets. Add registered_at field to conditional keyset entries. Document design decisions (download-all- then-sync privacy rationale, >= dedup semantics) in new Q&A section.
2 participants
This is my ongoing attempt to support encoding Prediction Market Token with cashu.
My primary motivation is to
There have been previous attempts to support DLCs on Cashu, for example:
#128
The purpose of those attempts was essentially to emulate a two-party DLC transaction using eCash tokens.
This approach is completely different. Each outcome is encoded as a separate token, and the mint is agnostic to the oracles. I believe this is a more natural representation of a prediction-market security token and enables a more liquid market.
This PR contains three NUTs
Done self-reviewing, it is now ready for review from others. I will try to have a reference implementation ready when I have time. I may update the spec based on what I've learn during implementation.
It is possible to split CTF.md (Conditional Token Framework) into an independent PR if the maintainer wishes. Since this is quite a huge PR.