> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

# Governance

Notareum governance is designed to transition from foundation stewardship to full community ownership over three years. The native mechanism is vote-escrowed NOTA (veNOTA): locking NOTA for longer periods grants proportionally greater voting power, aligning governance with long-term commitment rather than short-term token holdings. This page covers the NOTA token properties, the veNOTA lock mechanism, governable parameters, and the progressive decentralization roadmap.

## NOTA token

The `NotareumNOTAToken` is an ERC-20 token with votes, permit, and burnable extensions.

| Property       | Value                                                 |
| -------------- | ----------------------------------------------------- |
| Name           | Notareum                                              |
| Symbol         | NOTA                                                  |
| Decimals       | 18                                                    |
| Initial supply | 1,000,000,000 NOTA                                    |
| Extensions     | ERC20Votes, ERC20Permit, ERC20Burnable, ERC20Pausable |

The initial supply is minted to the deployer at construction. Additional minting is possible via `mint(address, uint256)` restricted to `ROLE_OPERATOR`, enabling goal-oriented distribution tied to KPIs. See [\$NOTA Token](../token/nota-token.md) for the full economic design.

## veNOTA vote-escrow

`NotareumVeNOTA` is an ERC-721 contract where each locked position is an NFT.

```mermaid theme={"system"}
flowchart LR
    A[Lock NOTA] --> B{Duration}
    B -->|91 days minimum| C[Low voting power]
    B -->|~1.5 years| D[Medium voting power]
    B -->|4 years maximum| E[10x voting power]
    C --> F[veNOTA NFT]
    D --> F
    E --> F
    F --> G[Time-decays to 0 at expiry]
```

### Lock parameters

| Parameter                 | Value                |
| ------------------------- | -------------------- |
| Minimum lock duration     | 91 days              |
| Maximum lock duration     | 1,461 days (4 years) |
| Maximum voting multiplier | 10x                  |

### Creating a lock

```solidity theme={"system"}
function createLock(uint256 amount, uint256 duration) external returns (uint256 tokenId);
```

* `amount`: NOTA to lock (MUST be > 0).
* `duration`: lock duration in seconds (91 days to 1,461 days).
* Returns an ERC-721 token ID representing the lock position.

### Voting power formula

Voting power decays linearly as the lock approaches expiry:

```
votingPower(tokenId) = amount * timeRemaining * MAX_MULTIPLIER / MAX_DURATION
```

Where `timeRemaining = lockEnd - block.timestamp` (0 if expired). At maximum lock (1,461 days): `votingPower = amount * 10`. At minimum lock (91 days): `votingPower ≈ amount * 0.062`. At expiry: `votingPower = 0`.

### Managing lock positions

* `increaseLockAmount(tokenId, amount)`: Add more NOTA to an existing lock.
* `extendLock(tokenId, newDuration)`: Extend lock end time. New end MUST be later than current.
* `withdraw(tokenId)`: Withdraw NOTA after lock expiry. Burns the NFT.

Only the NFT owner may modify or withdraw a position.

### Example

```typescript theme={"system"}
const amount = 100_000n * 10n ** 18n;
const duration = 365 * 24 * 60 * 60;  // 1 year in seconds

await ntm.governance.approveNotaForLock(amount);
const tokenId = await ntm.governance.createLock(amount, duration);
const votingPower = await ntm.governance.getVotingPower(tokenId);
console.log("Voting power:", votingPower);

await ntm.governance.extendLock(tokenId, 2 * 365 * 24 * 60 * 60);  // extend to 2 years
```

## Governance parameters

Parameters are organized into three categories by sensitivity.

### Category A: Critical

Require veNOTA supermajority plus a timelock. Include quorum sizes, approval thresholds, minimum stake requirements per tier, unbonding period duration, and maximum burn rate. These are the parameters that define the security model of the protocol.

### Category B: Economic

Require veNOTA majority. Include active burn rate, treasury rate, alias registration fee, and verification fees per level. These control the token economics and protocol revenue.

### Category C: Operational

Require `ROLE_PROTOCOL_ADMIN`. Include treasury address, burn address, fee collector address, and contract pause/unpause. These are administrative parameters requiring fast execution.

## Access control roles

All privileged operations are gated through `NotareumAccessManager` with seven named roles.

| Role ID | Name                       | Description                                 |
| ------- | -------------------------- | ------------------------------------------- |
| 0       | `ROLE_ADMIN`               | Root admin; manages all roles               |
| 1       | `ROLE_PROTOCOL_ADMIN`      | Protocol configuration                      |
| 2       | `ROLE_FEE_MANAGER`         | Fee collection and distribution             |
| 3       | `ROLE_SLASHING_ARBITRATOR` | Dispute resolution                          |
| 4       | `ROLE_TREASURY`            | Treasury management                         |
| 5       | `ROLE_PAUSER`              | Emergency pause                             |
| 6       | `ROLE_OPERATOR`            | Verification engine, staking record keeping |

## Progressive decentralization

Governance follows a three-phase roadmap.

**Year 1: Foundation Leadership.** Foundation multisig holds `ROLE_ADMIN` and `ROLE_PROTOCOL_ADMIN`. veNOTA voting is used for signaling and non-binding community feedback. Core contracts are audited and deployed.

**Year 2: Hybrid Governance.** `ROLE_PROTOCOL_ADMIN` operations require a passing veNOTA governance vote followed by Foundation multisig execution. Category B parameters are governed on-chain. Community earns influence as token distribution broadens.

**Year 3+: Full Decentralization.** Community-elected councils hold administrative roles. A Governor contract holds `ROLE_PROTOCOL_ADMIN`. Foundation retains only an emergency multisig veto. All Category A and B changes flow through community governance.

## Timelock

All governance-controlled Category A and B parameter changes SHOULD be subject to a minimum 48-hour timelock before execution. This gives the community time to review and coordinate responses to potentially harmful governance proposals before they take effect.

## Security considerations

**Plutocracy risk.** The 10x multiplier for long-term lockers gives disproportionate power to whale stakers. The protocol SHOULD implement voter participation thresholds and quorum minimums.

**Governance attack window.** The 14-day unbonding period limits how quickly an attacker can acquire then exit validator stake after a governance attack. Lock periods from 91 days to 1,461 days further commit voting capital.

**Timelock.** All Category A and B changes SHOULD have a minimum 48-hour timelock before execution.

## Related pages

* [\$NOTA Token](../token/nota-token.md) for the token overview
* [veNOTA](../token/venota.md) for lock mechanics and examples
* [Fee Model](fee-model.md) for governable fee parameters
* [Security](security.md) for the governance threat model
* [Participating in Governance guide](../guides/participating-in-governance.md)