I've been building on Hive for years now. Prediction markets, card games, lotteries, invoicing tools, payment plugins. I've shipped a lot of stuff on this chain. But until now, all of that work has been at the application layer. dApps, frontends, layer 2 experiments. I've never actually contributed to the core blockchain codebase itself.
That changed this week. I submitted my first pull request to the Hive blockchain repository, and it's a meaningful one. Twenty-five files changed across protocol, chain, API, resource credits, account history, tests, and documentation.
https://github.com/openhive-network/hive/pull/47
I wanted to see where SMTs were at and I was surprised to see they were pretty much done. Some minor things, TODO comments and whatnot, but functionally completed.
But as I dug into SMTs, I realised they were lacking some features that make blockchain tokens useful for devs to build with and Ethereum ERC-20 tokens are the benchmark in my opinion. There were also some runtime guardrails missing that any serious token system needs before you'd trust it with real value.
What the PR adds
1. Token metadata on-chain
There's currently no way to store an SMT's human-readable name, description, or branding on-chain. If you create a token today, clients have no protocol-level way to know what it's called or what it looks like. Everyone has to rely on off-chain sources to display token information, which is fragile and inconsistent across different frontends.
The PR adds smt_set_token_metadata_operation, which lets a token's control account store a name (up to 32 characters), a description (up to 1,000 characters), an image URL (up to 256 characters), and a custom JSON metadata field directly on-chain. The JSON field uses the same relaxed validation path as core Hive JSON metadata fields, so it's flexible enough for whatever token-specific data you need to attach. It can be updated at any time after token creation, and it requires active authority of the control account so random users can't mess with your token's branding.
Every token standard on every other chain has this. SMTs need it.
2. Delegated spending (approve/transferFrom)
This is a big one. Right now, there's no way for a third party to spend SMTs on behalf of a token holder. No approve/transferFrom pattern. If you've worked with ERC-20 tokens on Ethereum, you know this pattern is foundational. Without it, you can't build DEX integrations. You can't build payment processors. You can't build escrow workflows. You can't build any service that needs to move tokens on behalf of a user with their prior authorisation.
The PR adds two new operations:
smt_approve_operation lets a token holder grant a spending allowance to another account. You specify the spender, the token, and the maximum amount they're allowed to spend. Setting the amount to zero revokes the allowance. Setting a new amount overwrites the previous one.
smt_transfer_from_operation lets an approved spender execute a transfer from the token holder's balance to a recipient. It checks that the allowance exists, that the amount doesn't exceed what's been approved, and deducts from the remaining allowance. When the allowance hits zero, the allowance object gets cleaned up automatically.
There's also a new smt_allowance_object with proper indices for looking up allowances by owner/spender pairs and by spender for reverse lookups. And two new API endpoints, find_smt_allowances and list_smt_allowances, so frontends and services can actually query this data.
3. Control transfer
If you create an SMT, you're the control account forever. There's no way to hand off administrative control to another account. That's a problem for any long-lived token project. Teams change. Operators rotate. Projects get acquired. You need the ability to transfer control without rebuilding the entire token.
The PR adds smt_transfer_control_operation, which lets the current control account transfer ownership to a new account. It requires active authority of the current control account, enforces that the new account actually exists on-chain, and prevents you from transferring control to yourself. Once transferred, all subsequent admin operations have to be signed by the new control account.
4. Precision and supply guardrails
These are the kind of things you don't think about until they bite you. The PR adds two runtime enforcement mechanisms that were missing:
smt_create_operation now enforces a precision ceiling (SMT_MAX_DECIMAL_PLACES) during validation. Previously you could create tokens with precision values that weren't properly bounded.
Supply adjustments now enforce max_supply at mint time. If your token has a configured max supply, minting operations that would push the current supply above that cap get rejected. And smt_setup_operation now rejects max_supply values that are lower than the already-issued current supply, so you can't accidentally create an impossible tokenomics state.
These are basic safety rails. If you're going to run a token economy, the protocol itself needs to enforce the rules you set, not just trust that application-layer code will do the right thing.
The details
I tried to do this properly. The PR includes resource credit calculations for all four new operations so they integrate cleanly with Hive's RC system. Account history tracking is wired up. And there are ten new test cases covering validation and application logic for each operation, including edge cases like revoking non-existent allowances, exceeding approved amounts, verifying that allowance objects get removed when fully spent, rejecting max supply below current supply, and enforcing the supply cap during minting.
On the documentation side, I wrote a consolidated SMT developer guide covering the full feature set: operations, lifecycle objects, SMT-aware core operations, database API usage, and RC charging behavior and caveats. I also updated some stale docs that had outdated SMT references and TODO placeholders sitting around doing nothing.
Why this matters
SMTs have been in limbo for a long time. The concept is genuinely powerful. User-created tokens at the protocol level without needing a sidechain or a third party layer. But the implementation has gaps, and those gaps prevent developers from building real things with them.
You can't build a marketplace around tokens that don't have on-chain metadata. You can't build a DEX or any kind of automated trading without delegated spending. You can't run a serious token project if you can't hand off control or trust that supply caps are enforced. These aren't nice-to-haves. They're table stakes for any token standard in 2026.
I've been on Hive since the Steemit days. I've watched features get announced, half built, and then left to collect dust. I've written about wanting more targeted, outcome-driven development on Hive. At some point you have to stop talking about what the chain needs and go do some of it yourself.
What's next
This is my first core contribution, but I plan to keep working through the SMT codebase and submitting PRs where I find gaps. If you're a developer on Hive and you've been thinking about contributing to core but haven't taken the leap yet, come join in. The codebase is C++ but it's well structured, and there's plenty of work to do.
Let's get SMTs over the line.