A newly reported security issue in Predinex Stellar’s prediction-market contract could allow a specially designed token to re-enter the betting process before the contract finishes recording a user’s position, potentially leaving the tokens held by the contract out of sync with its internal pool accounting.
The finding was opened on September 27 against Predinex’s Soroban smart contract and centers on the ordering of operations inside its place_bet function. The GitHub issue does not demonstrate an active exploit, stolen funds or a known token that can currently trigger the condition.
Instead, it identifies a latent reentrancy path created because the contract makes two external token calls before persisting several of the state changes that describe the bet.
According to the report, place_bet first updates a wallet rate-limit counter. It then calls the configured token contract to transfer the bettor’s tokens into Predinex and, when a fee applies, performs another token transfer to the fee recipient.
Only after those external calls does the contract update the pool totals, outcome totals and the user’s betting position.
The concern is what would happen if a token’s transfer implementation invoked Predinex again before returning control to the original call. The nested bet could observe the old pool and user state because the outer call has not yet persisted its updates. When the nested call returns, the original execution could then write the state values it calculated earlier, potentially overwriting changes made during the re-entrant execution.
In that scenario, additional tokens could be sitting inside the contract while some of the corresponding stake is missing from the accounting used to calculate pool totals and positions.
No Callback-Capable SEP-41 Token Has Been Identified
There is an important limitation to the finding.
The reporter explicitly said they could not identify a standard SEP-41 token that currently re-enters another contract through its transfer function. No proof was provided showing the condition being exploited on Stellar mainnet, and there is no evidence that a Predinex user has lost money through it.
That makes the issue materially different from the Payy USDC bridge exploit, where assets visibly left a live contract, or the MultiversX VM exploit, where network operators had to respond after malicious state changes were already being investigated.
The closer comparison is a recently reported Heliobond vault accounting bug, another Stellar-based issue where researchers identified a potentially dangerous accounting failure without establishing that the affected code had caused losses in a live deployment.
Predinex’s issue was accepted into the Stellar Wave contribution program and assigned to developer Prozaks, with a September 30 deadline for remediation.
The response has already moved beyond assignment. An open pull request, #1261, was filed late on September 27 and proposes moving the two external token transfers until after the pool and user-position storage writes have been completed.
The patch remains unmerged at the time of review.
It currently changes the contract implementation rather than adding the callback-token test specifically requested in the original issue’s acceptance criteria. That does not mean the proposed fix is ineffective, but a dedicated adversarial test would provide stronger evidence that future changes cannot silently restore the same ordering problem.
Public Evidence Does Not Show Predinex Holding Mainnet Liquidity
The financial significance of a smart-contract vulnerability depends heavily on whether vulnerable code is actually controlling real assets.
Public Predinex materials reviewed for this article do not establish that the Stellar version is currently operating a mainnet prediction market with user liquidity.
The repository labels the project as BETA and describes its lifecycle as an initial implementation. Its roadmap still lists frontend and product work as in progress, while its contract-versioning documentation describes the initial production deployment as a Stellar testnet deployment.
The repository does contain scripts and workflow infrastructure for deploying to Stellar mainnet, so the codebase is clearly being designed with mainnet operation in mind. What is missing is a publicly identified production contract address that can be connected to current pools and real balances.
No GitHub releases were published when checked either.
That absence cannot prove there is no private or otherwise undocumented deployment. It does mean there is not enough public evidence to characterize issue #1229 as a vulnerability presently threatening a known pool of mainnet customer funds.
The distinction matters. The industry has repeatedly had to separate vulnerabilities caught during development from vulnerabilities discovered after capital was already exposed. The Cosmos recovery patch showed how much more complicated that calculation becomes once developers are trying to protect or recover assets already affected by a security problem.
The Token-Swap Risk Is Narrower Than It Initially Appears
The original report notes that Predinex’s standard betting token is fixed when the contract is initialized and cannot currently be replaced through an ordinary configuration call.
That significantly reduces the immediate version of the threat.
The codebase also does not expose an update_current_contract_wasm entry point for replacing the deployed contract binary in place. Predinex’s own migration documentation instead contemplates deploying breaking contract versions under a new contract ID and pointing the frontend toward the replacement.
In practical terms, the standard place_bet path cannot simply wake up tomorrow using a new callback-capable payment token because an administrator changed one setting.
However, the broader codebase makes the token-security question more interesting than that conclusion alone suggests.
Predinex already contains separate multi-asset market functionality. Its place_multi_asset_bet flow accepts a token from a pool’s approved-token list, transfers that token into the contract and then updates deposit and betting accounting. That path is separate from issue #1229 and has not been demonstrated to be exploitable, but it shows why secure handling of arbitrary external token contracts is relevant to the project’s architecture rather than purely hypothetical future functionality.
As Predinex expands from one configured asset toward multi-asset markets, token allowlisting and interaction ordering become part of the security boundary.
A Theoretical Bug Is Exactly When Reentrancy Should Be Fixed
It would be easy to dismiss this issue because nobody has produced a malicious token that steals money from Predinex today.
That misses the useful part of the finding.
Reentrancy defenses are most valuable before an application’s integrations become complicated. Once a prediction market supports more assets, more external contracts and more liquidity, developers have to remember every assumption previous versions made about how those external contracts behave.
The safer design is not to rely on a token behaving nicely in the first place.
Writing economically important state before giving control to an external contract follows that principle. A callback can then observe accounting that already reflects the transaction rather than an intermediate state the protocol never intended outsiders to see.
Predinex’s proposed patch moves in that direction and, if merged and adequately tested, would reduce dependence on the behavior of the payment token itself.
The bigger question is whether the same principle is applied consistently across the rest of the growing codebase, particularly the newer multi-asset paths.
For investors, users and developers, there is no evidence here of a Stellar prediction market being drained. There is instead something more mundane but still valuable: an architectural weakness identified while the public project still appears to be in an early deployment phase.
That is the cheapest point in a protocol’s life to fix it.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.