BitcoinOS Charms Use Case - Charms Dex on Bitcoin

General Commons DeFi
1

BitcoinOS - Charms DEX on Bitcoin

I just posted my suggestion for the best use case of Charms on X
and wanted to share it with the Sovryn community for thoughts and maybe
participation and other / better sugestions.

https://x.com/WiwiChiDi/status/1927035062341488833

What is charms?

Charms is a metaprotocol that enables native, programmable tokens on Bitcoin
and other UTXO chains without the need for bridging or custodians.

When I read through the whitepaper about “enchanting” and “spells” it reminded me
of magic. So I tried to explain the rather dry and technical side with
Harry Potter Magic so everybody would understand immediately cause it is relatable and
everyone knows Harry Potter.

Here it goes:

Charms dex.
The first programmable private dex - built on Bitcoin. Privacy like Monero. Logic like Uniswap. Compliance-ready like Swissborg. Settled on Bitcoin. A magical guide to privacy & programmability.

The Invisibility Cloak (Privacy)
“I solemnly swear that I am up to no good.” In Harry Potter and the Philosopher’s Stone, Harry puts on his father’s invisibility cloak.
He moves through Hogwarts unseen — doing what he needs, hidden from view.

In Charms DEX: Every trader wears a cryptographic invisibility cloak.
You can swap tokens, provide liquidity, or stake — without revealing who you are or what you’re doing to outsiders.

But unlike dark magic, this is still accountable — the system knows a valid trade happened, it just doesn’t expose your identity.
It’s like being in the market… without anyone front-running, spying, or tracking you.

The Marauder’s Map (Zero-Knowledge Proofs)

“Messrs. Moony, Wormtail, Padfoot and Prongs are proud to present the Marauder’s Map.” In The Prisoner of Azkaban, Harry gets a magical map that shows real-time movements of everyone in Hogwarts — only to those who know how to read it.
In Charms DEX: When you complete a trade, you generate a zero-knowledge proof — a cryptographic map. This map proves that: You followed the rules. The trade was fair. No one was cheated.

But… it doesn’t show your identity, amount, or intentions — unless you choose to reveal it (e.g., for compliance, AML, or credit verification).
Charms gives the protocol a Marauder’s Map, but only with just enough info to verify, not surveil.

Wizard Chess Meets a Hidden Strategy Game

“The key is to act without being seen — but never without consequence.” Imagine a game of Wizard Chess — but instead of an open board, each player moves in the shadows. The moves are:

Hidden from opponents. Verified by a magical judge (ZKPs). Revealed only if needed for final settlement or dispute.

That’s Charms DEX: A private strategy game. All moves (trades) are provably valid. No one can spy, frontrun, or manipulate the system. But outcomes are final and secure — settled on Bitcoin, the world’s strongest magical vault.

What Is the Charms DEX?

In a world where surveillance is the default, Charms DEX is like Hogwarts for Bitcoiners — a place where magic meets rules, and privacy doesn’t mean lawlessness.

A Sorcerer’s Marketplace — where every trade is a hidden spell, cast in silence but sealed with proof.
A forum of Invisible Citizens — where traders gather freely, act privately, and follow laws that only math can enforce.

A Strategy Game on a Hidden Map — where the only thing revealed is that the game is fair.

So far so good.
My thought process here was to focus on the biggest (imo) advantage of Charms.

Using the security of Bitcoin and at the same time provide PRIVACY and still be compliant on the regulatory side.
Privacy will be one of the biggest features in a world of hacks and data breaches.
If done correctly Charms dex could combine the best features of Swissborg, Monero and Uniswap.

  • Like Uniswap, but private.
  • Like Monero, but programmable.
  • Like Swissborg, but decentralized.
    Users can trade assets without revealing amounts, prices, or identity.
    The system can still prove that the trade followed all rules — thanks to zero-knowledge proofs.

We should

  • not trying to compete with Solana or Ethereum on throughput.
  • own the niche of private, Bitcoin-native, programmable DeFi.
  • build ZK compliance into the DEX to attract institutions/regulators in the long game.
    What do you guys think?
2 Likes
2

To begin with, I think I fail to understand what or if this has anything to do with Sovryn?

2 Likes
3

Yeah, I thought this was another thing that was supposed to be a Sovryn project, but then all of a sudden wasn’t. :rofl:

I can’t believe I don’t see more people crying fowl on socials about what was done.

2 Likes
4

so this is a new DEX launching on BOS, with Yago as founder.

what happens to the existing Sovryn DEX?

we were told to sit back, wait & help grow BOS at the expense of SOV
-for this was the best for Sovryn according to @yago

Now it looks like he told us this as an excuse so he could launch all these ideaas himself & replace SOV comunity out of the equation.
we have no working product to generate revenue on BOS and seemingly been scammed.

(i have had a forum debate with @yago and he called me a conspiracy theorist, well its not an conspiracy anymore since it has played out.)

5

No it is not. It is a possible use case for charms. And it is just hypothetical. It is just an idea what to do best with charms as a metaprotocol.

I don’t even understand charms as “tokens” in a sense of “tokens” you can buy but rather tokens that carry certain “function” that were “programmed” in them.

That is why I understand the whole protocol as a possible breakthrough in terms of privacy. You can write logic into charms tokens or conditions and combine them to enable complex functionality / criteria. I am not technical so someone else is more capable of explaining but the way I understand things with charms you could implement KYC procedures without revealing anything in reality. You would program certain conditions via charms tokens (using zero knowledge proofs) and it would be verifyable that you for instance “passed KYC”, “reside in a supported region”, “are not a bot” or whatever else but without revealing the actual user input (name & much more sensitive data etc.). This way certain “states” can be proven and you do not need any intermediaries anymore. Taking this further you could build complex criteria using charms such as:

Regulatory compliance
KYC without doxxing yourself
Obfuscate trade sizes & even who is trading
(as long as all conditions that were programmed are met)

and as a result in the future prevent front running
incentivize institutions or even governments to participate since they could stay hidden

The possibilities are enormously large but I guess to build everything from scratch could take years.

Anyway Sovryn might provide the DEX infrastructure (if that makes sense technically which I have no idea if true or not.)

Tldr.: I did suggest to use the charms metaprotocol to put it to use creating a private (the first) DEX on Bitcoin. An idea nothing more, nothing less.

6

Sharing this here for the more technical people (created by @JaromirTesar)

Charms represents a blend of Bitcoin’s robustness and Cardano’s programmability, introducing Datum and Redeemer-like concepts to Bitcoin in a unique way. In Cardano, each unspent output can include multiple user-defined tokens and an arbitrary piece of data called a Datum. The Datum effectively serves as the local state for a smart contract, associated with that specific output. To spend a “scripted” output, a spending transaction must provide two things in addition to the usual signature: • A Redeemer: an arbitrary input supplied to the contract (e.g., an action or parameter). • The Validator Script itself. To update the state, a transaction must consume (spend) the output and create a new output with a revised Datum (new state). This means the state is passed forward from one UTXO to the next. Cardano maintains state across transactions by chaining UTXOs, with the ledger itself enforcing the contract rules on-chain. The Carm protocol enables something similar on Bitcoin. Most Bitcoin-based protocols, like Ordinals and Runes, rely on centralized indexers to scan the ledger and track ownership off-chain, requiring users to trust third-party databases. Charms eliminates this reliance. Each transaction includes a zkVM-powered “Spell”, a cryptographic proof that ensures: • The transaction and app logic are valid. • Previous transactions were correctly processed. • The spell is authentic, preventing fraud. Thanks to recursive ZK proofs, Charms clients can independently verify asset state without indexers. Spells are the core mechanism that create and transfer Charms assets. A Spell is essentially a blob of metadata attached to a transaction that describes what tokens or state (“charms”) are being created, moved, or destroyed. A Spell is inserted in the witness field of a Bitcoin input, formatted as a no-op script fragment. The spell data is wrapped in an OP_FALSE/OP_IF … OP_ENDIF so that it has no effect on Bitcoin’s script execution.


Image

Inside this “envelope,” the spell contains a structured description of Charms’ operations, plus a cryptographic proof. A Spell typically includes: • A list of apps (smart contracts or token types) involved in the transaction. • The list of input UTXOs being consumed and what charms (tokens/state) they carried. • The list of output UTXOs being created and what charms they will carry. • A zk-SNARK proof attesting that the state transition from inputs to outputs obeys all the rules of the involved apps. When a Charms-enabled wallet sees a Bitcoin transaction, it will look for a Spell in the inputs. If found, the wallet tries to parse and validate it. The Charms metadata for outputs is not stored in the output itself within the Bitcoin transaction. It’s only described in the input’s witness field and interpreted off-chain by Charms-aware clients. Charm state transitions are initiated via on-chain Bitcoin transactions, but the actual tracking and validation of those state transitions happen off-chain. Charm state transitions are valid per application. The Charms parser finds the application (via its identity and verification key) in the Spell and performs the requested operation according to the rules. The next user must retrieve the current valid off-chain state, then use it to construct a new Bitcoin transaction with a new Spell that describes the next valid state transition. Bitcoin alone cannot prevent double-spending of Charms tokens unless those tokens are bound to specific UTXOs (e.g., specific satoshis). If Charms tokens are not tied to specific satoshis, then two valid Bitcoin transactions could exist with different inputs (different UTXOs) and conflicting Charm Spells — both valid from Bitcoin’s perspective. Only the Charm application logic and client validation can detect and reject such misuse.


Image

