PUN Classic (v1), PUN 2 and Bolt are in maintenance mode. PUN 2 will support Unity 2019 to 2022, but no new features will be added. Of course all your PUN & Bolt projects will continue to work and run with the known performance in the future. For any upcoming or new projects: please switch to Photon Fusion or Quantum.

Reliability in Bolt

The reliability of all different transfer mechanics in Bolt can be a bit daunting to get to grasps with. Here we'll go through how it works for all different types of data you can send in Bolt.


Let's start with the most complicated one: Properties on states. When you change the value of a property on a state, say: state.health = 50; Bolt will detect this and mark the property for replication (i.e. sending it to everyone else that's connected to the game).

If the packet that contains the change of a property is lost, Bolt will detect this and mark the value to be re-sent. However since Bolt only sends a packet every N frames, if you do two changes to the same property in quick succession only the latest value will be seen by the remotes (i.e. other players connected to the game).

Bolt also does not guarantee any ordering when it sends properties, which means that if you change two properties right after one another like this:


state.health = 50;
state.ammo = 10;

...there is no guarantee that health will arrive before ammo, they might not even arrive in the same packet.

The only one guarantee Bolt provides when dealing with state properties is: The latest value of a property will eventually arrive on all connected remotes.


Events in Bolt can be sent in two different ways: Unreliable and Reliable Ordered. Events sent as Unreliable are not guaranteed to arrive at all and the ones that do arrive, in most of the cases (99.9%), will be in the same order they were sent. Events sent as Reliable Ordered are guaranteed to arrive, and always in the exact same order.

Global events can be both Reliable Ordered and Unreliable. Entity events can only be Unreliable.


Commands are sent in a best-effort manner. They are completely unreliable, but are sent with some redundancy, meaning that each command will be sent in several packets to give it a higher chance of arriving. Command ordering however is reliable: There may be lost Commands, but the ones that arrive will always be delivered in the order they were queued with the QueueInput() call.

If the Owner of an entity has not received a Command from a Controller, it can use the MissingCommand() callback to detect this, and potentially create a default action.

Protocol Tokens

Classes that inherit from IProtocolToken can be passed to several different methods in Bolt, for example: BoltNetwork.Instantiate, BoltNetwork.Connect, BoltEntity.AssignControl. Protocol tokens passed like this are guaranteed to always arrive when the action they were passed in to happens on remotes (other connected players).

If you create a ProtocolToken property on a State it will be subject to the same conditions as any other property types.

Back to top