diff --git a/neps/nep-0568.md b/neps/nep-0568.md
index 04aacf072..3391794c8 100644
--- a/neps/nep-0568.md
+++ b/neps/nep-0568.md
@@ -28,16 +28,10 @@ updates.
 
 ## Motivation
 
-```text
-[Explain why this proposal is necessary, how it will benefit the NEAR protocol or community, and what problems it solves. Also describe why the existing protocol specification is inadequate to address the problem that this NEP solves, and what potential use cases or outcomes.]
-```
+The sharded architecture of the NEAR Protocol is a cornerstone of its design, enabling parallel and distributed execution that significantly boosts overall throughput. Resharding plays a pivotal role in this system, allowing the network to adjust the number of shards to accommodate growth. By increasing the number of shards, resharding ensures the network can scale seamlessly, alleviating existing congestion, managing the rising traffic demands, and welcoming new customers. This adaptability is essential for maintaining the protocol's performance, reliability, and capacity to support a thriving, ever-expanding ecosystem.
 
 ## Specification
 
-```text
-[Explain the proposal as if you were teaching it to another developer. This generally means describing the syntax and semantics, naming new concepts, and providing clear examples. The specification needs to include sufficient detail to allow interoperable implementations getting built by following only the provided specification. In cases where it is infeasible to specify all implementation details upfront, broadly describe what they are.]
-```
-
 Resharding will be scheduled in advance by the NEAR developer team. The new
 shard layout will be hardcoded into the neard binary and linked to the protocol
 version. As the protocol upgrade progresses, resharding will be triggered during