Aster is a “decentralized” perpetual futures exchange that is in reality centralized and controlled by the team. This is part of a larger discussion of faux-decentralized perpetual futures exchanges. But Aster also rhymes a bit with some old Binance problems that ended in closures and shutdowns a few years ago.
Aster lives, largely, on the BNB Smart Chain. This blockchain itself has a storied history of Binance exercising something like total independent control over user funds. So the 0th argument here that Aster is centralized is that Binance has previously exercised a privileged position to freeze user funds and block perfectly-valid private keys from working on on BNB Smart Chain. Binance claims those actions were taken in response to hacks to safeguard user funds. Sure, maybe, whatever.
That does mean, of course, that everything on BNB Smart Chain lives under the cloud of Binance deciding some action is not in the best interest of user fund safety and unilaterally blocking whatever Binance chooses. That argument is true as far as it goes. But it is also reductive. We are not simply claiming Aster is centralized because Binance supports the platform and Binance controls BNB Smart Chain and BNB Smart Chain contains this code:
// This is introduced because of the Tendermint IAVL Merkle Proof verification exploitation.
var NanoBlackList = []common.Address{
common.HexToAddress("0x489A8756C18C0b8B24EC2a2b9FF3D4d447F79BEc"),
common.HexToAddress("0xFd6042Df3D74ce9959922FeC559d7995F3933c55"),
// Test Account
common.HexToAddress("0xdb789Eb5BDb4E559beD199B8b82dED94e1d056C9"),
}
So let us start with the Vault contract that holds a lot of the funds inside Aster. This is an upgradeable proxy contract configured in such a way that the team can take all the money. And not only is this true but it is even acknowledged, in writing, in an audit of the platform. That narrative here is roughly that in the initial design a single address could steal all the money in the vault. Then an auditor noticed that and the team committed to move to a multisig. This is in writing in an audit provided by the Aster team itself on their own website. That is pretty conclusive proof:
Next we are going to run through a litany of controls the team can use to steer the platform. And then we are going to discuss how the team, and the team alone, can use those controls to expropriate user assets. None of this requires deviation from the expected functionality of the system. Yes, these actions would constitute theft and therefore are not consistent with the team’s stated intent for the platform. But bank executives do not write “so we can steal the money” on the application under “why do you want this bank charter?” What matters is that all of these “attacks” can be accomplished using levers of control that were consciously built into Aster.
And before anyone says “but the DEX has decentralized governance” you need to know that there is a plan for future decentralized governance but as of now it is as described above:
So there is some kind of administrator and it is not a DAO. So we can now discuss the admin’s powers.
First up the administrator can pause and unpause the system. This means, in a very general sense, they never feel any time pressure when it comes to siphoning out funds. The pause button means coordination and timing and synchronization are all easy.
The team also has the ability to adjust a range of parameters including fees and open interest limits dynamically. That means they can charge users higher fees than those users expected, remove contracts and generally can force liquidations and similar by deleveraging the system in ways users cannot anticipate.
And the team is also able to change the pricing sources used to run the exchange. It is then fair to ask if we routinely see the team using this admin interface to do these sorts of things? Yes. Here is a single EOA — a non-automated, off-chain-controlled, human operated admin address — sending in config updates continually:
The “Batch Update…” calls generate long lists of trading configuration updates like these:
Then the “Execute Tp Sl or Liq” calls yield changes like:
And now, just to tighten this up, let us quickly explore how these admin controls are implemented. Not because it is complicated — but instead because it is so simple and easy to see. Here are a number of TradingConfig controls:
function setTradingSwitches(
bool limitOrder, bool executeLimitOrder, bool marketTrade,
bool userCloseTrade, bool tpSlCloseTrade, bool liquidateTradeSwitch,
bool predictBet, bool predictSettle
) external override {
LibAccessControlEnumerable.checkRole(Constants.MONITOR_ROLE);
uint tradeSwitches = 0;
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.LIMIT_ORDER), limitOrder);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.EXECUTE_LIMIT_ORDER), executeLimitOrder);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.MARKET_TRADING), marketTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.USER_CLOSE_TRADING), userCloseTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.TP_SL_CLOSE_TRADING), tpSlCloseTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.LIQUIDATE_TRADING), liquidateTradeSwitch);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.PREDICTION_BET), predictBet);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.PREDICTION_SETTLE), predictSettle);
LibTradingConfig.setTradingSwitches(uint16(tradeSwitches));
}
function setExecutionFeeUsd(uint256 executionFeeUsd) external override {
LibAccessControlEnumerable.checkRole(Constants.ADMIN_ROLE);
LibTradingConfig.setExecutionFeeUsd(executionFeeUsd);
}
…
function setMaxTpRatioForLeverage(address pairBase, MaxTpRatioForLeverage[] calldata maxTpRatios) external override {
LibAccessControlEnumerable.checkRole(Constants.PAIR_OPERATOR_ROLE);
require(pairBase != address(0) && IPairsManager(address(this)).getPairForTrading(pairBase).base != address(0), "TradingConfigFacet: pair does not exist");
LibTradingConfig.setMaxTpRatioForLeverage(pairBase, maxTpRatios);
}
You can see at the beginning of each function it calls checkRole(SOME_ROLE). There is one control each for the MONITOR_, ADMIN_ and OPERATOR_ roles. There are a few different admin roles here and some associated machinery to administer them that we are not going to bother with here.
The point is simply that there are privileged administrators here. And yes the system may largely rely on multisigs so many of these controls require a few EOAs to sign to make a change. But this is exactly the same problem highlighted in writing in an audit dated September 2024 referenced above. The system as designed, as built, as deployed and as it runs in the real world is as centralized as any traditional financial business in which several managers must sign off changes.
So, just like Hyperliquid, without even worrying about whether the off-chain portions of the system are run honestly in good times, the team can force the system portions to pay out all the money to favoured accounts on-chain.
How might that work? For example, the team can redirect pricing sources to oracles the team controls and then ensure team-affiliated positions collect all the money. The team similarly has sufficient control over funding rate levels and leverage limits and various liquidation-related parameters to harvest deposits over time.
Does that sound a little complex and marginally contrived? Did you forget the part where the team could simply take a bunch of users’ assets and their auditor noticed and they admitted it and put that audit on the website anyway? Every exploit is more complex than that! The simplest exploit described here is “they open the till to remove the money” and then it gets more complicated. And the team has a similar degree of control over the Aster USDF stablecoin that is also part of the platform with full freeze-and-seize powers. And yes another audit also notes some of these problems.
And The Code? Smells like BNB Beacon Chain
We quote the code above at length. But those snippets come mainly from blockchain explorers. These are not the best place for code — seeing history is difficult — and of course blockchain explorers have no way to host non-smart-contract code. Aster has other components so…what gives?
The official links do not point to code:
Even the audits point to somewhat random locations:
That github.com/astherus-contract repo has some code but it is not recent:
There is a different github.com/asterdexcom repo with some of the smart contract code and more recent activity, but not much else:
If you go look at the commit history from some of these it is clear these are the development repos and the team consists entirely of pseudonyms like alex-degen and cody-z and mark-c. So it looks like this ridiculous BS all over again:
That was the now-shuttered BNB Beacon Chain and the team admitting the system was closed-source long long after they’d publicly claimed otherwise. We had a lot of public back-and-forth with V and zoro in which they seemed to confess quite often.
Back then, late 2022/early 2023, they published fresh docs and code which effectively admitted the whole thing was a sham. Eventually it was all shut down. Oh and there was lots of unbacked collateral in the mix then too which got BUSD shut down.
If it turned out cody-z was zorobytes that would probably shock precisely 0 people. After all, one of BNB Beacon Chain’s original purposes was to provide a high-throughput decentralized trading platform. Like Aster. Really. This is from mid 2022:
Following our comments the team publicly admitted writing new code and docs. They admitted, publicly and in writing, that this was in response to our questions about what they had long claimed was an open system:
A range of issues back then were, um, left to be fixed in the future:
Instead of doing what was promised and sorting all the issues, BNB Beacon Chain was shut down before the data was fully clarified. Oh, and back then they also promised future decentralization:
BNB Beacon Chain’s aspirational DEX aped many popular DeFi products from the time. And the aspirational decentralization looked a lot like, well, many things (hint: including Aster). But it was always a centralized, partially-closed-source, system with weird features and behaviours. Roughly: it was a sham, BUSD was violently cut down by NYDFS, and eventually the whole BNB Beacon DEX thing got taken offline. Aster now appears to rhyme with much of that steaming pile.
So?
Good luck calling it Aster this time and aping Hyperliquid instead of whatever 2021/2022 DEX you all liked so much last time.
Previously the BNB Chain team incorrectly described our questions as assertions and generally made a hash of clarifying it was all always fine:
“Your thing does X when I run it. Can you explain?” is a statement of fact followed by a question. Consider the above to be our questions. As last time you published fresh code and docs and then linked them in your answers to imply we had not read properly when in fact your work was faulty…you’ll excuse us for wanting to do this in public with timestamps.
As we have often explained: this blog specializes in predictions about the past.
Aster: A Fake-D DEX was originally published in ChainArgos on Medium, where people are continuing the conversation by highlighting and responding to this story.
