Evm precompile maintenance skill - #2998
Conversation
…lude issue 2445 notes.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
UnArbosFour
added
the
skip-cargo-audit
🛡️ AI Review — Skeptic (security review)VERDICT: VULNERABLE VERY HIGH scrutiny: 27-day-old account with 1 public repository and 32 lifetime contributions, despite repository write permission; no Gittensor association or author/committer mismatch found. Branch targets main. Static analysis found no runtime, dependency, workflow, credential, or Findings
Prior-comment reconciliation
ConclusionThe maintainer skill can still direct future precompile work to change established economic values by a factor of 10⁹. Balance units must be determined and preserved per released ABI. 📜 Previous run (superseded)
🔍 AI Review — Auditor (domain review)VERDICT: 👎 LIKELY Gittensor-associated contributor; newer account with repository write access, so executable maintainer guidance received close correctness scrutiny. The Auditor proposed a replacement PR description, but the current body is non-trivial; not overwriting. Maintainers: ask the Auditor to regenerate if you want it. This documentation-only PR does not affect the runtime or require a Findings
ConclusionThe blanket balance-scaling instruction can cause future precompile implementations to alter economic values by 10⁹. Correct the unit guidance and document V2 units before merging. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| ## Step 1 - Review current precompiles vs. subtensor functionality | ||
|
|
There was a problem hiding this comment.
[HIGH] Do not apply 18-decimal scaling to every precompile balance
This contradicts the deployed Staking V2 contract: explicit amount_rao and amount_alpha parameters are passed to the pallet in native units without BalanceConverter. Following this instruction would multiply or divide economic values by 10⁹ and could break new functions or adapters. Scaling must follow each released function's unit contract, not a blanket rule.
| ## Step 1 - Review current precompiles vs. subtensor functionality | |
| - Preserve each released function's documented unit contract. Use `BalanceConverter` | |
| only for interfaces defined in 18-decimal EVM units; pass parameters defined | |
| in native rao or alpha units through without decimal scaling. |
| transferStake(bytes32,bytes32,uint256,uint256,uint256) | ||
| burnAlpha(bytes32,uint256,uint256) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
[MEDIUM] Document units for positional staking amounts
This public reference lists several indistinguishable uint256 arguments without names or units. Their meanings differ materially: for example, addStake accepts rao while removeStake accepts alpha. Add parameter names and explicit units for every amount and price argument so callers do not apply the V1 18-decimal convention to V2.
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👎 |
|
|
||
| - All extrinsics should be exposed to precompile callers for the following pallets: |
There was a problem hiding this comment.
[HIGH] Do not apply 18-decimal scaling to every precompile balance
This blanket rule conflicts with deployed interfaces such as BalancePrecompile::getFreeBalance, which returns the underlying Rao value directly. Following it would multiply some established results by 10⁹ or divide inputs that already use runtime units, breaking ABI semantics and potentially causing severe economic miscalculations. Require preservation of each released function's existing unit convention, and use the EVM balance converter only where that function's ABI calls for 18-decimal values.
| - All extrinsics should be exposed to precompile callers for the following pallets: | |
| - Preserve each released function's documented units, scaling, precision, and rounding. | |
| Use the runtime EVM balance converter only where that function's ABI requires 18-decimal values. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
| - Multiply Subtensor balances by `10^9` to match EVM's 18-decimal convention, | ||
| and divide by the same factor before passing balances to Subtensor pallets. |
There was a problem hiding this comment.
[HIGH] Do not apply 18-decimal scaling to every precompile balance
This blanket rule remains unsafe: released precompiles can define different units, and applying 10^9 universally can change economic values by that factor or double-convert an existing interface. Require each function to preserve its documented ABI units and make any conversion explicit and tested.
| - Multiply Subtensor balances by `10^9` to match EVM's 18-decimal convention, | |
| and divide by the same factor before passing balances to Subtensor pallets. | |
| - Preserve each released function's documented balance units, precision, scaling, | |
| and rounding. For new interfaces, define and test conversions per function; do not assume every balance uses 18-decimal EVM units. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
…n evm maintainer skill
| precompile callers for the following pallets: | ||
| - subtensor |
There was a problem hiding this comment.
[HIGH] Do not apply 18-decimal scaling to every precompile balance
This blanket rule conflicts with released interfaces that explicitly use rao (for example, staking parameters named amount_rao) and with the repository documentation stating that precompile amounts are rao rather than 18-decimal wei. Following it would multiply returned values or divide inputs by 10^9, breaking existing contracts and potentially changing transferred/staked economic amounts. Require unit handling to follow each released ABI; only apply scaling where that specific interface already defines 18-decimal values.
| precompile callers for the following pallets: | |
| - subtensor | |
| - Preserve the units, precision, scaling, and rounding defined by each released ABI. | |
| Do not apply a blanket decimal conversion: use 18-decimal scaling only where | |
| that specific interface already requires it, and preserve rao-denominated fields. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
| precompile callers for the following pallets: | ||
| - subtensor |
There was a problem hiding this comment.
[HIGH] Do not apply 18-decimal scaling to every precompile balance
This blanket rule conflicts with the skill's compatibility requirements and existing released ABIs: for example, IBalance.getFreeBalance and staking calls explicitly expose amounts in rao, while the runtime's 10^9 converter applies to native EVM account balances. Following this instruction would multiply existing precompile results or divide their inputs by 10^9, breaking callers and potentially changing transferred or staked value. Require each function to preserve its released units; use scaling only where that function's established ABI explicitly requires 18-decimal EVM units.
| precompile callers for the following pallets: | |
| - subtensor | |
| - Preserve the units and scaling defined by each released precompile ABI; several | |
| existing interfaces expose balances directly in rao. Apply `10^9` conversion | |
| only where the specific interface explicitly uses 18-decimal EVM units. |
|
🔄 AI review updated — Skeptic: VULNERABLE |
1 participant
Adds public documentation for current and proposed EVM precompiles, including ABI lifecycle and subscription-based event reporting. Extends the EVM maintainer skill with focused guidance for ABI versioning, backwards compatibility, coverage, and regression testing—requiring migration before any mainnet change that would force hard deprecation.