Docs Style Guide

Terminology

The following is the preferred usage of common terms:

• Mina is the network. MINA is the token.
• Use zero-knowledge proof, not zero knowledge proof.
• Use zk-SNARK & zk-SNARKs. Not zk-snarks, etc.
• Use Mainnet, Devnet, Testnet. Not "Main Net", "DevNet", etc.
• Use public key or private key. Not "secret key".
• Use key pair or public/private key pair. Not "keypair", "key-pair", etc.
• Use proof of stake. Not "proof-of-stake", "Proof of Stake", etc. Unless it precedes another word then use, then use hyphens, e.g. proof-of-stake consensus.
• Use zkApp (singular) or zkApps (plural). Casing for this may vary based on the context where it is used. If unsure, please ask.
• Use zkApp CLI or Mina zkApp CLI. Not "zkApp Cli", "Zkapp CLI", etc.
• Use SnarkyJS. Not "snarkyJS", etc.
• Use smart contract to refer to the code written with SnarkyJS. Use zkApp to refer to the UI + the smart contract.
• Use prover function, not "prover". The latter refers to the entity who executes that function.
• Use verifier function, not "verifier". The latter refers to the entity who executes that function; unless you're referring to the Mina protocol, then say "Mina" not "verifier".
• Use Merkle tree, not "merkle tree" or "Merkle Tree".
• Use Merkle mountain range, not "merkle mountain range" or "Merkle Mountain Range".
• Use Berkeley Testnet, not "Berkeley testnet", etc.
• Within the docs, use section to refer to a top-level section such "About Mina".
• Within the docs, use page to refer to individual pages within a top-level section.

Sidebar Capitalization

• Use Title Case--e.g. Protocol Architecture, etc.
• But use sentence casing for phrases--e.g. How to use a zkApp, Install a wallet, etc.

Old glossary terms to discuss/update:

• Keypair (sic) - we need to add space within key pair & update across old docs.
• Zero-knowledge-based or Zero-knowledge based - when to use?

Call Outs

Syntax to use. The headline can be updated. The icon cannot be changed.

• Danger is for security warnings. For example, where failure to take x action could result in a security vulnerability (loss of funds, XSS attack, etc). E.g. "Always validate user-provided data to prevent XSS attacks".

  

• Caution is unused.

  

• Info is for limitations & "must know" information.

  

• Tip is unused.

  

• Note is used for general & "nice to know" information.

  

Graphics

Graphics were created using an iPad, stylus, & Procreate.