diff --git a/proposals/0047-syscall-and-sysvar-for-last-restart-slot.md b/proposals/0047-syscall-and-sysvar-for-last-restart-slot.md
new file mode 100644
index 0000000..12c316b
--- /dev/null
+++ b/proposals/0047-syscall-and-sysvar-for-last-restart-slot.md
@@ -0,0 +1,148 @@
+---
+simd: '0047'
+title: Syscall and Sysvar for last restart slot
+authors:
+  - Godmode Galactus (Mango Markets)
+category: Standard
+type: Core
+status: Draft
+created: 2023-04-15
+---
+
+## Summary
+
+Create a new syscall and sysvar that can be used to get the last restart slot.
+
+A new Sysvar :
+`SysvarLastRestartS1ot1111111111111111111111`
+
+Method signature for syscall:
+`fn sol_get_last_restart_slot() -> Slot`
+
+## Motivation
+
+In Solana, when the cluster cannot reach consensus, it is currently restarted
+using `ledger-tool` with a hard fork on a slot. All participating nodes need to
+restart their validator specifying the hard fork slot. Once all nodes
+participating in the restart effort exceed 80% of the total stakes, the restart
+is successful, and the cluster continues from the hard fork slot. So hard fork
+is a tool to intentionally fork off the nodes not participating in the restart
+effort.
+
+Program developers may find it useful to know that a cluster restart has
+recently occurred. This information can help them prevent arbitrage and
+liquidation caused by outdated oracle price account states. However, the
+cluster's restart process takes several hours; in that time, the world can
+change, causing asset prices to fluctuate. As the cluster updates the state of
+all accounts, malicious actors could take advantage of the delay by conducting
+trades using outdated prices, anticipating that they will soon catch up to the
+actual prices of real-world assets. Knowing that cluster restart has been done
+recently, programs can manage these cases more appropriately.
+
+## Alternatives Considered
+
+We need to have the value of the last restart slot while executing the program.
+We cannot use an account because then it should be updated just after the
+restart is successful, which will add complexity. The best way is to create a
+new syscall and sysvar to get this information during the execution of a
+transaction, which will help us get the last restart slot. We prefer syscall
+over sysvar because the newly created sysvar has to be passed in the instruction
+this takes up transaction accounts space. In the long-term Solana evolution, we
+plan to get rid of syscalls and make everything a sysvar, so we have decided to
+implement both a syscall and a sysvar to address short and long-term evolution.
+
+## New Terminology
+
+None
+
+## Detailed Design
+
+The following criteria should be met to choose a restart slot.
+
+* Should be of type unsigned int 64 bits.
+* Should be indicative of when the cluster was restarted
+* Should be monotonically increasing
+* Should be less than equal to the current slot
+* Should be synchronized in the whole cluster
+* Can also be indicative of a slow block
+* The first restart slot should be `0`
+
+In Solana client `hard fork` variable satisfies nearly all the conditions except
+it is not indicative of slow block, it is a good candidate.
+
+The syscall and sysvar will be available in architectures eBPF and SBF. Only the
+sysvar will be available from architectures SBFv2.
+
+### Feature Gate
+
+This feature should be protected by the feature gate this is because this
+feature can create differences in consensus. Solana core developers should
+create a new keypair and use it to enable this feature on the cluster.
+
+Upon activation, the functionality described below immediately becomes
+available.
+
+### Creation of a new sysvar
+
+Similar to the clock or rent sysvar we can create a new sysvar for last restart
+slot. We have to implement a new class to store the required values, which then
+could be used by sysvar during execution.
+
+Sysvar Id: `SysvarLastRestartS1ot1111111111111111111111`
+
+### Creation of a new syscall
+
+The implementation of this syscall is pretty straightforward. The syscall should
+have following signature:
+
+`fn sol_get_last_restart_slot() -> u64`
+
+Murmur3 hash is: `0xb532af38`
+
+### Overview of changes for Solana client
+
+In Solana Labs validator client all the cluster restart-related data is already
+stored in the bank structure. For other validator clients, we have to get the
+last restart slot information and make it accessible to the runtime of the
+program. We have to set this data in invoke context executing the program. Then
+the syscall and sysvar can use invoke context to return the data to the
+executing program.
+
+### Compute budget for the syscall
+
+As this feature involves moving a u64 from the bank to the invoke context and
+returning it when syscall or sysvar is called.
+
+So considering :
+
+```
+/// Cluster averaged compute unit to micro-sec conversion rate
+COMPUTE_UNIT_TO_US_RATIO = 30;
+```
+
+We can set the maximum compute limit for the syscall to:
+
+```
+COMPUTE_UNITS_LIMIT = 2 * COMPUTE_UNIT_TO_US_RATIO
+```
+
+## Impact
+
+Programs will start using this new syscall to correctly address the security
+concerns during network restart. This will increase the reliability of solana
+cluster as a whole and make program developers more confident to handle edge
+cases during such extreme events.
+
+As the method is syscall the developers do not need to pass any new
+accounts or sysvars to the instruction to use this feature.
+
+## Security Considerations
+
+None
+
+## Backwards Compatibility
+
+The programs using the new syscall could not be used on Solana version which
+does not implement this feature. Existing programs that do not use this feature
+are not impacted at all. Feature gate should be used to enable this feature when
+the majority of the cluster is using the required version.
diff --git a/proposals/0047-syscall-to-get-last-restart-slot.md b/proposals/0047-syscall-to-get-last-restart-slot.md
deleted file mode 100644
index 366a7de..0000000
--- a/proposals/0047-syscall-to-get-last-restart-slot.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-simd: '0047'
-title: Syscall to get the last restart slot
-authors:
-  - Godmode Galactus (Mango Markets)
-category: Standard
-type: Core
-status: Draft
-created: 2023-04-15
----
-
-## Summary
-
-Create a new syscall that can be used to get the last restart slot (currently
-the last time hard fork was done on the cluster).
-
-`fn sol_get_last_restart_slot() -> Slot`
-
-## Motivation
-
-In Solana, when the cluster cannot reach consensus, it is currently restarted
-using `ledger-tool` with a hard fork on a slot. All participating nodes need to
-restart their validator specifying the hard fork slot. Once all nodes
-participating in the restart effort on the hard fork exceed 80% of the total
-stakes, the restart is successful, and the cluster continues from the hard fork
-slot. So hard fork is a tool to intentionally fork off the nodes not
-participating in the restart effort. Currently, we can consider the slot on
-which hard fork was done as a restart slot.
-
-Program developers may find it useful to know that a hard fork has recently
-occurred. This information can help them prevent arbitrage and liquidation
-caused by outdated oracle price account states. However, the cluster's restart
-process takes several hours; in that time, the world can change, causing asset
-prices to fluctuate. As the cluster updates the state of all accounts, malicious
-actors could take advantage of the delay by conducting trades using outdated
-prices, anticipating that they will soon catch up to the actual prices of
-real-world assets. Knowing that cluster restart has been done recently, programs
-can manage these cases more appropriately.
-
-## Alternatives Considered
-
-We need to have the value of the last restart slot while executing the program.
-We cannot use an account because then it should be updated just after the
-restart is successful, which will add complexity. The best way is to create a
-new syscall or sysvar to get this information during the execution of a
-transaction, which will help us get the last restart slot. We prefer syscall
-over sysvar because the newly created sysvar has to be passed in the instruction
-this takes up transaction accounts space. This will break existing program
-interfaces, and the transaction account space is limited which is already a pain
-point for many DeFi projects.
-
-## New Terminology
-
-None
-
-## Detailed Design
-
-Currently, in Solana Labs validator client `hard fork` slots are good indicators
-when the cluster was restarted. This may change in the future following criteria
-that should be met to choose a restart slot.
-
-* Should be indicative of when the cluster was restarted
-* Should be monotonically increasing
-* Should be less than equal to the current slot
-
-The next part will consider hard fork slot is equal to the restart slot.
-
-### Creation of a new syscall
-
-The implementation of this syscall is pretty straightforward. In Solana Labs
-validator client all the hard forks for a cluster are stored in the bank
-structure. The last hard fork slot can be retrieved and then stored in invoke
-context, so that the executing program can access it.
-
-For other validator clients, we have to get the last hard fork slot information
-and make it accessible to the runtime of the program. If there is no hard fork
-done yet on the cluster we consider that the first hard fork is at Slot `0`.
-
-### Overview of changes for solana client
-
-The hardfork data is available in the `Bank`. The structure `HardForks` contains
-a vector with all the previous hard forks. The vector is also sorted when we
-register a slot. So the last element of the vector is usually the last slot at
-which hard fork was done. We can get the last hard fork slot from the bank and
-pass it to invoke context structure. We can register new syscall in the file
-`definitions.rs` where other syscalls are defined.
-
-```rust
-define_syscall!(fn sol_get_last_restart_slot() -> Slot);
-```
-
-We can then return the data of the last hard fork slot passed to the invoke
-context in this function's implementation.
-
-## Impact
-
-Programs will start using this new syscall to correctly address the security
-concerns during network restart. This will increase the reliability of solana
-cluster as a whole and make program developers more confident to handle edge
-cases during such extreme events.
-
-As the method is syscall the developers do not need to pass any new
-accounts or sysvars to the instruction to use this feature.
-
-## Security Considerations
-
-None
-
-## Backwards Compatibility
-
-The programs using the new syscall could not be used on solana version which
-does not implement this feature. Existing programs that do not use this feature
-are not impacted at all.