add staking v2 precompile#64
Merged
MichaelTrestman merged 1 commit intolatent-to:mainfrom Aug 19, 2025
Merged
Conversation
| 3. Toggle **include option** OFF for the second parameter. | ||
| 4. Click the **+** button and find the new stake record. | ||
|
|
||
| ## Questions about Call the staking precompile from another smart contract. |
There was a problem hiding this comment.
Suggested change
| ## Questions about Call the staking precompile from another smart contract. | |
| ## Notes: Calling the staking precompile from another smart contract |
|
|
||
| ## Questions about Call the staking precompile from another smart contract. | ||
|
|
||
| 1. which one is the coldkey? |
There was a problem hiding this comment.
Suggested change
| 1. which one is the coldkey? |
| ## Questions about Call the staking precompile from another smart contract. | ||
|
|
||
| 1. which one is the coldkey? | ||
| Since the precompile can't get the orginal caller, the precompile takes the contract's address as coldkey. |
There was a problem hiding this comment.
Suggested change
| Since the precompile can't get the orginal caller, the precompile takes the contract's address as coldkey. | |
| - The precompile takes the contract's address as the **coldkey**, since the precompile can't get the original caller. |
|
|
||
| 1. which one is the coldkey? | ||
| Since the precompile can't get the orginal caller, the precompile takes the contract's address as coldkey. | ||
| 2. is the token subtracted from contract or original caller if calling the addStake |
There was a problem hiding this comment.
Suggested change
| 2. is the token subtracted from contract or original caller if calling the addStake |
| 1. which one is the coldkey? | ||
| Since the precompile can't get the orginal caller, the precompile takes the contract's address as coldkey. | ||
| 2. is the token subtracted from contract or original caller if calling the addStake | ||
| The contract need to pay the token. so must guarantee the balance of contract is enough to call addStake. |
There was a problem hiding this comment.
Suggested change
| The contract need to pay the token. so must guarantee the balance of contract is enough to call addStake. | |
| - The **contract** (not the caller's coldkey) must have sufficient liquidity or the transaction will fail. |
| Since the precompile can't get the orginal caller, the precompile takes the contract's address as coldkey. | ||
| 2. is the token subtracted from contract or original caller if calling the addStake | ||
| The contract need to pay the token. so must guarantee the balance of contract is enough to call addStake. | ||
| 3. any security issue for the contract |
There was a problem hiding this comment.
Suggested change
| 3. any security issue for the contract |
| 2. is the token subtracted from contract or original caller if calling the addStake | ||
| The contract need to pay the token. so must guarantee the balance of contract is enough to call addStake. | ||
| 3. any security issue for the contract | ||
| Because the token for addStake is subtracted from contract. We must set the transaction as priviledged one. |
There was a problem hiding this comment.
Suggested change
| Because the token for addStake is subtracted from contract. We must set the transaction as priviledged one. | |
| - The transaction must be *privileged* because the liquidity for `addStake` is subtracted from contract. |
| The contract need to pay the token. so must guarantee the balance of contract is enough to call addStake. | ||
| 3. any security issue for the contract | ||
| Because the token for addStake is subtracted from contract. We must set the transaction as priviledged one. | ||
| like the example in [the link will be available after a PR merged in subtensor side] |
There was a problem hiding this comment.
Suggested change
| like the example in [the link will be available after a PR merged in subtensor side] | |
| <!-- example in link will be available after a PR merged in subtensor side --> |
| 3. any security issue for the contract | ||
| Because the token for addStake is subtracted from contract. We must set the transaction as priviledged one. | ||
| like the example in [the link will be available after a PR merged in subtensor side] | ||
| 4. the unit of amount in addStake, removeStake |
There was a problem hiding this comment.
Suggested change
| 4. the unit of amount in addStake, removeStake |
| Because the token for addStake is subtracted from contract. We must set the transaction as priviledged one. | ||
| like the example in [the link will be available after a PR merged in subtensor side] | ||
| 4. the unit of amount in addStake, removeStake | ||
| As the function parameter indicates, all these are aligned with the decimal of TAO |
There was a problem hiding this comment.
Suggested change
| As the function parameter indicates, all these are aligned with the decimal of TAO | |
| - As the function parameter indicates, `amount` in `addStake` and `removeStake` are specified in TAO $\tau$. |
| like the example in [the link will be available after a PR merged in subtensor side] | ||
| 4. the unit of amount in addStake, removeStake | ||
| As the function parameter indicates, all these are aligned with the decimal of TAO | ||
| 5. If transfer token to contract in msg.value, and trigger the contract to call precompile. should the function in contract do the decimal convert. |
There was a problem hiding this comment.
Suggested change
| 5. If transfer token to contract in msg.value, and trigger the contract to call precompile. should the function in contract do the decimal convert. |
| 4. the unit of amount in addStake, removeStake | ||
| As the function parameter indicates, all these are aligned with the decimal of TAO | ||
| 5. If transfer token to contract in msg.value, and trigger the contract to call precompile. should the function in contract do the decimal convert. | ||
| Yes. the decimal in msg.value is 18. need conversion like `uint256 amount = msg.value / 1e9` |
There was a problem hiding this comment.
Suggested change
| Yes. the decimal in msg.value is 18. need conversion like `uint256 amount = msg.value / 1e9` | |
| - Note that when transferring liquidity to the contract, `msg.value` is in denominations of 1/1e18 TAO $\tau$ . The staking precompile, however, expects RAO, 1/1e9 TAO $\tau$. You must convert before calling it: **uint256 amount = msg.value / 1e9**. |
|
|
||
| ## Staking V1 and V2. | ||
|
|
||
| There are two versions of staking precompile implemenation, V1 and V2. The contract address for V1 is `0x0000000000000000000000000000000000000801`. The address for V2 is `0x0000000000000000000000000000000000000805`. The V1 is deprecated, just being kept for compatiable with old interface. The major difference between V1 and V2 is, the staking amount is fetched from the msg.value in V1. Then precompile transfer the token back to caller. It is misleading and confuses the solidity developers. In V2 implementation, all amount parameters are defined as parameter of transaction. |
There was a problem hiding this comment.
Suggested change
| There are two versions of staking precompile implemenation, V1 and V2. The contract address for V1 is `0x0000000000000000000000000000000000000801`. The address for V2 is `0x0000000000000000000000000000000000000805`. The V1 is deprecated, just being kept for compatiable with old interface. The major difference between V1 and V2 is, the staking amount is fetched from the msg.value in V1. Then precompile transfer the token back to caller. It is misleading and confuses the solidity developers. In V2 implementation, all amount parameters are defined as parameter of transaction. | |
| There are two versions of staking precompile implemenation, V1 and V2. The contract address for V1 is `0x0000000000000000000000000000000000000801`. The address for V2 is `0x0000000000000000000000000000000000000805`. V1 is deprecated, but is kept for backwards-compatibility. The major difference between V1 and V2 is that the staking amount is fetched from the `msg.value` in V1. Then precompile transfers the token back to the caller. It is misleading and confuses solidity developers. In the V2 implementation, all amount parameters are defined as parameter of transaction. |
| ## Call the staking precompile from another smart contract (staking pool use case) | ||
|
|
||
| In this interaction you will compile [`stake.sol`](https://github.com/opentensor/evm-bittensor/blob/main/solidity/stake.sol), a smart contract Solidity code and execute it on the subtensor EVM. This `stake.sol` will, in turn, call the staking precompile that is already deployed in the subtensor EVM. | ||
| In this interaction you will compile [`stakeV2.sol`](https://github.com/opentensor/evm-bittensor/blob/main/solidity/stakeV2.sol), a smart contract Solidity code and execute it on the subtensor EVM. This `stakeV2.sol` will, in turn, call the staking precompile that is already deployed in the subtensor EVM. |
There was a problem hiding this comment.
Suggested change
| In this interaction you will compile [`stakeV2.sol`](https://github.com/opentensor/evm-bittensor/blob/main/solidity/stakeV2.sol), a smart contract Solidity code and execute it on the subtensor EVM. This `stakeV2.sol` will, in turn, call the staking precompile that is already deployed in the subtensor EVM. | |
| In this interaction you will compile [`stakeV2.sol`](https://github.com/opentensor/evm-bittensor/blob/main/solidity/stakeV2.sol), a Solidity smart contract code, and execute it on the Subtensor EVM. This `stakeV2.sol` will, in turn, call the staking precompile that is already deployed on the Subtensor EVM. |
| ``` | ||
|
|
||
| 2. Copy staking precompile address `0x0000000000000000000000000000000000000801` to the **At Address** field in Remix IDE, and click **At Address** button. | ||
| 1. Copy this below ABI from https://github.com/opentensor/subtensor/blob/main/precompiles/src/solidity/stakingV2.abi into Remix IDE as a new file. |
There was a problem hiding this comment.
Suggested change
| 1. Copy this below ABI from https://github.com/opentensor/subtensor/blob/main/precompiles/src/solidity/stakingV2.abi into Remix IDE as a new file. | |
| 1. Copy the ABI from https://github.com/opentensor/subtensor/blob/main/precompiles/src/solidity/stakingV2.abi into Remix IDE as a new file. |
MichaelTrestman
approved these changes
Aug 19, 2025
MichaelTrestman
left a comment
MichaelTrestman
left a comment
There was a problem hiding this comment.
Great, thanks for the changes!
I just made some copy cleanup suggestions, but if these look ok, go ahead and merge, thanks!
MichaelTrestman
added a commit
that referenced
this pull request
Aug 19, 2025
This reverts commit 0d6d239.
MichaelTrestman
added a commit
that referenced
this pull request
Aug 20, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.