From 4758e3fab857c748878e8aa1c1c55d08adab17ed Mon Sep 17 00:00:00 2001
From: Jinho Jang <41753422+jinhojang6@users.noreply.github.com>
Date: Sun, 27 Jul 2025 23:25:56 +0900
Subject: [PATCH] docs: update rln-key-benchmarks.md

---
 docs/rln-key-benchmarks.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/rln-key-benchmarks.md b/docs/rln-key-benchmarks.md
index 91835be..2892e9d 100644
--- a/docs/rln-key-benchmarks.md
+++ b/docs/rln-key-benchmarks.md
@@ -49,7 +49,7 @@ In the following simulation, we can see `100` nwaku interconnected nodes, where
 
 Using RLN implies that waku should now piggyback on a blockchain (the case study uses Ethereum Sepolia) and has to stay up to date with the latest events emitted by the rln smart contract. These events are used to locally construct a tree that contains all members allowed to create valid proofs to send messages. Some numbers:
 - A tree with 10k members takes `2Mbytes` of space. Negligible.
-- A tree with 10k members takes `<4 minutes to synchronize. Assumable since it's done just once.
+- A tree with 10k members takes `<4` minutes to synchronize. Assumable since it's done just once.
 - With a block range of 5000 blocks for each request, we would need `520 requests` to synchronize 1 year of historical data from the tree. Assumable since most of the free endpoints out there allow 100k/day.
 
 ## Performance relay vs. rln-relay