> For the complete documentation index, see [llms.txt](https://docs.railgun.org/wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.railgun.org/wiki/rail-token/protocol-governance.md).

# Decentralized Protocol Requests

How RAILGUN's on-chain protocol request process and treasury distribution work, including why treasury funds never pass through a developer wallet.

<figure><img src="https://4189133001-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MgpI5FGDnzf3cR6tzx7%2Fuploads%2FgDnIGje0G8GDiXF2srcv%2Fimage.png?alt=media&#x26;token=ac850db4-429f-4c43-9251-c8c84c275c6a" alt=""><figcaption></figcaption></figure>

## **How do protocol requests work?** <a href="#id-1c2c" id="id-1c2c"></a>

RAILGUN protocol requests are decentralized, any wallet that locks RAIL can evaluate and submit protocol requests. For all stages, RAIL staked determines the value of the stakers' evaluations, and snapshots  are taken at each stage. RAIL can also be delegated to another wallet, however the associated rewards will be accrued by the wallet to which RAIL is delegated.

Protocol requests come in the form of code changes to the smart contracts and anyone with enough technical expertise can write and submit code. Decision making rests with the community of stakers who determine whether or not to accept proposed changes.&#x20;

Any change to the smart contracts (including the governance, treasury, and voting contracts) requires the passing of a protocol request. The decentralized protocol request system is the only way in which upgrades to the RAILGUN protocol can be made.

## How the Treasury Moves

Treasury funds never pass through a developer or team wallet, during an upgrade or otherwise. Protocol deductions (0.25% on shield and unshield interactions) are sent directly on-chain to the treasury contract for that network. Distribution to RAIL stakers happens autonomously, on a fixed schedule, via the treasury and staking contracts. No multisig or team signer is in that path. Changing any of it, including the treasury contract itself, requires a passed on-chain protocol request, exactly like any other protocol upgrade.

## **Potential Protocol Request Topics** <a href="#ed33" id="ed33"></a>

There are no subject matter limitations on the decentralized governance system and every staker is entitled to submit a protocol request on any code changes.

For example:

* Protocol upgrades to the smart contracts
* Deploying RAILGUN on additional blockchains that allow for smart contracts
* Protocol deductions
* Distributing treasury tokens

## **Protocol request stages** <a href="#a48e" id="a48e"></a>

### **Request Initiation**

Governance begins with a protocol request being written up containing:

* Title
* Document
* Description
* Code actions to execute

The staker must pay a small gas fee to submit a proposal in order to prevent spam.

### **Sponsorship**

After submission, a 30-day Sponsorship Period begins where the request must reach a value determined by the smart contract.&#x20;

To prevent proposal spam, stakers can only sponsor 1 protocol request in a time period determined by the smart contracts.&#x20;

If a proposal does not reach the required value within the 30-day window, it has failed.

Sponsorship is a period that enables the stakers to properly analyze any proposal’s value, feasibility and solidity, by engaging the full spirit of open-source, whilst filtering out unusual or unpopular proposals without needing a full quorum. This period and its structure also ensure that proposals that pass result in the best outcomes.

### **Call to Evaluate**

If a proposal succeeds in sponsorship, then anyone can call it to be evaluated by executing an interaction on-chain. This must be done within 30-days of the protocol request going live or the proposal will become stale and unable to be executed.&#x20;

### **Review**

Sponsored protocol requests are held for a period determined by the smart contract to give stakers  time to evaluate.

### Evaluation

At this stage, stakers can evaluate the protocol request and determine whether it should be executed.  The time period for evaluation is determined by the smart contract.

### **Veto**

After evaluation, there is an additional veto period where stakers can decide to reject the protocol request.&#x20;

The quorum is determined by the values in the smart contract.&#x20;

If quorum is reached the protocol request is passed.

### **Execution**

After the evaluation and veto periods end, an Execution Window opens. For the proposal to take effect, any wallet can call the execution. This must be done within a time period detemined by the contract from the end of the veto period or the proposal will become stale and unable to be executed.

Executing a protocol request initiates the smart contract functions from the proposal. If there are errors in the code, then no changes will occur, and the request will need to be rewritten and resubmitted.