clarify nonce wording

adr/adr2002 - nonces for bridging.md

@@ -14,9 +14,9 @@
 
 ## Context
 
-There is a need for nonces to keep track of when data is created on layer.  The problem is: should you allow older signed data to be pushed after newer signed data?  If you do, you can give optionality to bridge users for going back in time (e.g. a price feed). 
+There is a need to keep track of when data is created on layer.  The problem is: should you allow older signed data to be pushed after newer signed data?  If you do, you can give optionality to bridge users for going back in time (e.g. a price feed). 
 
-For layer include a timestamp as one of the parameters used in bridge validator set updates in place of a nonce. This is different than the original blobstream which also had a universal nonce. Each time the bridge validator set changes, all validators sign a hash of multiple parameters, including the new validator set timestamp. The bridge contract enforces that this timestamp is greater than the previous one. The bridge contract also uses this timestamp to determine whether a given validator set record is stale by comparing the timestamp to the Layer unbonding period. We use the strictly increasing timestamp rule to prevent the bridge from accepting old validator set attestations, and it also allows the bridge to save gas costs by skipping blocks. In addition, we use the age of a validator set attestation to determine whether that validator set's tokens are still locked as stakes and thus eligible for slashing.
+The original blobstream had a universal nonce for enforcing when each attestation occured. In place of a nonce, Layer includes a timestamp as one of the parameters used in bridge validator set updates. Each time the bridge validator set changes, all validators sign a hash of multiple parameters, including the new validator set timestamp. The bridge contract enforces that this timestamp is greater than the previous one. The bridge contract also uses this timestamp to determine whether a given validator set record is stale by comparing the timestamp to the Layer unbonding period. We use the strictly increasing timestamp rule to prevent the bridge from accepting old validator set attestations, and it also allows the bridge to save gas costs by skipping blocks.
 
 We do not include a nonce for oracle data attestations. We use attestation timestamps and report timestamps instead to determine the ages of these, respectively. We do not necessarily need every single oracle attestation to be bridged to every single user chain, and they do not have to be bridged in the order in which they were created. We include `nextTimestamp` and `previousTimestamp` in each oracle attestation to determine ordering properties of oracle reports.