diff --git a/State-Channels.md b/State-Channels.md
index f278cff..15a5aae 100644
--- a/State-Channels.md
+++ b/State-Channels.md
@@ -29,7 +29,7 @@ Running a small scaling benchmark, similar to the single-channel benchmark above
 * 3,500 coin transfers per second (6.5x)
 * 30,400 plain messages per second (11.5x)
 
-We have not yet spent much time optimizing this. Adding more nodes, the total throughput will scale linearly, i.e. if one node can deliver a certain throughput, `N` nodes will deliver `N` times as much, at least during the time when channels do not post transactions to the chain (the whole point of State Channels is to do this as seldom as possible).
+We have not yet spent much time optimizing this, but were able to push the benchmark to 10k concurrent channels, and the total throughput numbers remained stable. This indicates that the system is mostly free from internal bottlenecks that would degrade performance as more channels are added. However, the 10 performance cores were saturated already with 50 channels putting the pedal to the metal, so further scaling was not possible on that particular hardware. Adding more nodes, the total throughput will scale linearly, i.e. if one node can deliver a certain throughput, `N` nodes will deliver `N` times as much, at least during the time when channels do not post transactions to the chain (the whole point of State Channels is to do this as seldom as possible).
 
 The State Channel implementation is capable of running in server mode, where the application listens on a given port and services any request that comes in. A State Channel Market demo exists, where a market provider services merchants and customers, facilitating customer-to-merchant payments atomically across channels, for a low service fee, and at a round-trip cost of ca 15 ms + network transfer delays and, as mentioned above, with immediate settlement.