diff --git a/pubsub/README.md b/pubsub/README.md
index c8879ca..f66990d 100644
--- a/pubsub/README.md
+++ b/pubsub/README.md
@@ -76,15 +76,15 @@ done to allow content to be routed through a swarm of pubsubbing peers.
 The `data` field is an opaque blob of data, it can contain any data that the
 publisher wants it to.
 
-The `seqno` field is a linearly increasing number that is unique among messages
-originating from each given peer. No two messages on a pubsub topic from the
-same peer should have the same `seqno` value, however messages from different
-peers may have the same sequence number, so this number alone cannot be used to
-address messages. (Notably the 'timecache' in use by the floodsub
-implementation contains a `message_id`, which is constructed from the
-concatenation of the `seqno` and the `from` fields. This `message_id` is then
-unique among messages. It was also proposed in
-[#116](https://github.com/libp2p/specs/issues/116) to use a `message_hash`,
+The `seqno` field is a 64-bit big-endian uint that is a linearly increasing
+number that is unique among messages originating from each given peer. No two
+messages on a pubsub topic from the same peer should have the same `seqno`
+value, however messages from different peers may have the same sequence number,
+so this number alone cannot be used to address messages. (Notably the
+'timecache' in use by the floodsub implementation contains a `message_id`,
+which is constructed from the concatenation of the `seqno` and the `from`
+fields. This `message_id` is then unique among messages. It was also proposed
+in [#116](https://github.com/libp2p/specs/issues/116) to use a `message_hash`,
 however, it was noted: "a potential caveat with using hashes instead of seqnos:
 the peer won't be able to send identical messages (e.g. keepalives) within the
 timecache interval, as they will get rejected as duplicates."