Off-chain calculations for @substrate/api-sidecar.
npm install @substrate/calcThis package is generated from the calc Rust crate using wasm-bindgen and was initially developed
solely to use as a dependency for substrate-api-sidecar. We are now offering this package as a
standalone through the npm registry.
Example usage for the package can be found in Sidecar's
staking payout service
and Sidecar's block service.
partial_fee (i.e. the total fee minus any tip).```
partial_fee = base_fee + len_fee + ((adjusted_weight_fee/estimated_weight)*actual_weight)
Where:
- base_fee is a fixed base fee to include some transaction in a block. It accountslen_fee
for the work needed to verify the signature and the computing work common to any tx.
It is constant for any tx.
- is a fee paid based on the size (length in bytes) of the transaction.adjusted_weight_fee
Longer transactions require more storage, and therefore are more expensive.
- is a fee that is itself estimated_weight * targeted_fee_adjustment:targeted_fee_adjustment
- is some adjustment made based on the network load andestimated_weight
other circumstantial factors, and is an opaque internal value we have no access to.
- is the "pre-dispatch" weight of the transaction. It's set actual_weight
based on the cost of processing the transaction on reference hardware.
- is the weight that is found in the ExtrinsicSuccess event for weight
the extrinsic in a block (it's just called in the event), and it's estimated_weight
value is often close to , but the node has the opportunity
to change it depending on the actual computing work necessary to process the tx.
The RPC endpoint payment_queryFeeDetails returns base_fee, len_fee and adjusted_weight_fee. The RPC endpoint payment_queryInfo returns estimated_weightweight
(called in the response), and a partialFee value, which is our best
guess at the inclusion fee for the tx without actually submitting it and seeing
whether the node changes the weight or decides not to take a fee at all.
To get the correct values for some extrinsic from both endpoints, provide the
extrinsic bytes, and the number of the block before the block it is included in
(e.g. if the extrinsic was in block 100, you'd use block 99 as an argument). This
is very important.
Once you've called these endpoints, access the ExtrinsicSuccess event to find actual_weight
the , but also a paysFee value which signals whether the extrinsic
actually incurred a fee at all or not (a node has the opportunity to refund the
fee entirely).
With all of those values at hand, the equation above calculates the correct Fee.
Why? Well, the basic way to calculate a pre-dispatch fee is:
``
partial_fee = base_fee + len_fee + adjusted_weight_fee
We can do this from just the RPC methods. But then once it's in a block, we need
to swap out the weight used to calculate that adjusted_weight_fee with the ExtrinsicSuccess
actual weight that was used from the event. In the end, the
calculation itself is simple, but gathering the details needed is the main difficulty.
We do this all in Rust simply to limit any precision loss.
This is a tool to calculate the payout of a staking era, either for a validator
or a nominator. This is not a predictive estimation, instead it intakes data
from a concluded era
to arrive to the final amount. For this it takes the following parameters:
- total_reward_points are the total era pointsera_payout
for a determined era.
- is the payoutvalidator_reward_points
for a determined era.
- are the era pointsvalidator_commission
earned by the validator in a determined era.
- is the commission that the validator takes of its assignednominator_exposure
payout before distribituing the remainder between itself and it's nominators.
- is the amount staked by the nominator or validator,total_exposure
depending on who we are inquiring about.
- the total amount staked.is_validator
- is a bool` that states whether the inquired account is a validator.
We welcome contributions for documentation and code.
If you have any questions you can reach the maintainers by filing an issue on github.