Yes, that is correct. Only the participants that have permission to the protected information on the smart contract can determine this state information. The global state information (token balances) is available to everyone to verify.

The calculated state changes are not recorded in the secure vault. Only the events (the input parameter values and the function names) are stored. The participants can replay the events in order to obtain the current state of the smart contract. Ordering of the events is important. The recording of the reference hash (the link between the smart contract and the secure vault) in the block chain determines the order.

Of course, two or more participants may send an event message at almost the same time. This will cause one to ‘win’ and get their event recorded first. With distributed systems and the latency effects you can’t do much about this, the participants have the best picture of the state when they made their decision to execute an event.

Developers need to be careful in their designs for how access to shared resource the is some way critical to the behaviour of the system to avoid race conditions. One way around this is to impose a form of control over who has write access to a critical resource.