# Baker Registry FAQ

**Q: What is the purpose of a baker registry?**

A: There are two primary goals.
* First is to demonstrate a great use case for blockchain -- the sharing of information between independent parties without central control.
* Second is to reduce the friction/cost for bakers and aggregators by helping the bakers to more easily communicate timely updates to their policies and status.

**Q: How does it work?**

A: The core component is a smart contract that keeps each baker's public information in its storage. Each baker will add themselves by calling the contract from their baker account specifying their information as a parameter.

**Q: What if someone else tries to update my information?**

A: The contract will require that an update to change the data for a given baker account be sent from that account; this means that you must be in possession of the private key for that account in order to call the contract to update the data.

**Q: What if I don't want to use my baker account private key to call a contract?**

A: The contract will allow you to specify an alternative account which is allowed to update your information. This way you can keep your baker account key more secure by not using it for any additional operations. But the very first time you call the Baker Registry contract you must do it from your baker account in order to specify your alternative account. After you have done this, you can perform all actions by calling the contract from your alternative account.

<!-- Q: How do I call the contract and specify the parameters?

A: For security you are expected to always be in control of your keys. In addition to a smart contract, there will be a related web app. This web app will never need your keys and is not a wallet to hold your keys. The web app will only provide you with a simple interface to query the contract storage in order to retrieve your current data in its storage. Using the app you will be able to edit your data and then the app will generate the command text and parameters that you will need to call the contract from the Tezos client or from any other wallet of your choice that supports parameters. -->

**Q: Why would this be better than what we do today?**

A: By utilizing the Tezos blockchain we remove the unecessary and time consuming work that both bakers and listing services currently need to do to communicate any changes to policy and status. As the number of bakers and listing services continues to grow this will be increasingly costly and is error prone when having to update multiple systems. But this does not remove the need for listing services, it just removes some of the work. The listing, ranking, and auditing services will still provide value through offchain proprietary analysis, marketing, and helping the community to validate the baker policy.

**Q: What is left to do to make this ready for use?**

A: The registry now exists on the mainnet. Due to limitations in the origination operation size it was pre-populated with 103 bakers. All bakers should go to the web interface and lookup their baker pkh; if you are already in the registry then verify the existing data and add any missing information. If you you are not in the registry then add yourself as a new baker. If you have any questions ask them on Agora.

We need to get the bakers, listing services, audit services, and indexers to provide feedback on the currently implemented baker data schema shown below.
1. Bakers need to confirm that the schema correctly defines all the data they want to communicate publicly
2. Listing and Ranking Services need to confirm that the schema captures all the data they need to provide their services
3. Audit Services need to confirm that the schema captures all the data needed to accurately audit historical payouts according to the specified split/payout information at that time.
4. Indexer Providers need to confirm that the proposed schema is a good fit for indexing and API inclusion (especially for historical analysis by audit services)

We should also start a discussion for the creation of working groups made up of Bakers, Listers/Rankers, Auditors, and Indexers to have a voice in evolving the standards related to the data schema, its associated meta data for auditing/indexing, and APIs that will be used by other parties such as wallets. As baker business models evolve and especially as the protocol amends we will all need to work together to keep these standards, APIs, and tools up to date.

**Q: Why does the schema no longer have a fee model. What is a split?**

A: There was discussion in the community about how it is best to have the registry use terminology that most aligned with how the protocol functions. In the Tezos protocol the rewards belong to the baker. At no point does the baker custody the funds of another entity. The baker makes an offchain agreement to pay the delegator for the act of delegating to the baker. This payment is described in the current schema as a split of the reward calculation. So, for example, rather than charging a fee of 10% and implying custody, the more accurate description is that the baker pays a 90% split for the delegation. Over time we might decide that there is need to add a "fixedPaymentForDelegation" field, but that is why we want to have the ecosystem start using the registry so we can learn and determine the best way forward.

The current proposed baker data schema has 2 components. The **onchain** baker split/payout information which includes a link to the **offchain** additional baker details data.

**On Chain:(updated 13 Nov 2019)**

