Render new PoS file

specs/src/SUMMARY.md

@@ -29,7 +29,7 @@
     - [Fee system](./economics/fee-system.md)
     - [Inflation system](./economics/inflation-system.md)
     - [Proof-of-stake](./economics/proof-of-stake.md)
-        - [Bonding mechanism](./economics/proof-of-stake/bonding-mechanism.md)
+        - [Objects and Transactions](./economics/proof-of-stake/objects-and-txs.md)
         - [Cubic slashing](./economics/proof-of-stake/cubic-slashing.md)
         - [Reward distribution](./economics/proof-of-stake/reward-distribution.md)
     - [Shielded pool incentives](./economics/shielded-pool-incentives.md)

specs/src/base-ledger/governance.md

@@ -50,7 +50,7 @@ Each proposal will be stored in a sub-key under the internal proposal address. T
 /\$GovernanceAddress/proposal/epoch/\$id: u64
 ```
 
-An epoch is a range of blocks or time that is defined by the base ledger and made available to the PoS system. This document assumes that epochs are identified by consecutive natural numbers. All the data relevant to PoS are [associated with epochs](../economics/proof-of-stake/bonding-mechanism.md#epoched-data).
+An epoch is a range of blocks or time that is defined by the base ledger and made available to the PoS system. This document assumes that epochs are identified by consecutive natural numbers. All the data relevant to PoS are [associated with epochs](../economics/proof-of-stake/objects-and-txs.md#epoched-data).
 
 Field semantics are as follows:
 

specs/src/economics/proof-of-stake.md

@@ -2,7 +2,7 @@
 
 This section of the specification describes the proof-of-stake mechanism of Namada, which is largely modeled after [Cosmos bonded proof-of-stake](https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/spec/README.md), but makes significant changes to bond storage representation, validator set change handling, reward distribution, and slashing, with the general aims of increased precision in reasoning about security, validator decentralisation, and avoiding unnecessary proof-of-stake-related transactions.
 
-This section is split into three subcomponents: the [bonding mechanism](./proof-of-stake/bonding-mechanism.md), [reward distribution](./proof-of-stake/reward-distribution.md), and [cubic slashing](./proof-of-stake/cubic-slashing.md).
+This section is split into three subcomponents: the [bonding mechanism](./proof-of-stake/objects-and-txs.md), [reward distribution](./proof-of-stake/reward-distribution.md), and [cubic slashing](./proof-of-stake/cubic-slashing.md).
 
 ## Context
 

specs/src/economics/proof-of-stake/cubic-slashing.md

@@ -9,7 +9,7 @@ The cubic slash rate is a function of all infractions in a given epoch and its n
 
 $$9* (\sum_{i \in \text{infractions}} \frac{\text{vp}_{i}}{\text{vp}_{tot}})^2$$
 
-For each individual slash, the rate is ultimately determined as the maximum of the cubic slash rate and some nominal minimum rate that is dependent on the infraction type (see [system parameters](./bonding-mechanism.md#system-parameters)) and is capped at 1.0. The amount of slashed tokens is the rate multiplied by the stake (voting power) used to commit the infraction. The "cubic" in cubic slashing thus comes from the product of the rate, which is quadratic in the voting power, and the voting power itself.
+For each individual slash, the rate is ultimately determined as the maximum of the cubic slash rate and some nominal minimum rate that is dependent on the infraction type (see [system parameters](./objects-and-txs.md#system-parameters)) and is capped at 1.0. The amount of slashed tokens is the rate multiplied by the stake (voting power) used to commit the infraction. The "cubic" in cubic slashing thus comes from the product of the rate, which is quadratic in the voting power, and the voting power itself.
 
 Expressed in pseudocode:
 <!-- I want to make these two code blocks toggleable as in  https://rdmd.readme.io/docs/code-blocks#tabbed-code-blocks but can't seem to get it to work-->

specs/src/economics/proof-of-stake/reward-distribution.md

@@ -2,7 +2,7 @@
 
 Namada uses the automatically-compounding variant of the [F1 fee distribution](https://drops.dagstuhl.de/opus/volltexte/2020/11974/pdf/OASIcs-Tokenomics-2019-10.pdf).
 
-Rewards are given to validators for proposing blocks, for voting on finalizing blocks, and for being in the [consensus validator set](bonding-mechanism.md#validator-sets). The funds for these rewards come from **minting** (creating new tokens). The amount that is minted depends on how many staking tokens are locked (staked) and some maximum annual inflation rate. The rewards mechanism is implemented as a [PD controller](../inflation-system.md#detailed-inflation-calculation-model) that dynamically adjusts the inflation rate to achieve a target staked token ratio. When the total fraction of tokens staked is very low, the return rate per validator needs to increase, but as the total fraction of stake rises, validators will receive fewer rewards. Once the desired staking fraction is achieved, the amount minted will just be the desired annual inflation.
+Rewards are given to validators for proposing blocks, for voting on finalizing blocks, and for being in the [consensus validator set](objects-and-txs.md#validator-sets). The funds for these rewards come from **minting** (creating new tokens). The amount that is minted depends on how many staking tokens are locked (staked) and some maximum annual inflation rate. The rewards mechanism is implemented as a [PD controller](../inflation-system.md#detailed-inflation-calculation-model) that dynamically adjusts the inflation rate to achieve a target staked token ratio. When the total fraction of tokens staked is very low, the return rate per validator needs to increase, but as the total fraction of stake rises, validators will receive fewer rewards. Once the desired staking fraction is achieved, the amount minted will just be the desired annual inflation.
 
 Each delegation to a validator is initiated at an agreed-upon commission rate charged by the validator. Validators pay out rewards to delegators based on this mutually-determined commission rate. The minted rewards are auto-bonded and only transferred when the funds are unbonded. Once the protocol determines the total amount of tokens to mint at the end of the epoch, the minted tokens are effectively divided among the relevant validators and delegators according to their proportional stake. In practice, the reward products, which are the fractional increases in staked tokens claimed, are stored for the validators and delegators, and the reward tokens are only transferred to the validator’s or delegator’s account upon withdrawal. This is described in the following sections. The general system is similar to what Cosmos does.
 
@@ -148,7 +148,7 @@ in order to calculate the new rewards given out to the delegator during withdraw
 
 The commission rate $c_V(e)$ is the same for all delegations to a validator $V$ in a given epoch $e$, including for self-bonds. The validator can change the commission rate at any point, subject to a maximum rate of change per epoch, which is a constant specified when the validator is created and immutable once validator creation has been accepted.
 
-While rewards are given out at the end of every epoch, voting power is only updated after the pipeline offset. According to the [proof-of-stake system](bonding-mechanism.md#epoched-data),  at the current epoch `e`, the validator sets can only be updated for epoch `e + pipeline_offset`, and it should remain unchanged from epoch `e` to `e + pipeline_offset - 1`. Updating voting power in the current epoch would violate this rule.
+While rewards are given out at the end of every epoch, voting power is only updated after the pipeline offset. According to the [proof-of-stake system](objects-and-txs.md#epoched-data),  at the current epoch `e`, the validator sets can only be updated for epoch `e + pipeline_offset`, and it should remain unchanged from epoch `e` to `e + pipeline_offset - 1`. Updating voting power in the current epoch would violate this rule.
 
 
 ## Distribution of block rewards to validators