How Steem Witnesses can help the SVM Dream . Bridging SVM to Steem: A Witness-Based Bridge Oracle
HF24 introduces a permissionless, supply-neutral mechanism for returning STEEM and SBD from the Steem Virtual Machine to the Steem mainnet, secured by the existing witness set rather than a separate bridge authority.
Commit:35d06de2e031e81e00f4231ae448ff8de33e7bbe
Background
The Steem Virtual Machine (SVM) has STEEM and SBD as native tokens, and those tokens eventually need a reliable path back to the Steem mainnet and into an ordinary account. The conventional way to build such a bridge is to establish a dedicated committee with its own multisig keys and entrust it to move funds. That approach adds a new trust boundary: another key set to secure, another operator that can fail or be compromised, and a gatekeeper positioned to approve or deny transfers.
HF24 avoids introducing any new authority. It reuses the same witnesses that already secure the chain.
Summary
When a user burns Steem or SBD on the SVM, the resulting withdrawal appears on the SVM's public feed. An oracle process operated by a Steem witness observes the withdrawal and broadcasts a signed attestation to the Steem mainnet, recording the transaction hash, destination account, and amount. Other witnesses do the same independently. Once a sufficient number of the currently scheduled witnesses agree on identical withdrawal details — 17 of 21 on mainnet — the chain releases the funds to the recipient from the account that holds the backing for all SVM tokens. A short maturation delay ensures the decision is final before funds move, and a permanent on-chain record prevents any withdrawal from being paid more than once.
No dedicated bridge committee or separate multisig custodian is involved.
Mechanism
SVM burn ──► witnesses attest ──► consensus ──► 22-block wait ──► paid
(user) (bridge_submit) (17 of 21) (finality) (svm.bank → recipient)
1. Burn on the SVM. The withdrawal is recorded as PENDING with a burn transaction hash, a destination Steem account, and an amount.
2. Witness attestation. Each witness runs an oracle process that polls the SVM feed periodically. For every new withdrawal, it signs and broadcasts a bridge_submit_operation attesting to that specific withdrawal. Submission batching is irrelevant to consensus: the chain evaluates each withdrawal independently.
3. Consensus. The chain counts how many currently scheduled witnesses have attested to identical withdrawal details. A dishonest witness cannot corrupt the process; at worst it attests to an incorrect version, which becomes a separate candidate that never accumulates enough honest confirmations. Testnet requires a single confirmation for rapid testing; mainnet requires 17 of the 21 scheduled witnesses — the network's standard supermajority.
4. Earmarking. When consensus is reached at block C, the chain debits the amount from the reserve account and schedules payout for block C + 22 (approximately 66 seconds later). No payment is made yet; the funds are set aside, and competing or duplicate candidates can no longer interfere.
5. Payout. At block C + 22, the chain credits the recipient, emits a public "Bridged From SVM" record, and writes a permanent marker finalizing the withdrawal. The 22-block delay ensures the consensus block is effectively irreversible before any funds move, preventing a reorganization from causing a double payout.
A withdrawal that fails to reach consensus before its deadline (approximately 3.5 days) expires without moving funds and may be resubmitted later.
Supply neutrality
Every token on the SVM is backed one-to-one by STEEM or SBD locked on Steem, and the account that holds all of that locked backing is svm.bank. Its balance is the proof of the SVM's supply.
The keys of svm.bank are permanently nullified: no private key can spend from it, and only bridge consensus can release funds. Returning funds is therefore an internal transfer, svm.bank → recipient, drawing on the locked backing that already exists. Total STEEM and SBD supply is unchanged by any bridge operation. The chain's own supply-accounting checks are extended to account for amounts that are in flight between the consensus block and the payout block, so the ledger remains balanced throughout.
Implementation overview
HF24 adds three consensus components:
- A signed operation,
bridge_submit_operation, carrying a batch of withdrawal attestations from a witness, together with two chain-emitted virtual operations:bridge_release_operation(the "Bridged From SVM" credit) andbridge_oracle_expired_operation. - An evaluator that accumulates confirmations per distinct
(tx_hash, payload)from currently scheduled witnesses, enforces one attestation per witness (anti-equivocation), and earmarks funds fromsvm.bankupon reaching the threshold. - A per-block routine that releases matured entries to their recipients, writes the permanent replay guard, and expires stale candidates.
All logic is hardfork-gated and fully deterministic; every node reaches an identical result by replaying chain state, with no dependence on optional plugins. Read APIs (find_bridge_oracle, find_bridge_processed) allow anyone to track a withdrawal's progress toward consensus and confirm its release, and the "Bridged From SVM" credit is recorded in the recipient's account history.
The complete technical specification — data structures, indexes, serialization, constants, evaluator and per-block logic, the API reference, and the full list of changed files — is available in github.
Example: a bridge-in on-chain
The following is a real settlement on a running testnet, tracing one withdrawal of 1000 STEEM to blaze.apps from the witness attestation through to the final credit.
1. The oracle broadcasts an attestation. The witness process logs each submission as it goes out:
[poll] SVM pending_withdrawals=1
bridge_submit publisher=initminer
svm_burn_tx : 2bedd554ae62c4c8c21d5530f006f28f6703581afe33f5d2f5f0607398c4c003
recipient : blaze.apps
amount : 1000000 (1000.000 STEEM)
broadcast OK — witness attested (awaiting on-chain consensus)
2. The attestation is included in a block as a signed transaction. bridge_submit_operation is an ordinary signed operation, so it appears in the block's transaction list (virtual_op: 0, a real trx_id). Here it landed in block 21404:
{ "trx_id": "e97796dbaf092ca4f4548048e737071c9a728c12",
"block": 21404, "trx_in_block": 0, "op_in_trx": 0, "virtual_op": 0,
"op": {
"type": "bridge_submit_operation",
"value": {
"publisher": "initminer",
"requests": [{
"tx_hash": "2bedd554ae62c4c8c21d5530f006f28f6703581afe33f5d2f5f0607398c4c003",
"block_num": 173386,
"block_time": "2026-07-29T01:29:24",
"recipient": "blaze.apps",
"amount": 1000000,
"symbol": { "nai": "@@000000021", "decimals": 3 }
}]
}
}
}
At this block the confirmation threshold is met (a single witness on testnet), so the chain debits svm.bank by 1000 STEEM and earmarks the payout — no coins are credited yet.
3. The chain releases the funds as a virtual operation. Roughly 22 blocks later, the maturation delay elapses and the chain emits bridge_release_operation. A virtual operation is generated by the chain itself, not submitted by anyone, so it is not part of a signed transaction: its trx_id is all zeros, trx_in_block is 4294967295, and virtual_op: 1. Here it landed in block 21425:
{ "trx_id": "0000000000000000000000000000000000000000",
"block": 21425, "trx_in_block": 4294967295, "op_in_trx": 0, "virtual_op": 1,
"op": {
"type": "bridge_release_operation",
"value": {
"tx_hash": "2bedd554ae62c4c8c21d5530f006f28f6703581afe33f5d2f5f0607398c4c003",
"block_num": 173386,
"block_time": "2026-07-29T01:29:24",
"recipient": "blaze.apps",
"amount": 1000000,
"symbol": { "nai": "@@000000021", "decimals": 3 },
"confirmations": 1
}
}
}
At this block blaze.apps is credited 1000 STEEM. The debit from svm.bank (step 2) and the credit to the recipient (step 3) are the two halves of a single supply-neutral transfer; total supply is unchanged.
Virtual operations such as
bridge_release_operationare only returned by the modern
account_history_api(e.g.get_ops_in_blockwithonly_virtual), not by the legacy
condenser_api, which drops operation types it does not recognize.
4. State APIs confirm the outcome. Because the withdrawal has settled, the permanent replay guard is present and no live candidate remains:
// database_api.find_bridge_processed { "tx_hash": "2bedd554…c4c003" }
{ "records": [ { "id": 5, "tx_hash": "2bedd554…c4c003", "processed_block": 21425 } ] }
// database_api.find_bridge_oracle { "tx_hash": "2bedd554…c4c003" }
{ "candidates": [] }
The presence of a find_bridge_processed record is what guarantees the same withdrawal can never be released again.
Conclusion
HF24 returns Steem & SBD from the SVM to Steem using the network's existing witness set, backed one-to-one by locked reserves and settled without any change to total supply. It removes the need for a separate bridge authority while preserving the security guarantees the chain already provides.
@cur8 @steem-agora @blaze.apps
Do we really want to have the results of one LLM evaluated by another LLM here, and decide on a HF based on that?
I have a few basic questions:
svm.bankaccount, 50 STEEM are sold, 150 STEEM are burned on SVM, 150 STEEM are repaid. What happens to the remaining 50 STEEM that were sold on SVM?And I have a few more first thoughts:
svm.bankshould not accept SBD. In the event of interest payments, it is unclear how these will be repaid.bridge_submit_operation. I have to agree with Claude (No. 6). That generates a lot of spam. Perhaps there are alternatives.0.00 SBD,
10.36 STEEM,
10.36 SP
Hello @moecki ,
Yes i compiled the code successfully and i have a public testnet now rpc exposed to https://testnet.blazeapps.org. The code is not 100% by LLM , its howerver built using LLM . THE SVM Withdrawl feed is an api endpoint that responds all SVM based withdrawls . SVM Nodes has api endpoint
/steemvm/steembridge/v1/pending_withdrawals, each withdrawl has a id and is incremental (N+1) . The STEEM sold on the SVM Dex or moved out to other chains Through IBC stays in the svm.bank . Burnt STEEM on TX fees are Chains Revenue , SVM -> Steem miannet is a user driven event in SVM when a users calls specific function to bridge back X amount of STEEM or SBD . Interest payments is co-ordinated , SBD can also have interest . Yield is possible on SVM but has to go through a Gov Proposal . Spam can be mitigated by applying a certain percent fees on the bridge both way . I put it ( 21 + 1 ) block because 21 blocks is the standard mathematical round in the DPoS schedule0.00 SBD,
3.53 STEEM,
3.53 SP
Thanks for your reply.
nice to see your testnet running. 👌
Okay. Is it correct that witnesses need to run a separate script if they want to monitor the feed? Would almost all witnesses do that? Note that there is also one non-top witness included. In that case, at least 17 of the top 20 witnesses must monitor the feed continuously (or at least once every 3.5 days).
I don't know how does the witness node receive the information that it should now authorise the payout? I wasn’t able to test this, as I didn’t receive any results from the endpoint. Is it correct that a GET request must be sent to https://evm.blazeapps.org/steemvm/steembridge/v1/pending_withdrawals ?
Hm, isn’t that a problem? That means there’s no synchronisation between the account balance on
svm.bankand the SVM supply. How should this be handled if a STEEM buyer on SVM wants to withdraw their STEEM from the mainnet?You mean that if interest is paid on the mainnet, it will also be paid on the SVM? Who or what is supposed to ensure that they run in parallel? That seems too uncertain to me. Even a slight deviation can lead to different amounts. Is interest on STEEM also planned for the SVM? Probably for all sorts of tokens, right?
Yes, that's good. But perhaps a percent fee with a minium amount would be better for micro returns (e.g. for 0.001 STEEM?).
Okay, but then we should use the existing constants to define these things. Or new constants defined by the existing constants. But that's a matter of code review. There are some odd uses.
0.00 SBD,
0.54 STEEM,
0.54 SP
Hi @moecki , yes the proposed Approach requires all witnesses to monitor the feed and report the bridge events , Similar to how it is actually required for them to run the price feed . This approach assumes witnesses are concerned about the Bridge as much as they are concerned about the price feed .
I missed to copy whore url for the rest api server , you can get
The Assumption and recommendation is that witnesses run their own node so the data they get is through directly querying the chain rather than relying on the third party api who can be dishonest as well .
If svm.bank starts receiving interests on SBD , Validators may propose a Governance proposal to pay SBD interests on SVM and it comes from inflation , only if the validators are able to pass the proposal . If not svm.bank will be holding surplus SBD , It wont be a problem that svm.bank has more balance than the circulating supply of steem and sbd on svm . the opposite should never happen . Both STEEM and SBD on svm can generate yeild , provided validators change inflation rate which is 0% at genesis .
Yes , We can add a minimum withdrawl , hard code and also add a additional fees on bridge events which can be burnt maybe , its just hypothesis , the current code is 1:1 and no fees or minimum is set , but its an easy addition i believe .
The birdge reuses some constants and introduces some
STEEM_BRIDGE_ORACLE_LIFETIME_BLOCKS re uses STEEM_BLOCKS_PER_DAY * 7 / 2)
STEEM_BRIDGE_ORACLE_MAX_CANDIDATES = 3
STEEM_BRIDGE_ORACLE_MATURITY_BLOCKS (STEEM_MAX_WITNESSES + 1)
You are right, any or every progress is better than stagnation, especially when STEEM’s price is falling and the community needs momentum to stay engaged. Even small developments can restore confidence, encourage participation, and reduce the urge to sell.
When users see steady improvements, they are more likely to remain active, create content, and support the platform through difficult market periods. Growth does not always have to be dramatic but consistent updates, better features, and visible action can build trust over time. In a declining market, progress itself becomes a signal of resilience and commitment.
In fact, I have been writing about it in different posts as a comment and strongly support your post.
0.00 SBD,
9.01 STEEM,
9.01 SP
Thank you for your Kind words and the support !!
0.00 SBD,
0.15 STEEM,
0.15 SP
Welcome.
something is already better than nothing , when the STEEM price is Declining and we need something to hold back the users and their sell pressure
0.00 SBD,
8.85 STEEM,
8.85 SP
Very True !
This is a promising approach that leverages Steem's existing witness consensus instead of introducing a new trusted bridge authority. Constructive questions and thorough code review will only make HF24 stronger. Looking forward to seeing further testing, refinement, and community collaboration before deployment.
0.00 SBD,
8.24 STEEM,
8.24 SP
Yes , 100% . Thanks for visiting my blog
The steem price is declining daily , for over 3 years or more now . One key reason is no development that is meaningful. I hope #SVM and #Sherpa can bring back momentum
0.00 SBD,
8.11 STEEM,
8.11 SP
you are 100% Hoping on the Right Direction
I tried to analyze the HF with Claude. Some questions came up from that...
1. Oracle data source. The consensus evaluator is deterministic, but the input isn't — each witness polls "the SVM feed." Is every witness expected to run a full SVM node and validate independently, or is this polling a shared RPC endpoint? If it's a shared endpoint, the trust boundary hasn't been removed, just moved behind 21 signatures. What are the node requirements?
2. SVM-side reorg. The 22-block delay covers Steem-side finality. What covers the SVM side? If a burn tx is reorged out after witnesses have attested, svm.bank pays out against a burn that no longer exists. Is there a required confirmation depth on the SVM before an oracle should attest, and is it enforced or just convention in the daemon?
3. Signing key. Which key signs bridge_submit_operation — the block signing key, the active key, or a dedicated one? If the daemon needs an active key on a hot machine, that's a meaningful new attack surface for every witness in the top 21.
4. 17/21 liveness. That threshold means 5 non-participating witnesses halt the bridge. With the rotating timeshare slot, the scheduled set changes every round. If a witness attests and then drops out of the schedule before consensus is reached, does its attestation still count, or can the confirmation count decrease? And what's the realistic plan if fewer than 17 witnesses actually run the daemon at launch?
5. No correction path. One attestation per witness per (tx_hash, payload). If an oracle attests to a bad payload because of stale data or a bug, is that witness permanently excluded from that withdrawal? With only a 4-witness margin, two buggy oracles could brick a legitimate withdrawal.
6. Spam amplification. Every withdrawal costs up to 21 signed on-chain transactions. Is there a minimum withdrawal amount or fee? Otherwise micro-withdrawal spam on the SVM burns RC across all top witnesses at 21x.
7. svm.bank key nullification. Is this enforced in consensus code at hardfork activation, or is it an account whose authorities were manually set to a null key? If it's the latter, whoever holds the current keys can act before HF24 ships.
8. Inbound direction. This covers SVM → Steem only. Is the lock-and-mint side specified anywhere? Supply neutrality depends on both halves being equally rigorous.
I hope it will be useful for the project to answer these questions, also to generate more trust from other Steem users.
0.00 SBD,
2.57 STEEM,
2.57 SP