Address some todo's in concepts and runtime

source/docs/casper/concepts/economics/runtime.md

@@ -4,35 +4,32 @@ slug: /runtime
 ---
 
 # Runtime Economics
-<!--TODO We will likely need to remove the bit about state pruning, since we will, in fact, now support state pruning. Similarly gas price/"conversion rate" will no longer be fixed to 1 mote per 1 unit of gas ("block vacancy" again)-->
-The economics of the runtime layer should incentivize efficient allocation of computational resources, primarily CPU time, to users. Pending state pruning implementation, disk space use is treated as CPU time usage and charged irreversibly per byte written. Currently, [gas](./gas-concepts.md) is allocated according to a first-in, first-out model for deploys, with a fixed price of 1 mote (1/10<sup>9</sup> part of a CSPR token) per 1 unit of gas.
+
+The economics of the runtime layer should incentivize efficient allocation of computational resources, primarily CPU time, to users. <!--TODO add a bit more about state pruning here? -->
+
+Currently, [gas](./gas-concepts.md) is allocated according to a first-in, first-out model for transactions. <!--TODO add a bit more about gas here? -->
 
 ## Gas allocation {#gas-allocation}
 
 Any finite resource on a publicly accessible computer network must be rate-limited, as, otherwise, overuse of this resource is an attack vector \-- a minimal requirement for platform security. However, rate-limiting, implemented on our platform as a simple block gas limit with several lanes, leaves the platform with the problem of fairly and efficiently allocating the gas. We are researching the optimal structure for spot and futures gas markets, and interested readers should consult the relevant [CEPs](https://github.com/casper-network/ceps). In the meantime, this section outlines some basic features of the platform that would underpin any allocation scheme.
 
 ### Consensus before execution & basics of payment {#consensus-before-execution--basics-of-payment}
 
-The Zug and Highway protocols reach consensus on a block _before_ the block is executed, introducing a subtle difference from platforms like Ethereum. In addition, deploys sent to a Casper network can only be selected based on claimed, rather than used, gas.
+The Zug and Highway protocols reach consensus on a block _before_ the block is executed, introducing a subtle difference from platforms like Ethereum. In addition, transactions sent to a Casper network can only be selected based on claimed, rather than used, gas.
 
-Additionally, a minimal amount of CSPR must be present in the user account's main purse to cover the payment computation. The community may introduce additional balance checks in the future.
+Additionally, a minimal amount of CSPR must be present in the user account or contract's main purse to cover the payment computation. The community may introduce additional balance checks in the future.
 
 ### Costs and limits {#costs-and-limits}
 
 Gas cost is a measure of the relative time used by different primitive operations of the execution engine, which is also assumed to be additive. By additivity, we mean that the time to execute a program is approximately proportional to the sum of gas expended by the opcodes and functions called within the program. Casper assigns gas costs to primitive execution engine opcodes and specific, more complex _host-side_ functions that are callable from within the execution engine context. Gas costs for opcodes and host-side functions are specified in the [chainspec](../glossary/C.md#chainspec) and may vary according to arguments.
 
-We expect to refine the current gas cost table to reflect time use more closely, with updates introduced in future upgrades. We also anticipate that storage costs will be calculated separately from computing time with the introduction of state pruning. <!--TODO check this statement for 2.0 Turns out the answer is "no" for now, despite introduction of state pruning. May change in 2.0+-->
+<!--TODO remove this line? -->
+We expect to refine the current gas cost table to reflect time use more closely, with updates introduced in future upgrades.
 
 ### Lanes {#lanes}
 
-The [block gas limit](https://github.com/casper-network/casper-node/blob/b94c4f79ac4ca00e996c418dcc3a98607779a193/resources/production/chainspec.toml#L96-L97) is split into two lanes, one for native transfers and one for general deploys. The number of transfers, which cost a fixed amount of gas, is governed directly by the `block_max_transfer_count` chainspec parameter, set to 2500 when Mainnet launched.
+The [block gas limit](https://github.com/casper-network/casper-node/blob/b94c4f79ac4ca00e996c418dcc3a98607779a193/resources/production/chainspec.toml#L96-L97) is split into two lanes, one for native transfers and one for general transactions. The number of transfers, which cost a fixed amount of gas, is governed directly by the `block_max_transfer_count` chainspec parameter, set to 2500 on Mainnet. <!--TODO check other lanes cost. -->
 
 ## Gas fees {#gas-fees}
 
-The gas price is currently fixed at 1 mote per 1 gas unit.
-<!--TODO See remarks about "block vacancy" above-->
-
-### Fee allocation {#fee-allocation}
-
-<!--TODO This entire section will need a rework-->
-All fees from a particular block accrue to its proposer, incentivizing non-empty block production and allowing major dApps to execute deploys for free, provided they operate a validator node and are comfortable with the latency introduced by validator scheduling.
+See [Gas](./gas-concepts.md). <!--TODO Add a summary and point to new gas concepts page. Mention the new dynamic pricing system for "spot" gas (and "block vacancy"). -->

source/docs/casper/concepts/economics/staking/concepts.md

@@ -9,20 +9,19 @@ The Casper Mainnet is a Proof-of-Stake blockchain that allows validators to stak
 **Consensus mechanism:** The Casper Mainnet and Testnet use a Proof-of-Stake consensus mechanism called [Zug](../../design/zug.md). Another Casper network can choose between Zug and [Highway](../../design/highway.md) using the network's chainspec.
 
 <!--TODO update the number of validators with 2.0 -->
-**Number of validators:** The Casper Mainnet supports up to 100 validators on the network. This number is chosen to strike a balance between performance and decentralization. This platform parameter can be increased through upgrades as development continues and performance improves. In addition, validators can stake on the Casper Mainnet through a process of permission-less bonding by participating in an auction for the validator slot.
+**Number of validators:** The Casper Mainnet supports up to 250 validators on the network. This number is chosen to strike a balance between performance and decentralization. This platform parameter can be increased through upgrades as development continues and performance improves. In addition, validators can stake on the Casper Mainnet through a process of permission-less bonding by participating in an auction for the validator slot.
 
 **Permission-less bonding:** For validators to begin staking and earning rewards, they must win a staking auction by competing with current and prospective validators to supply one of the forthcoming top stakes for a given era. This process is permission-less, meaning validators can join and leave the auction without restrictions, except for a waiting period to unlock staked tokens.
 
 <!--TODO They do not receive rewards for current activity, but can still be rewarded for past signatures due to lookback, check with @fizyk20-->
-**Unbonding:** To detach from the Casper Mainnet, it takes seven eras for both validators and delegators. Neither validators nor delegators receive rewards during the seven eras required for unbonding, as they are not actively contributing to the network's security during that time.
+**Unbonding:** To detach from the Casper Mainnet, it takes seven eras for both validators and delegators. Neither validators nor delegators receive rewards for the seven eras required for unbonding, as they are not actively contributing to the network's security during that time. However, during the unbonding period, they may receive rewards for having participated in past eras.
 
 <!--TODO update block times with 2.0-->
-**Eras and block times:** An era on Casper is roughly 2 hours long. Casper's consensus protocol allows validators to propose blocks as quickly as network conditions allow, subject to a platform-wide limit that may be adjusted with upgrades. We anticipate block times to last between sixteen seconds and eight minutes.
+**Eras and block times:** An era on the Casper Mainnet is roughly 2 hours long. Casper's Zug consensus allows validators to propose blocks as quickly as network conditions allow. We anticipate block times to last between 8 seconds and 1 minute.
 
-<!--TODO Might need a rework due to new rewards (promptness of consensus participation doesn't impact rewards directly)-->
-**Block rewards:** Block time is orthogonal to [rewards](../../design/rewards.md), so there is no precise reward per block. Instead, the number of rewards is split proportionally among stakes and reduced for failure to participate in the protocol promptly.
+**Block rewards:** Reward calculations depend only on the linear structure of the blockchain and published finality signatures, rather than block time or consensus mechanism. Reward calculations assume a known constant token supply inflation with nominal platform operation.
 
-**Reward cycle:** Rewards are distributed to validators and delegators once per era.
+**Reward cycle:** Rewards are distributed to validators and delegators at the end of an era for all blocks in that era and several eligible blocks from the previous era.
 
 **Token supply and inflation:** Mainnet launched with ten billion CSPR at the time of genesis. The target annual supply growth rate is 8%.