Engineering inside BitShares Core
Aetsoft's protocol work first appeared publicly in BitShares Core: protocol fixes, node patches, and wallet features shipped to a live blockchain and accepted upstream.
Aetsoft engineers contributed to BitShares Core, the open-source protocol, and to its reference wallet. The commits were authored between 2018 and 2019, then reviewed, merged and shipped in tagged releases through 2020, including BitShares Core 4.0.0. They sit on identifiable Aetsoft addresses.
The flagship work is a set of market fee sharing corrections that shipped behind their own hardforks. That experience became part of the protocol-engineering base Aetsoft later applied to purpose-built Layer 1 networks and a production mainnet programme.
001
ContextBitShares, a public blockchain on the Graphene engine
002
EngagementA sponsored workstream on the open-source protocol and its reference wallet
003
WorkTwo market fee sharing corrections, a node stability fix and settlement UI, merged into the official repositories
What BitShares was when Aetsoft got involved
BitShares is a public blockchain built on Graphene, a high-throughput engine that keeps chain state in memory and settles blocks in a few seconds. Daniel Larimer founded it. By early 2018, when Aetsoft engineers began contributing, it was already live, holding real balances, and run by an elected set of block producers called witnesses.
Aetsoft did not build BitShares. Its engineers contributed to parts of the protocol and the reference wallet while both were in production. That boundary runs through everything below.
Changing a live chain is a different kind of engineering
On a new project, you can change anything. On a chain that already holds balances, you cannot. A protocol change has to agree with every node still running the old rules, or the network splits in two.
BitShares handles this with hardforks. A hardfork is a rule change scheduled for a future timestamp, written so that old and new nodes agree on history up to that point and follow the new rule after it. Set the timestamp or the condition wrong and you risk a chain split. So changes land behind a dated switch, with unit tests that check behaviour on both sides of the fork. That was the part Aetsoft engineers worked inside.
The reference wallet has its own version of the problem. It talks to the live API, shows balances, and must never sign a transaction the chain will reject.
Changing a live chain is a different kind of engineering
On a new project, you can change anything. On a chain that already holds balances, you cannot. A protocol change has to agree with every node still running the old rules, or the network splits in two.
BitShares handles this with hardforks. A hardfork is a rule change scheduled for a future timestamp, written so that old and new nodes agree on history up to that point and follow the new rule after it. Set the timestamp or the condition wrong and you risk a chain split. So changes land behind a dated switch, with unit tests that check behaviour on both sides of the fork. That was the part Aetsoft engineers worked inside.
The reference wallet has its own version of the problem. It talks to the live API, shows balances, and must never sign a transaction the chain will reject.
The public record shows Aetsoft engineers with commits merged into official BitShares repositories, on identifiable Aetsoft addresses, across production releases
In BitShares Core, the protocol implementation, Aetsoft engineers authored merged commits between February 2018 and July 2019. In the reference wallet, bitshares-ui, a fourth authored 54 merged commits between March and August 2019.
The contributions were submitted to the official repositories through public forks and pull requests. The BitShares maintainers reviewed and merged them, and they shipped in tagged releases including Core 4.0.0.
The flagship
Market fee sharing
at the protocol level
Market fee sharing lets a referral programme earn a share of the trading fees generated by the users it brings in. On an exchange chain, that is a real economic primitive. It changes how fees move through the matching engine, so it lives in the consensus layer itself, alongside order matching.
The feature reached BitShares as BSIP-43, a protocol improvement proposal, and shipped behind a hardfork. An Aetsoft engineer authored the protocol corrections that followed. One fixed a check that was too strict and would have blocked valid fee sharing. It introduced its own hardfork, CORE_1774, so the correction switched on cleanly across a network that had to agree on the timing. A second extended fee sharing to force-settlement orders behind hardfork CORE_1780, with 189 lines of settlement tests. A third moved a reward-percent check out of the validator and into the evaluator, where the chain actually applies it.
Each of these touches db_market.cpp, the file that runs order matching and settlement. Each ships with tests that assert the behaviour before and after the fork. This is the quiet core of protocol work. The hard part is not the feature. It is making the feature safe to switch on across a running network.
These corrections shipped in BitShares Core 4.0.0 and remain in the codebase.
The reference wallet, kept separate
The reference wallet is where users met BitShares. It sits above the protocol, a separate layer, and we keep the two apart on purpose.
An Aetsoft engineer worked on the wallet's settlement experience across 2019: the remaining-settlement-volume display, the settle modal, and the order forms (issue #2602). Fifty-four of those commits are in the official bitshares-ui history.
The Core and wallet work converged on the same settlement flow. One engineer corrected it inside the matching engine; another made it legible in the wallet. Same feature area, two layers, one team.
The decisions that shaped the work
Protocol constraint
A consensus rule cannot change at once across independently run nodes.
A change has to live in the public network codebase to ship
Engineering response
Place each corrected behaviour behind a scheduled hardfork (CORE_1774, CORE_1780). Submit through upstream pull requests and maintainer review.
Why it mattered
Upgraded nodes activate the same rule at the same point, so the network does not split. Accepted work reaches official releases and stays verifiable beyond any one engagement.
Keeping the node up,
and the API honest
A witness node that crashes stops producing blocks. In 2018, running several witness nodes on one machine could trigger a segmentation fault, reported as issue #377.
An Aetsoft engineer fixed it. The fix merged into Core and shipped in the 2.0.181105 release. It is the kind of change nobody notices, which is the point. A block producer that stays up.
Aetsoft engineers worked on the node's data path in the same period. One change stopped the API from serving a cached account object that could drift out of sync with chain state, a subtle correctness bug reported as issue #151. Another fixed broken HTTP headers in the Elasticsearch plugin, which feeds account history to explorers and exchanges. A later change added unit tests for two signer-lookup calls, get_signed_transaction_signers and get_key_references, the calls a wallet uses to work out who must sign a transaction.
That is the difference between a protocol that runs and one that limps.
BitShares runs on Graphene. So does VPLedger, the Layer 1 blockchain Aetsoft designed and built a few years later. The engine was familiar because Aetsoft engineers had already worked inside it at the protocol level, on the matching engine, the hardfork mechanism, and the node.
Three lessons carried across. Protocol rules are economic decisions: fee sharing taught that a fee is a consensus rule with winners and losers, and it belongs behind a fork. Changing a live chain is a scheduling problem as much as a coding problem. That is why VPLedger puts configurable parameters behind referendum instead of hard-coding them. And the protocol and the wallet are separate disciplines that both have to be right. Aetsoft built VPLedger with that separation from the start.
The technologies differ across the three. VPLedger shares the Graphene engine; a later EVM Layer 1 programme used leaderless BFT consensus, threshold cryptography and on-chain validator elections instead. What repeats is the discipline. A protocol rule is an economic decision, and a change to a live chain has to be tested across activation boundaries before it switches on.
Results
The market fee sharing corrections activated through hardforks CORE_1774 and CORE_1780 and are still in the codebase. The witness-node fix shipped in the 2.0 release line, and the settlement features remain in the reference wallet. The record is public, authored on Aetsoft addresses, and accepted upstream.
“Working with the Aetsoft development team over the past year yielded increased deliverables to the BitShares Core protocol. Team fluent in blockchain design principles and able to deliver novel solutions.”
— Ryan R. Fox, Linkedin. Development Coordinator, BitShares Core Team, 2017-2019.
Frequently asked questions about BitShares
-
Did Aetsoft build BitShares?
No. BitShares was founded by Daniel Larimer and built by a wider community. Aetsoft engineers contributed to parts of the BitShares Core protocol and the reference wallet, with commits authored in 2018 and 2019 and merged into the official repositories, then shipped in releases through 2020.
-
What did Aetsoft contribute to BitShares Core?
Aetsoft engineers authored merged commits on the protocol and its reference wallet. The protocol work included market fee sharing corrections behind two hardforks, a witness-node stability fix, and node and API fixes. The wallet work covered settlement features. Most of it shipped in production releases including BitShares Core 4.0.0.
-
Is the contribution verifiable?
Yes. The commits are public in the bitshares/bitshares-core and bitshares/bitshares-ui repositories, authored on Aetsoft addresses and accepted through pull requests. BSIP-43 (Market Fee Sharing) is a public, Installed protocol proposal.
-
How does the BitShares work relate to VPLedger?
Both run on the Graphene engine. The protocol experience from BitShares, in particular fee logic, hardforks and node behaviour, informed the design of VPLedger, a Layer 1 blockchain Aetsoft built from the ground up.
If your network has something specific to guarantee at the protocol level, tell us what it is and we will tell you what it means in the consensus rules.
