# VoteVara Historical Translation Policy
## Purpose
VoteVara translates Vara governance without telling users how to vote. A
historical translation explains what voters were asked to approve, what the
chain was authorized to do, what occurred afterward, and what cannot be
established from the surviving record.
## Non-negotiable distinctions
Every record keeps these categories separate:
- **On-chain fact:** directly verifiable from Vara state or events.
- **Proposal claim:** stated by the proposer or supporting materials.
- **Third-party statement:** attributed to a named outside source.
- **VoteVara calculation:** reproduced from disclosed source fields and formulae.
- **VoteVara explanation:** plain-language interpretation of verified facts.
- **Inference:** a reasoned conclusion that is explicitly labeled as such.
- **Unknown:** information the available record does not establish.
## Source priority
1. Vara chain state, events, runtime metadata, calls, and preimages.
2. Contemporaneous Vara documentation and published runtime parameters.
3. Subsquare's indexed chain data and preserved proposal discussion.
4. Proposer materials and attributable participant statements.
5. Independent reporting and later retrospective material.
Source precedence does not make an interpretation true. The encoded call is
authoritative for the on-chain action; it does not independently prove an
off-chain promise was fulfilled.
## Translation rules
- Write the proposal question in past tense and label it retrospective.
- Explain Aye and Nay symmetrically.
- Do not improve an unclear proposal by silently supplying a rationale it did
not contain.
- Preserve the difference between what proposal materials promised and what
the on-chain call could execute.
- Describe `system.remark` as an on-chain record, not as a transfer or command
to an off-chain organization.
- Decode nested batch, proxy, scheduler, whitelist, and dispatch calls through
to the effective inner action whenever the historical metadata permits it.
- If decoding is partial, state the exact limitation.
- Use track parameters and runtime metadata applicable at the referendum's
historical block. Never apply current parameters retroactively.
- Do not assign a person or organization to an address without attributable
evidence. Behavioral resemblance is not identity evidence.
- Do not treat approval as broad participation. Always show participation and
concentration separately when the data exists.
- Preserve VARA as the primary unit. Any fiat conversion must identify its
price source and timestamp.
## Minimum historical translation
Every numbered referendum must answer:
1. What was proposed?
2. What did voting Aye mean?
3. What did voting Nay mean?
4. What exact action could the chain perform?
5. Did that action execute successfully?
6. Was further off-chain action expected?
7. What verifiable outcome followed?
8. What remains unknown?
## Review states
- `imported`: public source material captured, not interpreted.
- `needs-translation`: normalized record exists but prose is unfinished.
- `translated`: minimum translation completed.
- `fact-checked`: calculations, calls, claims, and sources reviewed.
- `published`: approved for the public VoteVara archive.
No imported or machine-produced translation is eligible for publication
without human review.
# VoteVara Archive Data Dictionary
## `identity`
Stable referendum number, preserved source title, public display title, and
canonical VoteVara slug. A display title may be a retrospective VoteVara title;
the original title is never overwritten.
## `classification`
Editorial classification used for navigation and research grouping. It does
not change the referendum's on-chain track or origin.
## `submission`
Proposer, submission block, original proposal body, and discussion location.
Verified identity remains null unless supported by attributable evidence.
## `governance`
Historical track, requested origin, deposits, periods, capacity, and threshold
curves captured for the referendum. These are historical parameters and must
not be replaced with current settings.
## `proposal`
Proposal hash, preimage length, decoded call, nested call path, remark text,
and decode limitations. The encoded call is authoritative for the on-chain
action; proposal prose is not.
## `deposits`
Submission and decision deposits, their depositors, and eventual refund or
slash status when verified.
## `lifecycle`
Final state and ordered on-chain events such as submission, decision start,
confirmation, approval, rejection, cancellation, timeout, and execution.
## `voting`
Weighted Aye/Nay totals, raw capital, support, electorate, address counts,
individual final vote rows, delegation aggregates, and derived concentration
metrics. All balance values contain exact planck strings.
## `execution`
Whether execution was scheduled and attempted, dispatch success or error, and
the observable on-chain state change once independently verified.
## `interpretation`
Retrospective human explanation: summary, Aye meaning, Nay meaning, chain
action, off-chain action, importance, technical detail, and unknowns.
## `accountability`
Promised outcomes compared with later verifiable outcomes. Successful dispatch
does not automatically prove that an off-chain promise was fulfilled.
## `sources`
Source type, public URL, retrieval time, local preserved capture, relevant
block, and qualification notes.
## `editorial`
Review state, reviewers, verification date, corrections, and internal notes.
Imported or draft records must not appear as finished public translations.
# VoteVara Calculation Methodology
## Units
Vara chain balances are stored in planck. The archive preserves every imported
integer as a decimal string and separately supplies its VARA representation.
`1 VARA = 1,000,000,000,000 planck`
Strings are used because JavaScript numbers cannot represent many governance
balances exactly.
## Weighted voting totals
Weighted total:
`weighted Aye + weighted Nay`
Approval percentage:
`weighted Aye / (weighted Aye + weighted Nay) × 100`
Abstain capital is not included in the Aye-versus-Nay approval denominator.
## Raw participation
Raw participation percentage:
`total participating capital / recorded electorate × 100`
This is not described as the percentage of people who voted. Vara governance
is token-weighted and the chain does not supply a human voter registry.
## Concentration
Concentration is calculated across accounts controlling the final direct vote.
Capital delegated to a direct voter is attributed to that direct voter for this
metric. Separate delegator rows are retained in the record but are not counted
a second time.
- Top-one concentration: capital controlled by the largest voting account
divided by total participating capital.
- Top-three concentration: equivalent calculation for the three largest.
- Top-ten concentration: equivalent calculation for the ten largest.
This measures concentration of voting control in the referendum. It is not a
claim that delegated tokens are owned by the delegate.
## Herfindahl–Hirschman Index
The HHI is the sum of squared percentage shares across accounts controlling a
direct vote. The archive uses the conventional 0–10,000 scale.
`HHI = Σ(account capital share² × 10,000)`
Higher values indicate that participating voting capital was controlled by
fewer accounts.
## Gini coefficient
The Gini coefficient is calculated over the participating capital controlled
by direct voting accounts. It ranges from 0 to 1, where 0 is equal distribution
and values approaching 1 indicate greater inequality.
Because only participating accounts are included, this is not a wealth-inequality
measure for Vara as a whole.
## Reconciliation
For every referendum, VoteVara compares the sum of the final vote rows with
Subsquare's recorded total capital. A record is marked `complete` only when the
values reconcile. A mismatch remains visible as `partial` and must be reviewed;
it is never silently forced to agree.