## Preamble

```
CAP: 0026
Title: Disable Inflation Mechanism
Author: OrbitLens <orbit.lens@gmail.com>
Status: Final
Created: 2019-07-10
Updated: 2019-09-24
Discussion: https://groups.google.com/forum/#!topic/stellar-dev/LIFvbMi9jPo
Protocol version: 12
```

## Simple Summary

This CAP disables the inflation mechanism.

## Motivation

Inflation mechanism was originally planned as a simple way for users to support important 
ecosystem projects and keep the overall XLM supply slightly inflationary.

- Currently, it doesn’t serve its original purpose, as users mostly prefer to claim the 
inflation payouts through the inflation pools instead of sponsoring ecosystem projects. 
As a result, inflation micropayouts from XLM pools generate a significant validators 
load and clog the network.
- Payouts get more and more resource consuming for validators over time due to the total 
lumens circulation supply increase.
- Once the validators vote for the significant base fee increase, such payouts became much 
less profitable for most lumen holders, and XLM pools will be forced to raise the minimum 
required account balance to more than 1000XLM to cover transaction fee loses.
- Inflation payouts may lead to additional complications in some edge-cases when 
programming smart contracts.
- Inflation deprecation opens new possibilities for the more effective targeted reward 
distributions that require complex logic, like stimulating DEX liquidity providers.

## Abstract

Turning off inflation requires a minor change in Stellar Core, namely `Inflation` 
operation behavior. At the same time, it can be implemented without XDR changes and 
breaking protocol changes.

## Specification

This proposal requires a single Core behavior change. 
Transaction containing `Inflation` operation should always return 
`opNOT_SUPPORTED` result code.

## Design Rationale

The proposed approach does not require breaking protocol changes and allows turning on 
the inflation mechanism in the future if needed. Due to the simplicity of proposed changes, 
the implementation potentially requires minimum efforts. 

## Security Concerns

None.

## Backwards Incompatibilities

This CAP contains no breaking changes and is fully backward compatible.