I have heard many arguments over the years, Hive-Engine is a layer 2 protocol built many, many years ago and still used and integrated into most things on HIVE, including Keychain Wallet and most popular front ends.
Nowadays, there are several alternatives coming into view - this excites me as someone who has always loved building and experimenting with these kinds of decentralized technology. And often when new things start coming around, we contextualize them by comparing them to the old things - very normal! But it has come to my attention that there is a lot of misunderstanding around Hive-Engine, its various parts, and just how decentralized these parts really are.
So I decided to make this post.
Now I like 
So it has not escaped me that, with hive-engine so widely used, new users I onboard often get confused about the "hive-engine hate" that gets floated around, and sometimes the answers that they get back are "it's centralized!", and particularily centralized by
Now, I have been thinking about this a long time - and what follows is my attempt to work with Claude to define what we are calling a "layer-cake" that is behind the myriad of moving parts currently and formerly known as "Hive-Engine".
When people say "hive-engine", they are usually referring to one thing. They are actually referring to somewhere between 6 and 7 distinct pieces of infrastructure, governance, and operational promises - each with its own trust model, its own failure modes, and its own level of actual decentralization.
I have been building seriously on hive-engine for about a year now alongside my brilliant friend and wizard @thecrazygm. I have dug deep. I have heard all the arguments. This is my attempt to break it down layer by layer - not to discourage anyone, but because understanding what you are standing on is the first step to building something that lasts.
Let's eat the cake from the bottom up.
This is the foundation. The actual code - steemsmartcontracts and its descendants - that runs the hive-engine sidechain. It is open source. Anyone can run it. Anyone can fork it.
This is the most durably decentralized piece of the whole stack, because the code exists independent of any team or promise. If everyone walked away tomorrow, the code would still be there. Someone could pick it up.
This is what open source actually means in practice, and it is more important than most people give it credit for in the moment.
Running on top of the node software are the contracts that define what hive-engine actually does. These include:
These contracts, as code in the github, are about as decentralized as anything gets. When they run on the sidechain, on the chain - most contracts have an owner. Some are 
One thing worth knowing about NFT games specifically: almost every serious NFT game on hive-engine eventually ends up spinning up their own private history node. The public nodes cannot keep up with the hammering. This is partially a scaling problem and partially a learning problem - teams figure out how to query correctly after they have already degraded the public infrastructure for everyone else. A private history node is both a solution and a development tax.
This is where decentralization gets complicated fast. Not all tokens are created equal, and the differences matter.
Off-chain custodied wraps (SWAP.BTC, SWAP.ETH, etc.)
The underlying asset lives on another blockchain entirely. You cannot verify the backing from HIVE. You are trusting the custodian - in practice,
SWAP.HIVE — the interesting middle case
The custody is still centralized. Someone holds the HIVE. But the collateral lives on the same chain you are operating on, which means anyone can look at the backing account and audit the peg. It is still a rug vector, but it is a transparent rug vector.
This matters because SWAP.HIVE is not just one token among many. It is the base trading pair for every single market on hive-engine. Many diesel pool, a large portion of the swaps, almost every interaction within the ecosystem routes through SWAP.HIVE at some point. The contracts are solid. The official on-ramp and off-ramp are a toll booth owned by one guy. There are alternative toll booths, but the point remains.
Lateral pools — distinct custodians
This is the part people might miss. While every token automatically gets a Swap.Hive market with order books, you can build pools that do not directly depend on
Our own ECOBANK token has a pool against HSBIDAO, which is backed by Hive Power and run by 
The point is not that lateral pools are risk-free. It is that the dependency graph is more complex than a simple stack. When you are making trade-off decisions, it matters whose custody and what kind of backing you are dealing with.
Running a node means having an API. Most witnesses expose theirs publicly, though not all are required to. This creates a somewhat organic redundancy at the light-node API level - not guaranteed, not formal, but present.
The history node is a different story. History nodes are expensive to run and expensive to maintain. The corporate promise (more on that below) covers exactly one. NFT games and serious developers eventually spin up their own. Everyone else depends on the one.
Light node API availability is distributed. Historical data availability is not, although we have proposed doing work on that front.
This one is not technical at all. It is an operational commitment.
The community has already revealed this floor is insufficient in certain areas. This is in some ways a feature (people can build), and most all serious users used Beeswap. Tribaldex was the fallback you use when nothing else worked. The corporate promise kept the plumbing on. Independent teams built or would build basically everything people actually wanted to use.
That Beeswap became load-bearing UX infrastructure that existed entirely outside the corporate commitment layer, was a feature. Now it is gone, and the floor is showing. We have been working on new tooling, but the lesson remains fresh.
Block validation on the hive-engine sidechain is governed by the WORKERBEE token (witness contract owned by
About a year ago, there was a very real threat - an actor had managed to get 5 of the top 20 witness slots and was going for a 6th. I mustered together a team of roughly 11 stakers and we successfully fought off a possibly impending 51% attack. There was some buying and selling WORKERBEE involved. The attack vector was not technical sophistication. It was apathy. Stake existed but was not engaged. Eleven people coordinating was enough to defend the chain.
The WORKERBEE witness layer now has roughly 30 engaged stakers who mostly pay attention. That is a meaningful improvement. It is also a reminder that decentralization can drift toward centralization through inattention, and can be pulled back through coordination. The code does not protect you always, but the community can.
Tribaldex. Beeswap (RIP). Ecency and PeakD integrations. Your own custom tools if you build them.
Fully centralized each in their own way, obviously fragile, and often the only thing most users ever see. The entire rest of this stack can be functioning perfectly and if the frontend is gone, most people think hive-engine is broken, or dead.
Independent teams filling this layer are doing genuine ecosystem work. They also have no obligation to stay, no succession plan, and no formal relationship with any of the other layers.
The lesson of Beeswap is not that we should have paid them more, although maybe we should have given their proposal a chance in that past time-frame. The lesson is that load-bearing infrastructure built by independent teams is a category of ecosystem dependency that we have not historically thought about clearly enough.
When you say "hive-engine", you are describing a system where:
None of this means hive-engine is broken, nor dead. It means understanding what you are building on and with is non-trivial, and the people who do understand it have an obligation to document it.
This is my attempt at that documentation.
