Does the omnichain design imply added trust assumptions (relative to a single-chain design)?

Yes and no.

Yes, in that Imua as a separate network will mean that all the operations of restaking, withdrawal, slashing etc. will be dependent on the correct operation of the Imua protocol. If Imua halts, then related operations will not work until the network recovers. However, no user assets are at risk since the assets stay in the client chain (e.g. BTC, ETH, SOL, etc) and Imua doesn’t have permission to transfer assets.

To mitigate the risk of the new trust assumption, Imua uses the industry-proven Cosmos SDK and Tendermint consensus mechanism for the chain infrastructure and will conduct extended auditing to minimize code-related risks. On protocol security, the network will be bootstrapped using restaked native tokens from the initial L1 chains that Imua supports, which provides the system with a great token-economic security from the very beginning.

No, in that since Imua is built as a separate network, then the connection between Imua and client chains can be implemented using specialized Zero-Knowledge (ZK) bridging primitives that are as trustless as the Imua network itself. The reading of restaked assets in client chains by Imua can be done by a ZK light-client based bridge, which is fully trustless and most secure. The control of restaked assets in the client chain is done by Imua sending transactions signed collectively by Imua validators using a Threshold Signature Scheme (TSS), an efficient MPC protocol. These bridging operations are as trustless as the Imua network, so as long as Imua network is secure, the bridge is secure. No additional trust assumption is relied on third-party bridge solutions.