Prediction Market

Proof of concept: PoC

In the sendResolverBondToMarket function, the resolver bond is currently stored using: marketBond[_market].resolverBond = _amount;

This approach overwrites any existing resolver bond, which is generally acceptable as only one resolution is expected.

However, an issue arises when a market status is resetByCouncil. Here’s the problematic sequence: 1. Reset State: The council votes to reset the market, leaving the previous resolver's bond intact but not immediately returned. 2. New Proposal: A new resolver proposes a resolution, adding their bond via sendResolverBondToMarket. 3. Bond Overwrite: The resolverBond value is overwritten with the new bond, effectively discarding the previous bond value. 4. Loss of Funds: When the previous bond is sent to the disputor (to punish original resolver), the resolverBond is reset to zero, causing the new resolver to lose their bond.

To handle the situation where multiple bonds coexist during a reset, the resolver bonds should be stored incrementally and decremented appropriately when withdrawn or refunded.

Modify sendResolverBondToMarket to increment the value by the new bond amount: marketBond[_market].resolverBond = _amount.

Similarly, in sendBondFromMarketToSafeBox and issueBondsBackToResolver, decrement the resolver bond by the transferred amount instead of setting it to zero.

Trueo Team: Resolved.

Proof of concept: PoC

When the market is in the MarketStatus.ResetByCouncil state, it should wait for the secondChallengePeriod before opening for resolution to allow openEscalatedDispute. However, proposeResolution can be called immediately without waiting for the secondChallengePeriod.

The bypass of secondChallengePeriod allows a dishonest disputor to move the market status to ResolutionProposed therefore earning the resolver's bond before the resolver has a chance to escalate the issue.

Consider moving _updateStatus execution before setting councilDecisionAt = 0 .

Trueo Team: Acknowledged.

When a market is finalized and ends with _CANCELED as the winningPosition, users can trigger withdrawFromCanceledMarket to withdraw their payment tokens.

Within withdrawFromCanceledMarket, if bondSettled is not yet settled, it will trigger _settleBonds to handle reward payments and bond refunds or slashes.

However, if the market previously entered a dispute or escalation state, it will transfer the reward to the safeBoxAddress when the winningPosition is _CANCELED, regardless of whether the originalOutcomeFromResolver is equal to _CANCELED.

This will result in the resolver not receiving the deserved reward.

Only transfer reward to safeBoxAddress when winningPosition is _CANCELED and winningPosition is not equal to originalOutcomeFromResolver

Trueo Team: Resolved.

Proof of concept: PoC

When a market is partially disputed, multiple disputes can be opened in parallel. If one of those disputes concludes first (e.g., triggering a ResetByCouncil), the market transitions back to OpenForResolution, and any unclosed disputes remain in storage, still carrying prior votes.

Because those old disputes are never marked as permanently invalid, they can be reused when the market enters a new resolution flow—allowing a malicious council member to “revive” the partially-voted dispute and finalize it with minimal new votes.

In the provided example:

1. A market transitions to ResolutionProposed with a “YES” outcome.
2. Two different disputers each open a separate dispute (Dispute #1 and Dispute #2).
3. Dispute #1 closes first (for example, by a majority that sets ResetByCouncil), while Dispute #2 remains open but unresolvable at that moment due to the market status update.
4. The market then resets, returning to OpenForResolution (or even ResolutionProposed again).
5. A malicious council member can propose a new outcome, open a fresh dispute, but then re-invoke the old, unresolved Dispute #2. Because that older dispute already has partial votes recorded, the malicious user can cast a single new vote (or minimal votes) to reach a majority, effectively closing Dispute #2 and imposing its outcome—even though other council members haven’t re-voted under the new context.

Invalidate or close all existing disputes when the market transitions from SetByCouncil or ResetByCouncil back to OpenForResolution.

Trueo Team: Resolved.

Guardian Team: The new check if (_disputeIndex <= marketLastClosedDispute[_market]) revert DisputeInvalid(); is ineffective because an old dispute may have a higher index than the last closed dispute. 15

burn can be called by anyone at any market state, allowing users to burn their yes and no tokens to retrieve the deposit tokens.

This could cause issues in a scenario where the market is finalized, especially when the winning position is _CANCELED. Instead of calling withdrawFromCanceledMarket, users might choose to call burn to reclaim their deposit tokens.

This would prevent _settleBonds from being triggered, causing all bonds and rewards to remain stuck and unresolved.

Consider restricting burn so it can only be called when the market is not finalized. Additionally, make settle bonds publicly callable in cases where no token holders decide to redeem or withdraw their tokens.

Trueo Team: Resolved.

Proof of concept: PoC

When a dispute is resolved by the council and its escalation leads to a Reset result, any user with an “unclosed dispute” bond remains unable to claim it because reopenMarketForDisputes sets marketClosedForDisputes to false.

Consequently, once the market transitions to a new proposal, if it finalizes with no disputes, the dispute is never recognized as “closed” or “canceled,” preventing claimUnclosedDisputeBonds from succeeding. The disputer’s bond remains locked, and they are unable to recover their funds.

Update canDisputorClaimbackBondFromUnclosedDispute to allow bond retrieval if the market has been reset, rather than strictly requiring it to be “closed for disputes” or “finalized.” This ensures no user is stuck with an unclaimable dispute bond after the escalation reset.

Trueo Team: Resolved.

The current implementation dictates that once an escalation is decided by a token holders' vote, the market either resolves to Finalized or reverts to OpenForResolution, with no mechanism to dispute this decision.

However, according to the documentation, a third challenge window should exist, enabling any holder of 250,000 TRUE tokens to dispute the escalation result and escalate the matter to the Attesters.

The absence of this challenge window introduces a vulnerability where large TRUE token holders could manipulate the vote for financial gain, leaving other stakeholders without any recourse to contest the outcome.

Introduce a third challenge window as outlined in the documentation, ensuring that escalation decisions can be disputed and reviewed by the Attesters.

Trueo Team: Acknowledged.

The mint function enforces the yesNoTokenCap, but it only checks the supply of Yes tokens. This creates a potential issue where the supply of No tokens can exceed the cap if there is an imbalance between the total supply of Yes and No tokens.

This imbalance can occur because Yes tokens can be burned (since YesNoToken is an ERC20Burnable contract).

For example:

• yesNoTokenCap = 100
• Initial supply: Yes = 90, No = 90
• A user burns 10 Yes tokens, reducing the Yes supply to 80.
• The same user mints 20 Yes tokens, bringing the Yes supply back to 100.
• The final supply becomes: Yes = 100, No = 110, exceeding the cap.

Check that the No token supply does not exceed the yesNoTokenCap during minting.

Trueo Team: Resolved.

Inside TruthMarketManagerV2, several functions are available to manage the market's configuration that can be called by the oracle council, such as setYesNoTokenCap, setEndOfTrading, setFirstChallengePeriod, and setSecondChallengePeriod.

While setYesNoTokenCap and setEndOfTrading are currently available in the OracleCouncilV2 contract, setFirstChallengePeriod and setSecondChallengePeriod are not implemented, preventing council members from configuring those market settings.

Implement setFirstChallengePeriod and setSecondChallengePeriod inside OracleCouncilV2.

Trueo Team: Resolved.

The _getTotalOpenDisputes function is used by the addOracleCouncilMember and removeOracleCouncilMember functions in the OracleCouncil contract.

This function calculates the total open disputes by looping through all active markets and checking if each market is in the DisputeRaised status and has any open disputes. The issue is that _activeMarkets does not have a cap, meaning it could grow indefinitely.

As a result, the gas costs for calling _getTotalOpenDisputes can become excessively high, potentially exceeding the block gas limit and causing the transaction to fail.

This could effectively lock the addOracleCouncilMember and removeOracleCouncilMember functions, preventing them from being executed.

Introduce a cap on the size of _activeMarkets or consider optimizing the function to avoid iterating through markets that are in a finalized state, as they cannot return to the disputed state.

Trueo Team: Acknowledged.

Many operations inside TruthMarketManagerV2 that change the market state can be manually triggered by the owner. This is needed in cases where markets are paused, as only the owner can initiate market state transitions, including disputeMarket.

However, disputeMarket uses the onlyOracleCouncil modifier, which restricts the function to being called only by the oracle council. This is despite the function logic including a check allowing the owner to trigger disputeMarket when markets are paused.

As a result, disputeMarket cannot be manually called by the owner when markets are paused.

Consider to use onlyOracleCouncilAndOwner instead.

Trueo Team: Resolved.

Proof of concept: PoC

If stake is not called in the same block of notifyRewardAmount, depending on delay, a portion of rewards will remain unused inside the contract.

For example, at time X rewards are transferred into the contract. Then some time Y has passed before the first user stakes. However, the reward period will end at X + rewardsDuration not X + Y + rewardsDuration.

Therefore, the rewards for Y * rewardRate will remain un-distributed till the next cycle. If a new reward cycle is never started (e.g. final cycle), then any undistributed amount will remain inside the contract.

Consider defining periodFinish in the first stake that is done after notifyRewardAmount, when total deposits are zero.

Trueo Team: Acknowledged.

Council members can cast votes referencing an invalid _winningPosition, one not recognized by the market. If enough votes align on this invalid outcome, the dispute remains unresolvable.

Consequently, it remains open indefinitely, blocking certain system actions (e.g., adding or removing council members) which require all disputes to be closed.

Enforce strict _winningPosition validation in voteForDispute, reverting if _winningPosition falls outside 1 to ITruthMarket(_market).positionCount().

Trueo Team: Resolved.

The setOracleBonds function in the TruthMarketManager contract allows the owner to change the oracleBonds address. The problem is that the oracleBonds address is hardcoded into markets when they are created.

If the address is updated in the TruthMarketManager contract, active markets not yet finalized will send and account for resolve, dispute, and escalate bonds to the new address.

However, when issuing them back, the old address in the market contract will be used, which will not have the funds or have them accounted for, leading to users losing those funds.

Furthermore, any unclaimed dispute bonds will also be unclaimable because the OracleCouncil contract will fetch the new address from the TruthMarketManager contract, while these dispute bonds are stored in and accounted for in the old contract.

If an oracleBonds update is needed, ensure it is performed only when all active markets are finalized and manually handle users' unclaimed disputed bonds, as the normal functionality will not work for pending disputes before the address change.

Trueo Team: Resolved.

Guardian Team: The setOracleBonds function now verifies that all active markets have settled their bonds before an address update is allowed. However, even with this precaution, any unclaimed dispute bonds become unclaimable.

Currently, if the escalator is correct, the reward is sent to either the resolver or the disputor. This assumes that the escalator is also the resolver or disputor.

However, considering that the escalator requires a larger bond, it’s possible that the resolver or disputor does not have the required bond, and another party could step in and become the escalator. This third party should be able to receive the reward independently for a correct escalation.

Consider splitting the reward between the disputor/resolver and escalator when escalator is correct.

Trueo Team: Acknowledged.

When a market is reset following multiple active disputes, a user whose dispute is still considered “open” cannot reclaim their bond because the system only allows bond retrieval after the market is finalized.

As a result, that user remains in a state with an unclaimed (open) dispute bond, which prevents them from initiating a new dispute on a subsequent outcome proposal. This essentially locks them out of further participation in the dispute process for that market.

Enable retrieval or reusability of the bond upon a market reset for disputes that remain open. Specifically, consider allowing users to claim or “migrate” their open dispute bond once the market transitions to a reset state—rather than strictly requiring the market to be finalized.

Trueo Team: Acknowledged.

The market’s dispute and escalation mechanisms rely on the ability to deposit bonds in USDC. If USDC—being a pausable token—is paused, no new bonds can be deposited, effectively blocking any new disputes or escalations.

An attacker can exploit this by proposing a resolution in their favor just before USDC becomes paused; if the pause period extends past the challenge window, the outcome remains uncontested, leading to unjust financial gains for the attacker.

Extend dispute periods when USDC (or any payment token) is paused until transfers become possible again.

Trueo Team: Acknowledged.

In the case of a block re-org event, disputors may unknowingly have submitted disputes for what they believe to be the correct result, leading to slashing and the loss of their disputor bonds.

For example, consider the following scenario:

(1) Alice proposes an incorrect resolution.

(2) Bob disputes Alice’s resolution.

(3) A block re-org occurs and Alice’s proposal is replaced with a correct resolution.

(4) Bob’s dispute is invalid and will be punished.

Allow disputors to pass the exact position they’d like to dispute to function openDispute.

Trueo Team: Acknowledged.

If the market is disputed or escalated, it could transfer bonds back to the disputor and escalator if they are not punished. However, since the paymentToken is USDC, which has a blacklist feature, it is possible for the disputor or escalator is blacklisted when the market attempts to return the bonds.

This would cause the market state transitions to fail. The same issue could occur when attempting to send rewards to the resolver or disputor if the reward token also has a blacklist feature.

Consider using the Pull-over-Push pattern when handling bonds and rewards.

Trueo Team: Resolved.

Guardian Team: The transfer could still be blocked when sending rewards to a blacklisted address.

Proof of concept: PoC

A market can be resolved or reset by the owner directly from the TruthMarketManager contract. One instance where this will be used is, if a market is paused, only the owner can call the reset or resolve market functions instead of following the general flow through either the OracleCouncil contract or the Escalation contract.

The issue is that when called directly, the dispute or escalation processes are not fully completed as they would be in the general flow. In the dispute case, for instance, one issue would be the marketLastClosedDispute not being updated, meaning the isResolverPunished and isDisputorPunished flags remain unset, defaulting to false.

Consequently, when the market either resets or finalizes, it will attempt to send funds to the disputer’s address fetching the address from the unset marketLastClosedDispute. Since this address is not set, it would return the zero address, leading to a revert and locking up the market.

Furthermore, the marketClosedForDisputes is also not set to true as done in the general flow, meaning unclaimed disputes for the market will remain locked.

Similarly, in the escalation case, if called directly for either reset or resolve, the lack of updates to marketToEscalatedDispute will leave multiple variables such as punishment outcomes empty.

This will also cause incorrect outcomes, as the punishment outcomes will all default to false and possibly other issues.

In the current code, a direct call to reset or resolve the market will cause multiple issues, potentially locking up the market and user funds. Either modify the logic to ensure that if called directly, the dispute or escalation processes are still fully completed, or avoid calling them directly entirely.

Trueo Team: Resolved.

In the current implementation, market creation is restricted to trusted council members. However, once market creation becomes permissionless as per the documentation, it introduces the risk of abuse.

Malicious actors could create nonsensical or deliberately unresolvable markets and then submit a CANCELED resolution to claim resolver fees

To mitigate this risk consider implementing a market creation fee when market creation becomes permissionless.

Trueo Team: Acknowledged.

Within function setAmounts in the TruthMarketManager, is it not validated that escalatorBondAmount is the largest bond amount relative to the disputer and resolver bond amounts.

According to documentation, "Every escalation must come at an increased cost to that of the previous, so that the protocol may potentially slash the bonds in compensation for the expended resources."

Validate the bonds amounts to be according to documentation.

Trueo Team: Acknowledged.

Currently, the createMarket function lacks validation for several input fields, which could lead to the creation of invalid or exploitable markets.

Specifically:

• rewardToken should be a non-zero address
• rewardAmount should not be zero and have a minimum amount
• yesNoTokenCap should be of a reasonable amount

Implement validations for the input fields described above.

Trueo Team: Acknowledged.

The mint function is exposed to a griefing attack where an attacker can frontrun a legitimate user's transaction by minting the exact remaining tokens under the yesNoTokenCap. This causes the legitimate user's transaction to revert due to the TokenCapExceeded() check.

The attacker can then backrun with a burn transaction, reclaiming the payment tokens spent during the frontrun. Although this attack requires the attacker to have sufficient capital to mint the remaining tokens, it effectively disrupts legitimate users.

Introduce a mechanism to limit how quickly addresses can mint, or limit the maximum mint amount per transaction.

Trueo Team: Acknowledged.

Within OraclePausable, the modifier pauserOnly breaks the typically access control naming convention of onlyRole

Consider updating the modifier to onlyPauser.

Trueo Team: Acknowledged.

The Truemarket documentation states that the total supply of TRUE is 100 million. However, the current maxSupply set in the TrueToken contract is 1 billion, which contradicts the documentation.

Update the maxSupply value in the TrueToken contract to align with the documented total supply of 100 million.

Trueo Team: Acknowledged.

In the _isValidTransition function, the else block for handling transitions when the from status is ResetByCouncil is never triggered.

This is due to the behavior of getCurrentStatus, which automatically transitions the ResetByCouncil status to OpenForResolution if the current timestamp is past the second challenge period.

Furthermore, the logic in the else block is incorrect because, there is no direct transition from ResetByCouncil to OpenForResolution.

Consider removing the else block.

Trueo Team: Acknowledged.

When amount is multiplied by 10^paymentTokenDecimals and then divided by 10^tokenDecimals, any amount smaller than the ratio 10^(tokenDecimals - paymentTokenDecimals) is rounded down to 0.

As a result, users may burn their YES/NO tokens but receive zero payment tokens, causing them to lose tokens unintentionally.

Require paymentTokenAmount > 0 before executing the burn, it's also recommended to only burn a multiple of 10^(tokenDecimals - paymentTokenDecimals) from the users token avoiding loss from their end due to truncation.

Trueo Team: Acknowledged.

When removeOracleCouncilMember is called, it moves councilMemberAddress at councilMemberCount to councilMemberIndex[_councilMember], but the councilMemberAddress at councilMemberCount is not cleared.

When removing a council member, consider clearing councilMemberAddress at councilMemberCount.

Trueo Team: Acknowledged.

In the setAddresses function, the AddressesUpdated event is emitted with a specific parameter order. However, the actual arguments passed do not match this order.

This causes misalignment between the event’s named parameters and the actual addresses being updated, leading to potential confusion or incorrect off-chain tracking.

Reorder the arguments in the emit AddressesUpdated(...) call to match the event’s parameter list or update the event definition to align with the actual argument order.

Trueo Team: Acknowledged.

When removePauserAddress is called, it moves pauserAddress at pauserCount to pauserIndex[_pauserAddress], but the pauserAddress at pauserCount is not cleared.

When a pauser is removed, consider clearing pauserAddress at pauserCount

Trueo Team: Acknowledged.

The TruthMarketManager contract uses the onlyOracleCouncilAndOwner modifier on the pause and unpause functions, allowing the owner and OracleCouncil address to call them.

However, the OracleCouncil contract does not implement the functionality to invoke these functions, preventing it from pausing or unpausing the TruthMarketManager contract as intended.

Implement the necessary functionality in the OracleCouncil contract to allow it to call the pause and unpause functions in the TruthMarketManager contract.

Trueo Team: Acknowledged.

When a market is newly created, it ensures that _endOfTrading is greater than minimumTradingDuration. However, when setEndOfTrading is called, there is no validation, making it possible to configure the market with an endOfTrading that is less than minimumTradingDuration.

Add the same validation inside setEndOfTrading.

Trueo Team: Acknowledged.

In OraclePausable, setPaused can be called by owner() which is the TruthMarketManagerV2 contract. However, this function is not implemented in TruthMarketManagerV2.

Consider implementing setPaused in TruthMarketManagerV2.

Trueo Team: Acknowledged.

When a new dispute is opened through the openEscalatedDispute function, the dispute’s createdAt is set to block.timestamp.

However, this value is overwritten when the setEscalationProposalId function is called, which sets createdAt to block.timestamp again. As a result, the createdAt variable will not accurately reflect the original time the dispute was created.

Ensure that the createdAt variable is only set once when the dispute is initially opened through the openEscalatedDispute.

Trueo Team: Acknowledged.

In the function resolveEscalatedDispute, the input arguments should be validated to avoid any illogical state.

Notably:

• _isResultReset and _isResultAccept should never be equal
• Punish arguments (x3) should never all be true.

Additionally, isEscalatedDisputorPunished should be set to false when _isResultAccept is true - as the escalator should never be punished if the escalation was accepted.

Similarly, isCouncilDisputorPunished should be set to false when _isResultAccept is false. Punish arguments should be validated to ensure they do not conflict with this.

Add the recommended validations to resolveEscalatedDispute.

Trueo Team: Acknowledged.

Users can open a dispute for a market once a resolution is proposed by calling the openDispute function with the market address and _disputeString as parameters. The _disputeString allows users to explain the reason for the dispute and present evidence.

However, with no restrictions or validations on the _disputeString, malicious users could exploit this feature to post malicious or misleading links. If these links are displayed on the front end, they could lead unsuspecting users to phishing sites or other malicious content.

Additionally, since only one dispute can be processed and rewarded or punished, the cost of such an attack is limited to the disputer bond amount. A malicious actor could open multiple disputes with different dispute strings to increase the chances of unsuspecting users clicking on the harmful links.

Ensure that disputes displayed on the front end are validated to prevent malicious content from being presented to users.

Trueo Team: Acknowledged.

When the council decides to reset a market with _returnToOpenForResolution == true, market status is immediately set to OpenForResolution.

As a result, the decision cannot be disputed by escalation which prevents a confident resolver from disputing the decision, so as not to lose the potential reward.

Consider if this is expected. Otherwise, allow for dispute by escalation, even if the council's decision is to reset and open market for resolution.

Trueo Team: Acknowledged.

The addOracleCouncilMember function incorrectly implements the check for the maximum number of council members, allowing the limit to be exceeded by one.

The condition:

if (councilMemberCount > marketManager.maxOracleCouncilMembers()) revert MaxOracleCouncilMembersExceeded(); does not prevent adding an 11th member when the maximum allowed is 10.

This happens because the check is only triggered after the count exceeds the limit, rather than when it reaches the limit.

Update the condition to ensure the council member count does not exceed the maximum:

if (councilMemberCount = marketManager.maxOracleCouncilMembers()) revert MaxOracleCouncilMembersExceeded();

Trueo Team: Acknowledged.