address comments

Author: tac0turtle

cips/cip-031.md

@@ -65,7 +65,7 @@ By integrating staking rewards directly into the lockup schedule, this proposal
    - Unlocked & Unstaked
    - Unlocked & Staked
 
-4. **Mathematical Model & Example:**
+4. **Example Implementation:**
 
 ### Continuous Vesting Accounts
 
@@ -102,15 +102,7 @@ Periodic account creation will be removed, and update schedule will be a noop
 
 ### Permanent Vesting Accounts
 
-Periodic account creation will be removed, and update schedule will be a noop
-
-    *NOTE: reward calculation is arbitrary, it is not based on Celestia's inflation.*
-
-5. **Error Handling:**
-
-- Ensure sufficient balance checks before processing rewards.
-- Validate that the lockup period is still active.
-- Separate commission transfers from reward lockup updates.
+Permanent account creation will be removed, and update schedule will be a noop
 
 ### Module Interaction
 
@@ -156,7 +148,7 @@ When upgrading to v4 we propose introducing a migration that will set the Parame
 
 # Backwards Compatibility
 
-Continuous Vesting, Delayed Vesting will implement the `UpdateSchedule` function allowing for the original amount to be added to. Periodic and Permanent will implement the design as a noop, and they will be disallowed from being created. 
+The continuous and delayed vesting account types will be updated to implement CIP-31. Specifically, they will implement the `UpdateSchedule` function so that the original vesting amount can account for staking rewards. The periodic and permanent account types will not support CIP-31. They will be disallowed from being created.
 
 # Test Cases
 
@@ -169,7 +161,7 @@ The implementation should include test cases covering:
 
 # Reference Implementation
 
-The `VestingAccount` interface will be updated to account for an UpdateSchedule method which includes the amount to update the schedule with and teh blocktime at which it occured. We must pass in the blocktime in order to understand if the account is fully vested or not.
+The `VestingAccount` interface will be updated to account for an UpdateSchedule method which includes the amount to update the schedule with and the blocktime at which it occured. We must pass in the blocktime in order to understand if the account is fully vested or not.
 
 ```diff
 // VestingAccount defines an account type that vests coins via a vesting schedule.
@@ -204,7 +196,7 @@ type VestingAccount interface {
 	GetDelegatedFree() sdk.Coins
 	GetDelegatedVesting() sdk.Coins
 
-	// UpdateSchedule updates the original vesting amount for the account.
++ // UpdateSchedule updates the original vesting amount for the account.
 +	UpdateSchedule(blockTime time.Time, amount sdk.Coins) error
 }
 ```