docs(vigilantes): remove speculative incentive descriptions (#437)

Author: kkkk666

docs/guides/overview/babylon_genesis/architecture/vigilantes/submitter.mdx

@@ -37,9 +37,6 @@ To avoid abuse of `OP_RETURN`, the data size carried in `OP_RETURN` is limited t
 A raw checkpoint consists of `epoch_num` (8 bytes), `last_commit_hash` (32 bytes), `bitmap` (13 bytes), and `bls_multi_sig` (48 bytes), which is 101 bytes.
 Besides a raw checkpoint, the checkpoint data includes
 a Babylon identifier (4 bytes) and the submitter's Babylon address (20 bytes).
-While this address is not used for any purposes at the moment, it could be used
-in future upgrades to potentially reward vigilante submitters for the
-submission.
 
 Therefore, we need at least two BTC transactions to carry a raw checkpoint.
 The structure of the two `OP_RETURN` entries is shown as the following:
@@ -51,7 +48,7 @@ message CheckpointFirst {
   uint64 epoch_num // 4 Bytes, big endian
   bytes last_commit_hash // 32 Bytes
   bytes bitmap // 13 Bytes
-  bytes bbn_addr // 20 bytes (for reward)
+  bytes bbn_addr // 20 bytes (submitter identifier)
 }
 
 // 62 Bytes in total

docs/operators/vigilantes/vigilantes.mdx

@@ -29,11 +29,6 @@ and synchronized in timely manner.
 - A synced Babylon full node
 - A system that satisfies minimum requirements
 
-## Economic Incentives
-While Vigilantes are crucial to the network's operation, the current Babylon protocol 
-is still developing its comprehensive incentive mechanism. Early participants contribute 
-to the network's robustness and may be positioned advantageously for future reward structures.
-
 ## Operational Considerations
 
 To reliably run a Vigilante program, the following considerations are important: