Well, the compiled code is available, and if they provide the source code, you can verify that it compiles to the code on chain (or, you can analyze the code on chain without the source code of the contract, but that is harder).<p>The source code for the contract can be made to have a proof of correctness in it, or, as it is probably not all that long, if you look at the source code long enough you can be sufficiently convinced that it runs how you expect it to.<p>Regarding the problems with turing completeness, any transaction is guaranteed to finish within a particular number of steps, because the transaction includes an amount of &quot;gas&quot;, which puts a limit to how many steps the contract will run. If it runs out of gas before finishing, all the changes in the state are reverted (but the person still pays the gas cost). If it finishes, then the extra &quot;gas&quot; is returned. (the transaction specifies some &quot;gas cost&quot;, which is how much ether per gas or gas per ether (idr) , and some amount of ether, which is the max cost the transaction is allowed to take. There aren&#x27;t &quot;gas balances&quot;, any &quot;gas&quot; that is transferred just is ether at the end. Its just a unit of how much computation, and the gas price is how much they are willing to pay per amount of computation. I feel like I didn&#x27;t explain this well...)<p>Checking that the contracts were run correctly is done by anyone verifying the block which contains the contract call. If the miner runs the contract incorrectly, then the people verifying the block will not accept the block as valid, so people won&#x27;t mine on the block, so it wont end up in the main chain, so the miner will not receive anything from mining the block, and what happens in the wrong execution wont effect anything.<p>I&#x27;m not sure if this explanation has been very clear, but I hope it has been clear enough. I can try again if it isn&#x27;t though.