diff --git a/bsip-0040.md b/bsip-0040.md
index 7b9fa6d..45c456c 100644
--- a/bsip-0040.md
+++ b/bsip-0040.md
@@ -37,7 +37,7 @@ With this BSIP any user can create keys with specific purpose (everything else i
 The above list of named keys is nothing that is known to the backend as the backend should have an abstract implementation.
  The UI could provide a button "Create Trading Key" that properly configures the respective custom active permission entry.
 
-This BSIP will be split into two parts that will be voted on serparately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows statefull restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions. Milestone 2 and 3 will be put up for voting if Milestone 1 proves successful.
+This BSIP will be split into two parts that will be voted on separately (see Milestones section). All of the above keys are possible with Milestone 1. Milestone 2 allows stateful restrictions (e.g. allow market orders up to some amount for every month), Milestone 3 gives finer control of how to combine restrictions. Milestone 2 and 3 will be put up for voting if Milestone 1 proves successful.
 
 # Rational
 
@@ -56,10 +56,10 @@ custom_active_permission = {
     authorities = list of custom_active_authority objects
 }
 custom_active_authority = {
-    valid_from,    // timestamp when this is active, defaults to now
-    valid_to,      // timestamp when this is invalid, defaults to 1 year
+    valid_from,    // timestamp when this is active
+    valid_to,      // timestamp when this is invalid
     operation_id,   // operation id of the target operation,
-    authority,     // same as for the existing authortities (multisig with weighted accounts or keys),
+    authority,     // same as for the existing authotities (multisig with weighted accounts or keys),
     restrictions        // see below
 }
 ```
@@ -98,7 +98,7 @@ List of possible restrictions are:
 | `logical_or`     | list of restrictions lists | stateless |
 
 Following cases must hold for a restriction:
-- if there is no value given (e.g. an optional argument, or nested value not given), the restrictions is passed (no change, no violation)
+- if there is no value given (e.g. an optional argument, or nested value not given), the restrictions is passed (even if the underlying operation understands the absence of a key as instructions to delete it on-chain, see bitshares/bitshares-core#838)
 - if the expected type of the argument does not match the given type (no implicit type conversion), the restriction is violated
 - if the function of the restriction asserts negatively, the restriction is violated
 
@@ -115,7 +115,7 @@ Stateless assert, all argument types. `Argument value` must be equal to one of v
 Stateless assert, all argument types. `Argument value` must NOT be equal to any of the values in the list.
 
 #### `lt, le, gt, ge`
-Stateless assert. Allows explicit type converstion:
+Stateless assert. Allows explicit type conversion:
 - `int` type: use as is
 - `string` type: use `length` of string as `argument value`
 
@@ -126,12 +126,12 @@ The different asserts read as:
 - `ge`: `Argument value` must be greater than or equal to `comparative`
 
 #### `limit`
-Statefull assert, only `int` type arguments. When the authority is created, `interval_began` is set to `valid_from` from its custom active authority and `max_cumsum` to `0`. Incoming operations are first tried to match all stateless asserts, 
-and if all passes continue with statefull asserts. If `now > interval_began + interval_in_sec`, then set `max_cumsum = 0` and set `interval_began = now`.
+Stateful assert, only `int` type arguments. When the authority is created, `interval_began` is set to `valid_from` from its custom active authority and `max_cumsum` to `0`. Incoming operations are first tried to match all stateless asserts, 
+and if all passes continue with stateful asserts. If `now > interval_began + interval_in_sec`, then set `max_cumsum = 0` and set `interval_began = now`.
 The assert that needs to pass is now `current_cumsum + incoming value <= max_cumsum`. If all `asserts` of this `custom_active_authority` pass, update `current_cumsum = current_cumsum + incoming value`.
 
 #### `limit_monthly`
-Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes).
+Stateful assert, only `int` type arguments. Analogue to `limit`, but `interval_began` is initially set to `month(valid_from)` and set to `month(now)` on update, additionally the time assert is `month(now) >= interval_began + interval_in_months` (include logic for month overflow when year changes).
 
 #### `attribute_assert`
 Stateless assert, only for dictionary type objects. The data list contains restrictions that all must pass, the reference for the `argument` of the child restriction is nested into the attributes of the parent dictionary type object. Allows nesting of `attribute_assert`.