npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

@substrate/calc

v0.3.2

Published

Off-chain calculations for @substrate/api-sidecar.

Readme

About

This 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.

Usage

Example usage for the package can be found in Sidecar's staking payout service and Sidecar's block service.

calc_partial_fee

Tool to calculate an extrinsics' partial_fee (i.e. the total fee minus any tip). It uses the following formula:

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 accounts for the work needed to verify the signature and the computing work common to any tx. It is constant for any tx.
  • len_fee is a fee paid based on the size (length in bytes) of the transaction. Longer transactions require more storage, and therefore are more expensive.
  • adjusted_weight_fee is a fee that is itself estimated_weight * targeted_fee_adjustment:
    • targeted_fee_adjustment is some adjustment made based on the network load and other circumstantial factors, and is an opaque internal value we have no access to.
    • estimated_weight is the "pre-dispatch" weight of the transaction. It's set based on the cost of processing the transaction on reference hardware.
  • actual_weight is the weight that is found in the ExtrinsicSuccess event for the extrinsic in a block (it's just called weight in the event), and it's value is often close to estimated_weight, 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_weight (called weight 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 the actual_weight, 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 actual weight that was used from the ExtrinsicSuccess 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.

calc_payout

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 points for a determined era.
  • era_payout is the payout for a determined era.
  • validator_reward_points are the era points earned by the validator in a determined era.
  • validator_commission is the commission that the validator takes of its assigned payout before distribituing the remainder between itself and it's nominators.
  • nominator_exposure is the amount staked by the nominator or validator, depending on who we are inquiring about.
  • total_exposure the total amount staked.
  • is_validator is a bool that states whether the inquired account is a validator.

Contributing

We welcome contributions for documentation and code. If you have any questions you can reach the maintainers by filing an issue on github.