> I think this is very inaccurate.
Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit team, and the $200M multi-sig bug still got through. If the top-tier team and process failed, it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug. This is invariant on the phase of development.
Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.
> But there are numerous smart contracts that have not been found to be vulnerable.
Sorry, but unexploited is not unexploitable. Many/most of these contracts are probably unexploitable, but the problem is that we can't be sure. To me, smart contract construction on the EVM/Solidity is closer to a "rolling your own crypto" grade problem, which is something that after years of massive exploits we've all agreed that you do not ever do it, vs building a webapp. Long term as tooling + approaches + standards + the language itself mature, it'll come closer to "backend programming at a hedge fund/bank" where it's doable but you need to be responsible.