ENFR
8news

Tech • IA • Crypto

TodayMy briefingVideosTop articles 24hArchivesFavoritesMy topics

WTF is Char? | Bitcoin 2026

BTCBitcoin MagazineMay 19, 2026 at 04:23 PM13:43
Audio player
0:00 / 0:00

TL;DR

Char is a proposed shared sequencing layer for Bitcoin layer-2 networks that replaces trust with stake-based, slashable consensus and verifiable ordering of transactions.

KEY POINTS

A shared sequencing layer for Bitcoin L2s

Char is designed as common infrastructure that multiple Bitcoin layer-2 applications can use to order transactions. Instead of each L2 building its own sequencer, Char offers a shared system that produces a single, verifiable ordering backed by economic incentives. This aims to reduce fragmentation and reliance on centralized operators across the ecosystem.

Stake-based participation and slashing

Participants lock up Bitcoin for defined periods to join a stake-weighted validator set. These participants sign attestations and collectively form consensus. If they act dishonestly, their locked funds can be destroyed, creating direct financial consequences for misbehavior and replacing trust assumptions with cryptoeconomic guarantees.

Verifiable consensus with economic penalties

The system produces proofs showing that transaction ordering was agreed upon by a group with significant value at risk. If conflicting data appears, it implies that at least a third of participants would have had to sacrifice their funds. This makes fraud detectable and economically irrational at scale.

Built as a minimal extension of Bitcoin Core

Char is implemented as a modified version of Bitcoin Core using a plug-in style approach. When disabled, the software behaves like a standard node. When enabled, it adds sequencing functionality without heavily altering the base protocol, maintaining high compatibility with existing infrastructure.

Epochs, identities, and structured consensus

Participants are organized into epochs based on their staked Bitcoin. Each has an identity (“anchor”) and a bond representing their deposit. Within each epoch, participants sign messages tied to specific applications and channels, producing ordered, application-specific data streams.

Leader sampling and continuous coordination

The system uses randomized leader selection to guide message ordering. Leadership rotates frequently, reducing the risk of control or censorship. If a leader behaves poorly, another quickly replaces them, ensuring resilience without centralized authority.

Integration with L2 pre-commit architectures

Most layer-2 systems are expected to use Char between periodic checkpoints to Bitcoin. For example, an L2 might post its full state weekly on-chain, while relying on Char for fast, low-latency consensus in between. This hybrid approach combines efficiency with Bitcoin’s security.

Cryptographic enforcement via signature design

Char leverages deterministic nonce techniques inspired by MuSig and Schnorr signatures. If a participant signs conflicting messages, their private key can be exposed due to nonce reuse properties, making slashing enforceable through cryptography rather than manual dispute resolution.

Open challenges: domains, compression, and incentives

Several design questions remain. These include how new applications register without enabling denial-of-service attacks, how to compress large consensus proofs efficiently, and how to price sequencing bandwidth. Incentive models range from direct fees to more experimental “field-based” approaches that avoid traditional token systems.

Rethinking token-driven economics

The design intentionally avoids relying on tokens as the primary coordination mechanism. Instead, it explores using economic signals and probabilistic incentives to allocate bandwidth and rewards, treating tokens as byproducts rather than foundational elements.

CONCLUSION

Char proposes a modular, economically secured sequencing layer that could standardize how Bitcoin layer-2 systems achieve fast and verifiable consensus while minimizing trust.

Full transcript

