Thank you @tezit for your answers. Just one more question:
I set the “Minimum Delegation Amount (tez)” to 1 tez. In the big map of the smart contract it is stored as “10000”. If this is in mutez, shouldn’t the value be 1’000’000?
The value is not stored as mutez, its stored with an arbitrary multiplier to support N number of decimal places. N is set to 4 decimal places so what you see in storage is value * 10000 (I made the decision to not use mutez because I felt it was not semantically correct as the app decimal values are not always related to tez, for example the split, but this decision could be flawed and might need to be changed to mutez in v2)
Please keep asking as these questions are all being added to a list that will eventually make it into General Help and Technical Details Docs.
edited: To clarify that some of the decimal fields are tez and thus could be reasonably stored as mutez, but others such as the split are not so rather than have two different approaches to handle decimals decision was made to use a singular more general approach.
1 Like
I think what currently is missing in the smart contract (or in the offchain additional baker details data) is a variable, probably called “maxDelegation”, which specifies the maximum delegation amount a baker is willing to accept. If integrated into wallets, this could prevent large holders of Tez to over-delegate a baker also when the “openForDelegation” flag is set as “true”.
Something like “maxDelegation” working in coordination with “openForDelegation” is probably needed.
We have a field which was ultimately left unused as it wasn’t yet clear how to utilize it; that field is named “overDelegationThreshold” and you can see it exists in the contract and is set to 100. The intent was that a baker could set the % of their bond utilization at which point they consider themselves to be overDelegated which could help users to make delegation decisions.
By having this baker specified field as a % it would also help those bakers who intend to always add bond at the last moment to specify a value of say 200% which indicates “even if our bond appears to be at capacity we will continue to accept delegation”.
1 Like
We think this is a great idea and we would like to see a testing baking key added to the baker’s information. This would be the key that bakers would use to bake on the testnet. That way testnets can fund at the genesis block level the baker’s test accounts and block explorers on the testnet can label up bakers that are testing on the testnet explorer. We could even pre-build snapshots in the genesis block now that we have all the bakers testing addresses.
You can find our full article here on testing:
2 Likes
I think you are right that the registry should allow a baker to specify public information to facilitate their participation in test networks.
It’s an open question whether testnets should leverage the current registry “Reporter Account” or whether we need even more testnet related data in the registry and as you suggest even a “Testnet Baking Account”.
I expect we will make these changes soon after community has a chance to better understand the role of a decentralized baker registry in helping all bakers take control over their data.
1 Like
Hi everyone! We’ve released a CLI tool for the Registry, give it a try 
8 Likes