Because Spells are validated on the client side, participants are free to ignore Charms if they’re not interested. Bitcoin nodes and other wallets see nothing but an innocuous piece of witness data. But users who opt-in by running the Charms software gain the ability to interpret these Spells and thus track and transact smart tokens on Bitcoin. Both Cardano and Charms treat the blockchain as a ledger of stateful UTXOs, but they handle state updates differently in practice. In the case of Cardano, the state is an integral part of the ledger. A Datum lives inside a UTXO; when that UTXO is spent, the state is destroyed on-chain and must be recreated in a new UTXO if it is to persist. The Cardano ledger itself ensures that only a valid state transition can occur by running the contract script. State in Charms is also tied to UTXOs, but the Bitcoin ledger is unaware of the state. Each enchanted UTXO holds a mapping of App → Data, potentially containing multiple independent pieces of state (multiple charms) in one output. To update the state, a transaction must spend the underlying Bitcoin UTXO and create a new one, similarly to Cardano. The Spell attached to that transaction will describe how the charms from the input UTXO map are mapped to charms in the new output(s). State continuity is ensured by the app logic and proofs: e.g., the Spell must prove that whatever the app expected from the previous state X has been correctly transformed into the new state X’ in the outputs. Each app has an identity and a verification key in its definition; this effectively plays a role similar to Cardano’s policy IDs or script hashes, tying state to a particular contract logic. In Charms, multiple apps’ states can be updated in one go since a single Spell can cover many charms at once, enabling composability. Suppose an auction on Cardano uses a UTXO with Datum {highestBid: 100, highestBidder: Alice}. If Bob bids 150, a transaction will consume that UTXO and produce a new one with Datum {highestBid: 150, highestBidder: Bob}. The Plutus script in the consumed UTXO checks that Bob’s bid is indeed higher (150 > 100) and that Bob’s transaction includes the 150 ADA payment, etc., before allowing it. On Charms, an equivalent auction state might be an NFT charm with data {highestBid: 100, bidder: Alice} on a Bitcoin UTXO. Bob’s bid would be a Bitcoin transaction where a Spell describes taking the NFT charm from the input and putting it into an output with data {highestBid: 150, bidder: Bob}. The Spell’s proof would certify that the rules of the auction contract (written in, say, Rust and compiled to a zkVM circuit) were followed – e.g., it checked 150 > 100 and that the appropriate payment was made. Cardano’s approach to extending UTXOs involves attaching explicit data fields to transactions: the Datum holds state, and the Redeemer provides input parameters for scripts. Charms, on the other hand, adds data to transactions in the form of the Spell, which is purely for off-chain consumption. The Spell contains the descriptions of charms (like mini-datums for each asset) and can be thought of as combining the roles of Datum and redeemer in one structure: • It describes the current state being spent (similar to a Datum from the inputs). • It carries the parameters or actions (similar to redeemers) needed to produce the new state. • It even includes the logic validation in the form of a zero-knowledge proof. This means Charms can include richer or larger data (thanks to Taproot’s flexibility) without burdening all network nodes – only those interested will process it. In Cardano, validation logic is separate from the data (the script is a separate entity, referenced by a hash). The Datum and redeemer are fed into the script. In Charms, the logic comes attached with the data in a sense – the verification key (vk) of each app points to the logic, and the Spell’s proof proves that the logic was executed correctly. To illustrate, Cardano might say: “Output X is locked by script hash H. Datum = 42. Redeemer = ‘increment’. The node will run script H with those inputs to decide validity.”


Image

Charms would say: “Output X is enchanted with app (vk = V) whose state = 42. A spell is cast with an operation ‘increment’ and a proof that the app V’s rules allow state 42 to go to 43.” The end result (state = 43 in a new output) is analogous, but Cardano had the chain execute the script, whereas Charms had the user’s machine execute the logic (off-chain or in a ZK circuit) and merely record the outcome + proof on-chain.


Image

Cardano’s Pros and Cons: • Pros: Security is rooted in the blockchain’s consensus. Users don’t need any extra verification software to trust outcomes – if it’s on the ledger, it followed the rules. This reduces the risk of users accepting invalid states by mistake. • Cons: Limited throughput and high execution cost, since every node executes every contract. Developers are constrained by the execution model and programming model. Charms’ Pros and Cons: • Pros: No additional burden on the base chain. Charms transactions have minimal impact on Bitcoin’s performance (aside from adding some extra bytes in blocks). The heavy lifting of contract execution is done off-chain by the party creating the transaction, who generates a proof of correctness. This opens the door to much more complex logic than would be feasible on-chain. Moreover, it also naturally provides privacy in some cases. • Cons: Security and trust are shifted to the client side. If a user does not run a Charms client, they could be fooled by a transaction that claims to transfer a token but has an invalid Spell. Bitcoin’s network won’t invalidate such a transaction – it’s up to you to check the proof. This introduces a slight trust model nuance: you trust math (the zk proof) and your software, instead of the global consensus, to enforce rules. • Another con is the complexity of setting up these zkVM circuits and proofs. Writing a smart contract in Rust that compiles to a zk circuit may be a higher bar for developers than writing a Plutus script. The proving process also means transaction creators might need significant computation to produce a proof, though verification for others remains fast. Cardano’s model is fully on-chain execution, maximizing security at the cost of scalability, whereas Charms is off-chain execution with on-chain proofs, aiming for scalability and cross-chain flexibility at the cost of making validation a local responsibility. Both approaches seek to bring programmability to UTXOs, but they lie at different points on the spectrum of on-chain vs. off-chain workload.

4:40 PM · Jun 2, 2025

1 Like