{
"bakerName": "Baker Public Name",
"bakerAccount": "Bakers account that users set as delegate",
"reporterAccount": "Optional account which can also submit changes to the bakers data, it's a security feature to limit the need for baker to use their primary key to submit subsequent changes to their onchain data",
"openForDelegation": true,
"bakerOffchainRegistryUrl": "link to where the baker stores the json document with offchain info",
"bakerRegistryLastUpdated": 2019-05-23T18:25:43.511Z,
"paymentModel" : {
    "bakerPaysFromAccounts": ["payout account 1 address", "payout account 2 address"],
    "split": 0.90,
    "minDelegation": 0.5,
    "subtractPayoutsLessThanMin": true,
    "payoutDelay": 6,
    "payoutFrequency": 1,
    "minPayout": 0,
    "subtractRewardsFromUninvitedDelegation": true,
    "bakerChargesTransactionFee": true,
    "paymentConfig": {
        "payForOwnBlocks": true,
        "compensateMissedBlocks": false,
        "payForStolenBlocks": true,
        "payForEndorsements": true,
        "compensateMissedEndorsements": false,
        "compensateLowPriorityEndorsementLoss": false,
        "payGainedFees": true,
        "payForAccusationGains": true,
        "subtractLostDepositsWhenAccused": true,
        "subtractLostRewardsWhenAccused": true,
        "subtractLostFeesWhenAccused": true,
        "payForRevelation": true,
        "subtractLostRewardsWhenMissRevelation": true,
        "subtractLostFeesWhenMissRevelation": true
    }
}
}

**Off Chain:**

{
	"signupRequired": false,
	"country": "USA",
	"website": "Bakers website URL that will be called directly as is, e.g. bakenrolls.com",
	"bakerDescription": "Text to describe bakers details, 280 character limit",
	"nonStandardPaymentDescription": "Optional text to describe the split/payouts if baker is using a non standard approach",
	"upcomingPaymentModelDescription": "Optional text to describe future plans to modify split/payouts e.g. In cycle 200 our split is changing from 90% to 85%",
	"branding": {
		"logo256":"https://atticlab.net/atticlab-logo-256.png",
		"logo1024":"https://atticlab.net/atticlab-logo-1000.png",
		"logoSvg":"https://atticlab.net/atticlab-logo-1000.svg"
	},

	"support": {
		"email": "[e-mail]",
		"supportUrl": "link to get support"
	},
	"projects": [{"projectName": "first project name", "projectUrl": "link to project"},
		{"projectName": "second project name", "projectUrl": "link to project"}],
	"social": {
		"twitter": "twitter link",
		"telegram": "telegram link",
		"reddit": "reddit link",
		"riot": "riot link",
		"youtube": "youtube link",
		"keybase": "keybase link"
	},
	"team": [{"teamMemberName": "first and last name1", "teamMemberProfile": "url for profile/linkedIn", "teamMemberImageUrl": "url for image"},
		{"teamMemberName": "first and last name1", "teamMemberProfile": "url for profile/linkedIn", "teamMemberImageUrl": "url for image"}]	
}

**Q: Will this be open source?**

A: Yes. All associated code (which includes the smart contract, a web app, and a library to call and parse the contract storage) will be released fully open source.

**Q: What is being done to prevent spam?**

A: The contract will require an additional amount of "dues" with each call to the contract by a baker. Currently the first version of the Registry on mainnet will set the dues to 1.5 xtz to signup a new baker and 0.5 xtz for each subsequent update. These dues are considered a donation to the Tezos Commons Foundation. Once the final version of the contract is deployed it is expected that the community will help TCF decide the appropriate amount of dues to require.

**Q: Who will originate the contract?**

A: TCF (Tezos Commons Foundation) will use the open source code to originate the contract. As the contract owner TCF will have the following contract capabilities:
* Update the dues amount required for baker signup and data updates.
* Transfer all the previously paid dues to TCF.

<!-- Q: What are payoutModels?

A: Currently have only 2 but likely need to determine with bakers/verifiers how they want to model additional parameters and plan for future flexibiity.

payoutModel = 1 is Dynamic (the currently most common)
payoutModel = 2 is Fixed (example of CryptoDelegate paying exactly the global inflation rate) -->

**Q: What if a baker provides inaccurate data?**

A: Much like today, if a baker misrepresents their status or policy it is up to the Tezos community to identify these mistakes and communicate clearly to the baker that this behavior is not acceptable. The listing services will play a fundamental role in validating the truthfulness of a baker as they do today. The difference is that with the data now recorded onchain in a contract we have an immutable ledger of the data updates.

**Q: What if a baker signs up using my name or something similar?**

A: This is another example of inaccurate data as described above. It will be up to the Tezos community, with the help of listing services, to denounce this behavior. Much like today, the listing services will ultimately decide what data they will display on their websites. The contract just makes it easier for them to retrieve a reliable and updated source of baker information. **Note:** The baker registry is not intended to be a general purpose Tezos Name Service (TNS). Such a service is actively being discussed in the community and if a TNS is launced then the registry will adopt the TNS.