Update nep-0508.md - per comments

neps/nep-0508.md

@@ -50,7 +50,6 @@ Currently, NEAR protocol has four shards. With more partners onboarding, we star
   * automatically determining the shard layout
 * Merging shards or boundary adjustments
 * Shard reshuffling
-* Shard Layout determination logic. Shard boundaries are still determined offline and hardcoded.
 
 ### Required protocol changes
 
@@ -75,10 +74,10 @@ The implementation heavily re-uses the implementation from [NEP-40](https://gith
 
 ### Code pointers to the proposed implementation 
 
-* [new shard layout](https://github.com/near/nearcore/blob/bc0eb3c6607f4ae865526a25b80706ec4e081fdc/core/primitives/src/shard_layout.rs#L161)
-* [the main logic for splitting states](https://github.com/near/nearcore/blob/bc0eb3c6607f4ae865526a25b80706ec4e081fdc/chain/chain/src/resharding.rs#L248)
-* [the main logic for applying chunks to split states](https://github.com/near/nearcore/blob/bc0eb3c6607f4ae865526a25b80706ec4e081fdc/chain/chain/src/chain.rs#L5180)
-* [the main logic for garbage collecting state from parent shard](https://github.com/near/nearcore/blob/eb824087fdd0763f00e695e303d7ad6c56f96538/chain/chain/src/store.rs#L2325)
+* [new shard layout](https://github.com/near/nearcore/blob/c9836ab5b05c229da933d451fe8198d781f40509/core/primitives/src/shard_layout.rs#L161)  
+* [the main logic for splitting states](https://github.com/near/nearcore/blob/c9836ab5b05c229da933d451fe8198d781f40509/chain/chain/src/resharding.rs#L280)
+* [the main logic for applying chunks to split states](https://github.com/near/nearcore/blob/c9836ab5b05c229da933d451fe8198d781f40509/chain/chain/src/update_shard.rs#L315)
+* [the main logic for garbage collecting state from parent shard](https://github.com/near/nearcore/blob/c9836ab5b05c229da933d451fe8198d781f40509/chain/chain/src/store.rs#L2335)
 
 ### Flat Storage
 
@@ -158,6 +157,10 @@ As mentioned above under 'Integration with Statelss Validation' section, initial
 
 ## Future possibilities
 
+### Further reshardings
+
+This NEP introduces both an implementation of resharding and an actual resharding to be done in the production networks. Further reshardings can also be performed in the future by adding a new shard layout and setting the shard layout for the desired protocol version in the `AllEpochConfig`. 
+
 ### Dynamic resharding
 
 As noted above, dynamic resharding is out of scope for this NEP and should be implemented in the future. Dynamic resharding includes the following but not limited to:
@@ -199,7 +202,9 @@ In the future, we would like to potentially change the schema in a way such that
 
 ### Backwards Compatibility
 
-We do not expect anything to break with this change. Yet, shard splitting can introduce additional complexity on replayability. For instance, as target shard of a receipt and belonging shard of an account can change with shard splitting, shard splitting must be replayed along with transactions at the exact epoch boundary.
+Any tooling or frameworks external to nearcore that have the current shard layout or the current number of shards hardcoded may break and will need to be adjusted in advance. The recommended way for fixing it is querying an RPC node for the shard layout of the relevant epoch and using that information in place of the previously hardcoded shard layout or number of shards. 
+
+Within nearcore we do not expect anything to break with this change. Yet, shard splitting can introduce additional complexity on replayability. For instance, as target shard of a receipt and belonging shard of an account can change with shard splitting, shard splitting must be replayed along with transactions at the exact epoch boundary.
 
 ## Changelog