# OstiumTrading::updateOpenLimitOrder() Makes Unnecessary Field Updates Low/Info · Three Sigma · RWA perpetuals DEX · 19th February, 2024 Finding 3S-OS-N12 of the Ostium security review. - Protocol: https://www.ostium.com/ - Report: /reports/ostium - Source: https://cdn.sanity.io/files/qoqld077/production/a95b9c69e0f65d1d6b0e649f0d62a362358ca8ce.pdf --- ### Description In OstiumTrading::updateOpenLimitOrder(), unnecessary fields of the OpenLimitOrder struct are updated. Specifically, the createdAt field is set, despite its intended immutability after creation, and the lastUpdated field is also updated. Subsequently, this object is passed to OstiumTradingStorage::updateOpenLimitOrder(), where lastUpdated is reassigned to the current block. However, the createdAt field remains unaltered as intended. ### Recommendation Do the following changes in OstiumTrading::updateOpenLimitOrder(): ```solidity - uint32 b = ChainUtils.getBlockNumber().toUint32(); o.targetPrice = price; o.tp = tp; o.sl = sl; - o.createdAt = b; - o.lastUpdated = b; ``` ### Status Addressed in [#d825181](https://github.com/0xOstium/smart-contracts-threeSigma/pull/58/commits/d825181bfe52ece4d8fdbc967d4e3679d294809b). --- Related findings: - [`treasury.updateYieldsFromLiquidatedLrts()` updates the yield in the current chain, but collateral may be in the other chain](https://0xsimao.com/findings/autonomint-yields-lrts-yield-collateral): Autonomint - [`MultiplierContract::proposeMultipleUpdates()` updates `maxLevel` before executing the update](https://0xsimao.com/findings/blast-ido-pools-multiplier-propose-multiple-executing): Blast IDO Pools - [reduceOnly limit order update does not take into account that a new amm may be selected, which may lead to loss of funds](https://0xsimao.com/findings/nftperp-i-reduce-account-amm-selected): Nftperp Exchange - [`TradingLimits::update()` incorrectly only rounds up when `deltaFlowUnits` becomes 0, which will silently increase trading limits](https://0xsimao.com/findings/mento-limits-delta-flow-becomes): Mento