LayerZero Composer

When the getPredictionResolution function is called with an empty encodedPredictedOutcomes array, the function skips the loop and returns (true, NO_ERROR, true). This contradicts validatePredictionMarkets, which reverts on zero markets. If any on-chain consumer relies solely on getPredictionResolution, an empty parlay incorrectly appears as a resolved success.

Furthermore, there is no maximum length validation as exists in the validatePredictionMarkets function.

Consider mirroring the validation in getPredictionResolution: require the array to be non-empty and within configured bounds, or call validatePredictionMarkets internally and propagate its result.

The prediction market side resolver does not enforce immutability of a market resolution once marked settled. A later cross-chain message with assertedTruthfully=true can set resolvedToYes to a different value, flipping an already-settled market outcome. While the configured UMA-side contract should only send one truthful resolution per market, any misconfiguration, replay from a different authorized remote bridge, or future code changes could toggle outcomes and corrupt payouts.

Consider adding validation to assert that market.settled is not already true in the marketResolvedCallback function.

Neither the validation nor resolution functions reject duplicate marketIds in the encoded PredictedOutcome[]. This can yield ambiguous parlay semantics, allow overcounting a single market multiple times.

Track seen marketIds within the loop and reject duplicated entries. Alternatively, deduplicate before processing and enforce a strict normalized format.

In the PredictionMarketLZResolverUmaSide resolver, the assertionResolvedCallback function always clears all mappings related to the marketId, which allows for subsequent submissions to the same market.

This is important to allow untruthful assertions to be re-submitted, however also allows assertions to be submitted for markets after they have already truthfully resolved.

To avoid any unexpected behavior, consider only clearing the mappings when the assertion was resolved non-truthfully so that the already truthfully resolved market cannot be re-submitted.

In the PredictionMarketUmaResolver contract there is no path to update the config values after it has been set on construction.

In case the configurations ought to be changed after deployment a new PredictionMarketUmaResolver instance will have to be deployed.

Be aware of this limitation for the PredictionMarketUmaResolver address and consider if a configuration setter should be added.

The UMA resolvers cannot validate the marketId correctness since they require resolution through the UMA oracle and the marketId is based upon the keccak256(abi.encodePacked(claim, ":", endTime)) result.

As a result, matched predictions can pass the _createPrediction function even though they might use an incorrect marketId. Currently there is no pathway for users to be able to escape their matched prediction of an incorrect marketId was used, meaning that if no other market in the parlay resolves to false, and the invalid marketId remains unresolved the collateral for these users would be trapped.

Ensure that the marketId used to create orders from the offchain system is always correct and be aware of this risk.

In the UMA side LZ Resolver the marketAsserter mapping is used to store the assertor of the marketId assertion, however this value is never used nor exposed to be read.

Consider removing the marketAsserter mapping.