I'm going to talk to you about what is char. Um, so Char is the sequencing layer for Bitcoin. Uh, what does that mean? Well, we're going to make a piece of infrastructure that is going to be essential for the future of all layer 2s running on Bitcoin. Um, in this talk in particular, uh, we're going to have three main components, the basics of why char exists, how our underlying architecture works, and then we're going to talk about some work in progress problems that we're tackling. So, first of all, uh, why would anyone want to run char? Well, inside the Bitcoin community, inside the layer 2 community, everybody is really an idealist. We're trying to make Bitcoin and layer 2 on Bitcoin as cipher punk as possible, but at the end of the day, you oftenimes end up having still centralized components that require maybe some sort of trust assumption. And at Char, we do not like that. So, what Char is intending to do is to be a platform that you can run that replaces some amount of trust. And here's what it looks like for somebody who is uh serving as one of these functions functionaries in in char. You lock up some bitcoin for a few weeks. You become a member of a stake weighted participant set. You start signing atestations. You form consensus with other participants. That consensus creates proofs of consensus that can be uh absorbed into a layer 2 application. Um and if you ever cheat, then you lose your money. Um and that's the basis of char. And we are a shared sequencing platform which means that all apps uh all layer 2s in the ecosystem can use our same federation. Um oh that's many many slide. Okay there we go. All right. Um so just as an example of this yesterday uh one of our uh teammates Stu gave a wonderful presentation on how to am I no slides or slides? Slides are there. Okay. uh wonderful presentation on uh exactly what it would look like to build an application and here's a prediction market that he built that runs on top of char. Um so how have we built this uh this char uh client? Um it's actually built directly inside of a fork of Bitcoin core. Um and the way that we've done this is to make a minimal inline set of logic changes um that are all added via a plug-in uh bas basically plug-in interface. So we are almost identically Bitcoin core. Uh you could run char node with char disabled and it would just look exactly like a bitcoin core node but if you pass in some special arguments then you're going to get supercharged with char. So uh how it works uh under the hood is we have uh anchors and bonds. Anchors are identities for each staker. Bond is a certificate of deposit that you place. Uh we have a C validation interface uh based detection system uh that can ingest all the block data figure out who's staked what. Um we then take uh those records of deposits and then we form them into epochs. In each epoch it's a set of participants who have a verifiable amount of Bitcoin that could be burned if they misbehave. Um and so we form these different groups over time. Um, every application in our ecosystem has some sort of ID. Just need to, you know, put that out there. Some sort of address for each application so you can know where to get the data from. And then what we do is every time we have uh an epoch, um, we create a specific per epoch ID for every domain. And then each participant in the network begins signing messages that are relevant for that specific channel. Um, and so the information that is coming out is a verifiable record of the entire network committed to specific blocks of data for this application in a specific order. Um, and the proof that we're exporting is specifically that if you were to ever get a conflicting committed piece of data for an application in a specific order, then you have a third of the network would have had to have destroyed their value in order for that to um be a message that you've received. Um, if you see two of them. And so that's what we're talking about when we talk about verifiable consensus is you can verify that people would be destroying a heck of a lot of money if you were to ever be lied to. So under the hood we implement that by a purify base which is a deterministic non system um from the musig paper um and we use these deterministic nonses to guarantee that if two conflicting statements are ever signed it leads to a key being leaked. This is through a classic uh you know uh more or less a vulnerability in shora signatures that if you ever reuse a knots it leaks your key because we use this deterministic knots that guarantees that if a knots is ever revealed we can find the intersection of the two lines and then we reveal a key. Um so this whole slashing thing it's really not magic. Um all that we're talking about is that char creates publicly verifiable value at risk. If there is an equivocation, then you can be punished. And we track through the epoch exactly how much over time value is at risk at any given moment. And that's how we bind our decisions and proofs against specific groups of people who can be punished. Um, that's really the core algorithm behind Char. Um, in any consensus system, what you'll find is that it's not just everybody shouts and whoever shouts loudest gets consensus. Usually you have some way of finding a leader who can direct. Um this is not a leader like as in someone who's in control. It's more like a guide. Um and so we pick these leaders uh using a sampling algorithm that randomizes who's allowed to guide the network at any given time and we change that over on every single uh message essentially of who's leading and the whole network tries to follow them and if they are a bad leader then the next leader is just moments away. So um under the hood you know we have code that does this. I'll skip skip over this a little bit. Um for the applications that are using this generally they're using what's called a pre-commit architecture. A pre-commit architecture is where you are using char network for consensus for a bounded period of time between which you're posting state snapshots back onto Bitcoin. And so the general uh architecture that a layer 2 uses is they want to post data to Bitcoin on some period. Let's say they want to post once a week between those weekly postings where they post the state of their whole application. They want some amount of low latency verifiable consensus happening and they would use char for these verifiable state transitions between their posts back to Bitcoin. Um if you don't want this pre-commit architecture in theory you can use char um and just have that be your only means of consensus. Um but proofof work checkpointing is a really great tool and we think that most uh layer 2 are going to use that in particular because they are intending to make bitv like which I'm sure you've heard a lot about over the course of uh you know this uh this conference uh bridges should be able to trustly bridge and those require commitments on chain. So now maybe the fun part is what's left to do. All of what you've seen so far is stuff that we've basically implemented. Um and we have a lot of things that um that we're planning on working on or wrestling with and if you were to join our team, you could help us uh figure those things out. So one question for us is uh we're currently a dumbpipe architecture. That means we don't care what the data looks like. However, there are ways that we can maybe not a full validation but a light amount of validation per application. This might streamline um the way that layer 2s can integrate. So that's something that we have under consideration. Um another open question that we're working on is uh where domains come from? How do you register and create a new domain? This is something that there are denial of service issues with if you can just create infinite domains. We have some mitigations that we're working on, but it's an open topic of of research um that we're going to pitch out to the wider layer 2 community of exactly how they want to register their layer 2 and be able to read data from the network. >> Welcome to predict. The world is a market. Everything is a market. Every headline moves the line. Every moment is your market. Call the moves. Bet on your instinct, your prediction, your edge. Dual bits predict where everything is a market. Uh compression is also another open topic that we're working on actively. The verifiable decisions that we produce from char are actually quite large. Most of the layer 2s that exist, they have their own bespoke compression technologies um usually based on zero knowledge proofs to take some set of transactions and reduce the size of the data that needs to go back to be posted on chain. Um we don't therefore provide our own native solution for that. But there are some approaches that we could take that would make our proofs natively smaller and would reduce the burden for layer 2s to compress the uh decisions being exported out of char. Um and then the last uh sort of open area that I want to talk about is a little bit more nuance and I've been rushing to give a little bit more philosophy. Um is the question of what gets sequenced and why. And this is a really a question of uh incentives. Um and interestingly in char they're there they're sort of a natural market where stakers in a sense are producing a amount of bandwidth that they themselves don't necessarily intend to use. uh and consumers uh layer twos want that bandwidth and it's an open question of how should they pay for it. Should they pay via Bitcoin? Should they pay through a token? Should they pay be via being able to extract some sort of minor extractable value that the act of sequencing itself is just something you can make money from doing by choosing what goes in. Um there are a lot of different models that have been explored for this in the literature um or prior art. There's sort of first come first- serve free-for-all. This is obviously bad for denial of service reasons. Um there are purchase models where you pay for every bite going in maybe somewhat explicitly. Um and then one thing that I want to just talk about which is maybe a new conceptual direction is uh fields. And I mean that in like the physics sense of the word field because we don't actually love tokens. You know we we're kind of anti-token largely at Char. Um but we're trying to solve a real problem in bandwidth allocation and something that in our thinking uh we have observed is that tokens are kind of like particles and particles you know that everybody knows the particle wave duality but there's also uh fields as a part of that story as well and tokens economic signals and incentives also kind of form a similar triad of concept. cepts where um essentially any system that you have uh waves, you have things that you could maybe interpret in another way as being a a particle. It's a pattern inside of uh a wave. A waveform is a pattern and then certain types of node within that pattern behave like particles. And similarly for an economic system, you have signals and incentives and then you have fixed points that behave like a token. And so we're in in being anti- token, we we've maybe arrived at a place where a token is an artifact of a of a real economic phenomenon happening. It's any time that you can discreetly bundle um uh you know bundle something together. And this is where it's an open area of research for us is can we uh make our incentive system work more in the signal and incentive space um with a smart use of maybe like a particulate charge that we're placing to steer in a more uh probabilistic or stochastic way how every participant operates without denial of service and without maybe some of the traditional problems that you have when you try to define your economic system token first. We want to focus on incentive, signal, uh, field, and wave before we, you know, think about how those things become discretetized. And that's sort of an open area of of research that we're going. For now, we're really just focused on building the best possible consensus primitives and we'll worry about the behavioral sides uh as they become necessary. So, thanks everyone for coming out. Um, I don't think I know if I have time for question, but if I do, I'll gladly take some. Thank you. Every year, this community comes together to celebrate, to debate, to build what comes next. And every year, the stage gets bigger. Sound money, center stage. So, where do you go to celebrate the next chapter in Bitcoin history? You come home. Nashville, July 2027.

More from BTC