# GIP-0027: Create altruistic allocations and close stale allocations

**URL:** <https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217>\
**Category:** Graph Improvement Proposals (GIP)\
**Tags:** protocol-gov\
**Created:** [March 28, 2022, 10:49pm UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217 "2022-03-28T22:49:48Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sam](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/sam/32/757_2.png) [@Sam](https://forum.thegraph.com/u/Sam)\
**Post date:** [March 28, 2022, 10:49pm UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/1 "2022-03-28T22:49:48Z")

</div>

This GIP is a collaboration between @ari and myself. It’s focused on providing a (non-penalized) way for the public to close allocations that are expired. It also carves out an exception for Indexers that want to serve queries altruistically.

I will update this thread with a Radicle link once my PR is live.

# Abstract

Provide a mechanism so that indexers can opt-out of indexing rewards by allocating zero tokens to a subgraph. This would be useful for an indexer who wants to altruistically serve queries. In addition, this implementation allows the public to close stale allocations after the max allocation period, however, nobody can close an altruistic allocation.

This GIP arose from the least contentious ideas in this forum discussion: [Rewarded force-close mechanism to eliminate stale allocations - #8 by yondon](https://forum.thegraph.com/t/rewarded-force-close-mechanism-to-eliminate-stale-allocations/2951/8).

# Background

An indexer’s allocation toward a particular subgraph has a maximum allocation period of 28 epochs (i.e., `maxAllocationEpoch`), after which the indexer should close the allocation. If an indexer leaves an allocation open beyond 28 epochs, we call this allocation _stale_.

> The mechanism for closing state allocations after the `maxAllocationEpoch` was introduced to prevent indexers from withholding rewards and never distributing them to delegators. Additionally, it promotes liveness in the protocol state changes that affect other stakeholders’ decisions.

An indexer’s stale allocation is still eligible for indexing rewards. If an indexer were to close their stale allocation (at some point beyond epoch 28) with a non-zero Proof of Indexing (non-zero PoI indicates to the protocol that the Indexer did valid work). However, any delegator can close their indexer’s stale allocation with a zero PoI which indicates to the protocol that it should not distribute indexing rewards for that allocation.

When an indexer’s allocation is closed with a non-zero PoI, then the protocol will calculate the amount of indexing rewards owed to the indexer. The amount of indexing rewards owed to an indexer is proportional to the indexer’s allocated stake relative to the total of all allocated stake on the same subgraph.

The two paragraphs above imply that if an “active” indexer closes an allocation that is less than 28 epochs old (i.e. it is not stale), but there is another indexer with a stale allocation currently open on the same subgraph, then the active indexer will receive less indexing rewards than they would have had the stale indexer not been allocated.

# Motivation

1. Stale allocations affect the stability of the network when an indexer that has a big proportional allocated stake on a subgraph does not keep it active, as other indexers won’t want to allocate if it already has a big allocation. Stale allocations also reduce the speed of how value flows through the protocol, reducing the frequency at which curators and delegators get their share of rewards and fees. Currently, delegators of an indexer are the only ones who can close stale allocations, but this is an unnecessary validation considering that anyone could turn into a delegator, even with the smallest amount of tokens, and then close it. For a summary of the current stale allocation statistics, see the “Allocation Age” histogram here: [https://dune.xyz/abarmat/The-Graph](https://dune.xyz/abarmat/The-Graph).

2. Today, indexers must allocate more than zero tokens. However, indexers might want to index and serve queries on a particular subgraph altruistically by opting out of rewards. Today indexers can serve queries altruistically by presenting an empty PoI on `closeAllocation`, however, this is not efficient because they must still pay Ethereum transaction fees to “refresh” (i.e., close and re-open) their allocations. By allowing altruistic indexers to allocate zero tokens, we can skip all the code paths for updating indexing rewards and provide a huge gas improvement.

# High-Level Description

This GIP proposes to make the following changes:

- Indexers can allocate zero-tokens to a subgraph to advertise they are indexing and serving queries but have opted out of indexing rewards. We call these _altruistic allocations_.

- Even if indexers allocate zero tokens, they are still required to have the minimum stake (currently 100,000 GRT).

- Altruistic allocations cannot be closed after the `maxAllocationEpoch` by the public - only by the indexer or the indexer’s operator.

- Anyone can now close an indexer’s allocation after the `maxAllocationEpoch`.

# Implementation

> <https://github.com/graphprotocol/contracts/pull/549>
>
> Supersedes: https://github.com/graphprotocol/contracts/pull/543
> 
> \### Goal
> 
> P…rovide a mechanism so that indexers can opt-out of rewards by allocating zero tokens to a subgraph. In addition, this implementation allows anyone to close stale allocations after the max allocation period, however, nobody can close an altruistic allocation.
> 
> \### Motivation
> 
> 1) Stale allocations affect the stability of the network when an indexer that has a big proportional allocated stake on a subgraph does not keep it active, as other indexer won't want to allocate if it already has a big allocation. Stale allocation also reduce the speed of how value flows through the protocol, reducing the frequency at which curators and delegators get their share of rewards/fees. Currently delegators for an indexer are the only one that can close them, but this is an unnecessary validation considering that anyone could turn into a delegator, even with the smallest amount of tokens, and then close it.
> 
> \> The mechanism for closing state allocations after the \`maxAllocationEpoch\` was introduced to avoid indexers holding off rewards forever and never distributing them to delegators. Additionally, it promotes liveness in the protocol state changes that effect other stakeholders decisions.
> 
> 2) Indexers might want to index and serve queries on a particular subgraph altruistically by opting out of rewards. Today they can effectively do that by presenting an empty POI on closeAllocation, however this is not the most efficient way to do it. By allowing them allocating zero tokens, we can skip all the code paths for updating rewards getting a huge gas improvement.
> 
> \### Highlight
> 
> \- Indexers can allocate zero-tokens to a subgraph to advertise they are indexing and serving queries but opted out of rewards.
> \- Even if indexers allocate zero token they are required to have the minimum stake.
> \- Altruistic allocations cannot be closed after the \`maxAllocationEpoch\` by the public, only by indexer or operator.
> \- Anyone can now close a standard allocation after the \`maxAllocationEpoch\`.
> 
> \# Gas Efficiency
> 
> Altruistic allocations are roughly 50% more gas efficient because the contract doesn't need to recalculate rewards snapshots.
> 
> \*\*Standard Allocation\*\*
> \`\`\`
> | Staking · allocate · 277077 │
> | Staking · closeAllocation · 233146 │
> \`\`\`
> 
> \*\*Zero Allocation\*\*
> \`\`\`
> | Staking · allocate · 144355 │
> | Staking · closeAllocation · 129128 │
> \`\`\`
> 
> \### Reference
> 
> Forum: https://forum.thegraph.com/t/rewarded-force-close-mechanism-to-eliminate-stale-allocations/2951/8

# Copyright Waiver

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

---

<div class="post-metadata">

**Author:** ![Brandon](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/brandon/32/1265_2.png) [@Brandon](https://forum.thegraph.com/u/Brandon)\
**Post date:** [April 14, 2022, 3:36am UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/2 "2022-04-14T03:36:40Z")

</div>

I’m still in favor of some of the more contentious options in the linked thread 😉 My main concern with this approach it still requires someone to eat the cost of closing the allocation on the Lazy Indexer’s behalf.

That being said, this seems like a reasonable first step, to evaluate the impact of before introducing anything more complex.

---

<div class="post-metadata">

**Author:** ![That3Percent](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/that3percent/32/62_2.png) [@That3Percent](https://forum.thegraph.com/u/That3Percent)\
**Post date:** [June 4, 2022, 11:05pm UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/3 "2022-06-04T23:05:42Z")

</div>

I think we should move forward with this GIP, regardless of where we go with rewarded force-closes or when. Altruistic allocations are an orthogonal concern.

---

<div class="post-metadata">

**Author:** ![DataNexus](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/datanexus/32/1830_2.png) [@DataNexus](https://forum.thegraph.com/u/DataNexus)\
**Post date:** [June 8, 2022, 6:13pm UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/4 "2022-06-08T18:13:40Z")

</div>

Just posting here to show agreement.

---

<div class="post-metadata">

**Author:** ![Oliver](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/oliver/32/631_2.png) [@Oliver](https://forum.thegraph.com/u/Oliver)\
**Post date:** [June 9, 2022, 10:47pm UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/5 "2022-06-09T22:47:38Z")

</div>

This proposal has advanced in the governance process and has been approved by the Council: [Snapshot voting](https://snapshot.org/#/council.graphprotocol.eth/proposal/0xd64e523713a05682f6cef9bfaf7fb340dde3396aeb1fe16d6ec5c1e1eaa7dd1e)

---

<div class="post-metadata">

**Author:** ![ari](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/ari/32/2747_2.png) [@ari](https://forum.thegraph.com/u/ari)\
**Post date:** [August 15, 2022, 4:33am UTC](https://forum.thegraph.com/t/gip-0027-create-altruistic-allocations-and-close-stale-allocations/3217/6 "2022-08-15T04:33:59Z")

</div>

The Council executed transaction `0xcdda6d13bb9adf50aa204a98256fe2e019b5ef9504f997a3d60ef961f4ac63f4` on Mainnet Ethereum to upgrade the **Staking** contract to implementation `0x0Cf97E609937418eBC8C209404B947cBC914F599`. It enables the **Altruistic Allocations** feature, allowing indexers to create zero-token allocations, which are much more gas-efficient but have the effect of effectively opting out of any rewards. In addition, anyone can now close stale allocations after the max allocation epoch, previously could only be done by delegators.
