Baking rewards as operations
How do making rewards appear on the chain when they are credited to the baker? Is it a 'transaction' operation? How do I go about identifying them?
Thanks!
baking rewards
New contributor
add a comment |
How do making rewards appear on the chain when they are credited to the baker? Is it a 'transaction' operation? How do I go about identifying them?
Thanks!
baking rewards
New contributor
add a comment |
How do making rewards appear on the chain when they are credited to the baker? Is it a 'transaction' operation? How do I go about identifying them?
Thanks!
baking rewards
New contributor
How do making rewards appear on the chain when they are credited to the baker? Is it a 'transaction' operation? How do I go about identifying them?
Thanks!
baking rewards
baking rewards
New contributor
New contributor
New contributor
asked 3 hours ago
Crypto MikeCrypto Mike
61
61
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
The rewards happen as part of the protocol and it's all on chain. But they are not a "transaction" in the normal sense of the word, as usually a transaction requires some user intervention. But there is fundamental movements of funds from the "freezer" to the delegates. Conceptually, the freezer temporarily holds all the bonds and rewards for baking and endorsing.
To find this information on chain, we have to look at the very last block of the cycle we'd expect the reward.
blockNumForRewards = (rewardedCycleNum + 6) * numOfBlocksInCycle
For example, for cycle 93, the rewards for cycle 93 gets unlocked at the last block of cycle 98, so we need to look at block number (93 + 6) * 4096 = 405,504
.
After we knowing the block number, We can query for the block with our node by getting the hash from a block explorer like tzscan. In this case, BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
is our block hash:
/chains/main/blocks/BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
Obviously there is a lot of information in here, but let's focus on the path that handles the balance changes, specifically metadata > balance_updates
. Example:
{
"protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
"chain_id": "NetXdQprcVkpaWU",
"hash": "BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf",
"metadata": {
...
"balance_updates": [
// this is what we care about
]
}
...
}
This portion of the block is the balance updates that retains to what the protocol needs to apply regardless of the user interventions. In a lot of the blocks, this portion will just include the current block baker with its locked rewards and bonds. In the last block of the cycle, balance_updates
also includes all the rewards and bonds unlocks for every baker that participated in cycle 93.
Anyhow, let's dig into the specifics of one baker to understand further. For illustration, I've filtered out transactions for one particular baker tz1ivoFE...TD
.
"balance_updates": [
...
{
"kind": "freezer",
"category": "deposits",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-10368000000"
},
{
"kind": "freezer",
"category": "fees",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-9362"
},
{
"kind": "freezer",
"category": "rewards",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-321000000"
},
{
"kind": "contract",
"contract": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"change": "10689009362"
},
...
Inside of balance_updates
array, it will include every "transaction" that needs to be adjusted for all these addresses including the "freezer". Each transaction also gives some clues on what they are for.
The above is pretty typical what we'll see per baker. There are 3 "freezer" related transactions and one "contract". The "freezer" transaction are different by their category
(deposits
, fees
and rewards
). The categories are pretty self explanatory. Just in case you are wonder, deposits and rewards will include both baking and endorsements bonds and rewards. Notice that those freezer operations are negative values and they imply that these balances are subtracted from freezer
.
The "contract" transaction is what changes the balance to the baker in question. This is pretty similar to a user initiated transaction. If we add up the 3 freezer category's balances, they would add up to the change balance for the baker.
add a comment |
Currently rewards are done manually and off-chain. You manually (or via a script) need to transfer the rewards to delegators.
When you transfer the rewards it will create transactions with operation ids which will be on-chain.
You could write a tool to connect the dots and create your own reporting, or use some of the existing tools (eg: bakerei, tezos-reward-distributor, etc...)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "698"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Crypto Mike is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f1125%2fbaking-rewards-as-operations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The rewards happen as part of the protocol and it's all on chain. But they are not a "transaction" in the normal sense of the word, as usually a transaction requires some user intervention. But there is fundamental movements of funds from the "freezer" to the delegates. Conceptually, the freezer temporarily holds all the bonds and rewards for baking and endorsing.
To find this information on chain, we have to look at the very last block of the cycle we'd expect the reward.
blockNumForRewards = (rewardedCycleNum + 6) * numOfBlocksInCycle
For example, for cycle 93, the rewards for cycle 93 gets unlocked at the last block of cycle 98, so we need to look at block number (93 + 6) * 4096 = 405,504
.
After we knowing the block number, We can query for the block with our node by getting the hash from a block explorer like tzscan. In this case, BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
is our block hash:
/chains/main/blocks/BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
Obviously there is a lot of information in here, but let's focus on the path that handles the balance changes, specifically metadata > balance_updates
. Example:
{
"protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
"chain_id": "NetXdQprcVkpaWU",
"hash": "BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf",
"metadata": {
...
"balance_updates": [
// this is what we care about
]
}
...
}
This portion of the block is the balance updates that retains to what the protocol needs to apply regardless of the user interventions. In a lot of the blocks, this portion will just include the current block baker with its locked rewards and bonds. In the last block of the cycle, balance_updates
also includes all the rewards and bonds unlocks for every baker that participated in cycle 93.
Anyhow, let's dig into the specifics of one baker to understand further. For illustration, I've filtered out transactions for one particular baker tz1ivoFE...TD
.
"balance_updates": [
...
{
"kind": "freezer",
"category": "deposits",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-10368000000"
},
{
"kind": "freezer",
"category": "fees",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-9362"
},
{
"kind": "freezer",
"category": "rewards",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-321000000"
},
{
"kind": "contract",
"contract": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"change": "10689009362"
},
...
Inside of balance_updates
array, it will include every "transaction" that needs to be adjusted for all these addresses including the "freezer". Each transaction also gives some clues on what they are for.
The above is pretty typical what we'll see per baker. There are 3 "freezer" related transactions and one "contract". The "freezer" transaction are different by their category
(deposits
, fees
and rewards
). The categories are pretty self explanatory. Just in case you are wonder, deposits and rewards will include both baking and endorsements bonds and rewards. Notice that those freezer operations are negative values and they imply that these balances are subtracted from freezer
.
The "contract" transaction is what changes the balance to the baker in question. This is pretty similar to a user initiated transaction. If we add up the 3 freezer category's balances, they would add up to the change balance for the baker.
add a comment |
The rewards happen as part of the protocol and it's all on chain. But they are not a "transaction" in the normal sense of the word, as usually a transaction requires some user intervention. But there is fundamental movements of funds from the "freezer" to the delegates. Conceptually, the freezer temporarily holds all the bonds and rewards for baking and endorsing.
To find this information on chain, we have to look at the very last block of the cycle we'd expect the reward.
blockNumForRewards = (rewardedCycleNum + 6) * numOfBlocksInCycle
For example, for cycle 93, the rewards for cycle 93 gets unlocked at the last block of cycle 98, so we need to look at block number (93 + 6) * 4096 = 405,504
.
After we knowing the block number, We can query for the block with our node by getting the hash from a block explorer like tzscan. In this case, BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
is our block hash:
/chains/main/blocks/BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
Obviously there is a lot of information in here, but let's focus on the path that handles the balance changes, specifically metadata > balance_updates
. Example:
{
"protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
"chain_id": "NetXdQprcVkpaWU",
"hash": "BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf",
"metadata": {
...
"balance_updates": [
// this is what we care about
]
}
...
}
This portion of the block is the balance updates that retains to what the protocol needs to apply regardless of the user interventions. In a lot of the blocks, this portion will just include the current block baker with its locked rewards and bonds. In the last block of the cycle, balance_updates
also includes all the rewards and bonds unlocks for every baker that participated in cycle 93.
Anyhow, let's dig into the specifics of one baker to understand further. For illustration, I've filtered out transactions for one particular baker tz1ivoFE...TD
.
"balance_updates": [
...
{
"kind": "freezer",
"category": "deposits",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-10368000000"
},
{
"kind": "freezer",
"category": "fees",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-9362"
},
{
"kind": "freezer",
"category": "rewards",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-321000000"
},
{
"kind": "contract",
"contract": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"change": "10689009362"
},
...
Inside of balance_updates
array, it will include every "transaction" that needs to be adjusted for all these addresses including the "freezer". Each transaction also gives some clues on what they are for.
The above is pretty typical what we'll see per baker. There are 3 "freezer" related transactions and one "contract". The "freezer" transaction are different by their category
(deposits
, fees
and rewards
). The categories are pretty self explanatory. Just in case you are wonder, deposits and rewards will include both baking and endorsements bonds and rewards. Notice that those freezer operations are negative values and they imply that these balances are subtracted from freezer
.
The "contract" transaction is what changes the balance to the baker in question. This is pretty similar to a user initiated transaction. If we add up the 3 freezer category's balances, they would add up to the change balance for the baker.
add a comment |
The rewards happen as part of the protocol and it's all on chain. But they are not a "transaction" in the normal sense of the word, as usually a transaction requires some user intervention. But there is fundamental movements of funds from the "freezer" to the delegates. Conceptually, the freezer temporarily holds all the bonds and rewards for baking and endorsing.
To find this information on chain, we have to look at the very last block of the cycle we'd expect the reward.
blockNumForRewards = (rewardedCycleNum + 6) * numOfBlocksInCycle
For example, for cycle 93, the rewards for cycle 93 gets unlocked at the last block of cycle 98, so we need to look at block number (93 + 6) * 4096 = 405,504
.
After we knowing the block number, We can query for the block with our node by getting the hash from a block explorer like tzscan. In this case, BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
is our block hash:
/chains/main/blocks/BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
Obviously there is a lot of information in here, but let's focus on the path that handles the balance changes, specifically metadata > balance_updates
. Example:
{
"protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
"chain_id": "NetXdQprcVkpaWU",
"hash": "BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf",
"metadata": {
...
"balance_updates": [
// this is what we care about
]
}
...
}
This portion of the block is the balance updates that retains to what the protocol needs to apply regardless of the user interventions. In a lot of the blocks, this portion will just include the current block baker with its locked rewards and bonds. In the last block of the cycle, balance_updates
also includes all the rewards and bonds unlocks for every baker that participated in cycle 93.
Anyhow, let's dig into the specifics of one baker to understand further. For illustration, I've filtered out transactions for one particular baker tz1ivoFE...TD
.
"balance_updates": [
...
{
"kind": "freezer",
"category": "deposits",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-10368000000"
},
{
"kind": "freezer",
"category": "fees",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-9362"
},
{
"kind": "freezer",
"category": "rewards",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-321000000"
},
{
"kind": "contract",
"contract": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"change": "10689009362"
},
...
Inside of balance_updates
array, it will include every "transaction" that needs to be adjusted for all these addresses including the "freezer". Each transaction also gives some clues on what they are for.
The above is pretty typical what we'll see per baker. There are 3 "freezer" related transactions and one "contract". The "freezer" transaction are different by their category
(deposits
, fees
and rewards
). The categories are pretty self explanatory. Just in case you are wonder, deposits and rewards will include both baking and endorsements bonds and rewards. Notice that those freezer operations are negative values and they imply that these balances are subtracted from freezer
.
The "contract" transaction is what changes the balance to the baker in question. This is pretty similar to a user initiated transaction. If we add up the 3 freezer category's balances, they would add up to the change balance for the baker.
The rewards happen as part of the protocol and it's all on chain. But they are not a "transaction" in the normal sense of the word, as usually a transaction requires some user intervention. But there is fundamental movements of funds from the "freezer" to the delegates. Conceptually, the freezer temporarily holds all the bonds and rewards for baking and endorsing.
To find this information on chain, we have to look at the very last block of the cycle we'd expect the reward.
blockNumForRewards = (rewardedCycleNum + 6) * numOfBlocksInCycle
For example, for cycle 93, the rewards for cycle 93 gets unlocked at the last block of cycle 98, so we need to look at block number (93 + 6) * 4096 = 405,504
.
After we knowing the block number, We can query for the block with our node by getting the hash from a block explorer like tzscan. In this case, BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
is our block hash:
/chains/main/blocks/BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf
Obviously there is a lot of information in here, but let's focus on the path that handles the balance changes, specifically metadata > balance_updates
. Example:
{
"protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
"chain_id": "NetXdQprcVkpaWU",
"hash": "BLdha4dMeWYxYkuP46eCgYwsgBYiKPNFLvgiu5NqgdxPLhkgzUf",
"metadata": {
...
"balance_updates": [
// this is what we care about
]
}
...
}
This portion of the block is the balance updates that retains to what the protocol needs to apply regardless of the user interventions. In a lot of the blocks, this portion will just include the current block baker with its locked rewards and bonds. In the last block of the cycle, balance_updates
also includes all the rewards and bonds unlocks for every baker that participated in cycle 93.
Anyhow, let's dig into the specifics of one baker to understand further. For illustration, I've filtered out transactions for one particular baker tz1ivoFE...TD
.
"balance_updates": [
...
{
"kind": "freezer",
"category": "deposits",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-10368000000"
},
{
"kind": "freezer",
"category": "fees",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-9362"
},
{
"kind": "freezer",
"category": "rewards",
"delegate": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"level": 93,
"change": "-321000000"
},
{
"kind": "contract",
"contract": "tz1ivoFEvbfbUNav5FwLvmxzMGcNXWxY9qTD",
"change": "10689009362"
},
...
Inside of balance_updates
array, it will include every "transaction" that needs to be adjusted for all these addresses including the "freezer". Each transaction also gives some clues on what they are for.
The above is pretty typical what we'll see per baker. There are 3 "freezer" related transactions and one "contract". The "freezer" transaction are different by their category
(deposits
, fees
and rewards
). The categories are pretty self explanatory. Just in case you are wonder, deposits and rewards will include both baking and endorsements bonds and rewards. Notice that those freezer operations are negative values and they imply that these balances are subtracted from freezer
.
The "contract" transaction is what changes the balance to the baker in question. This is pretty similar to a user initiated transaction. If we add up the 3 freezer category's balances, they would add up to the change balance for the baker.
edited 21 mins ago
answered 2 hours ago
FrankFrank
1,297418
1,297418
add a comment |
add a comment |
Currently rewards are done manually and off-chain. You manually (or via a script) need to transfer the rewards to delegators.
When you transfer the rewards it will create transactions with operation ids which will be on-chain.
You could write a tool to connect the dots and create your own reporting, or use some of the existing tools (eg: bakerei, tezos-reward-distributor, etc...)
add a comment |
Currently rewards are done manually and off-chain. You manually (or via a script) need to transfer the rewards to delegators.
When you transfer the rewards it will create transactions with operation ids which will be on-chain.
You could write a tool to connect the dots and create your own reporting, or use some of the existing tools (eg: bakerei, tezos-reward-distributor, etc...)
add a comment |
Currently rewards are done manually and off-chain. You manually (or via a script) need to transfer the rewards to delegators.
When you transfer the rewards it will create transactions with operation ids which will be on-chain.
You could write a tool to connect the dots and create your own reporting, or use some of the existing tools (eg: bakerei, tezos-reward-distributor, etc...)
Currently rewards are done manually and off-chain. You manually (or via a script) need to transfer the rewards to delegators.
When you transfer the rewards it will create transactions with operation ids which will be on-chain.
You could write a tool to connect the dots and create your own reporting, or use some of the existing tools (eg: bakerei, tezos-reward-distributor, etc...)
answered 3 hours ago
lostdorjelostdorje
4659
4659
add a comment |
add a comment |
Crypto Mike is a new contributor. Be nice, and check out our Code of Conduct.
Crypto Mike is a new contributor. Be nice, and check out our Code of Conduct.
Crypto Mike is a new contributor. Be nice, and check out our Code of Conduct.
Crypto Mike is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Tezos Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftezos.stackexchange.com%2fquestions%2f1125%2fbaking-rewards-as-operations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown