# GIP-0060: Early allocation closure

**URL:** <https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559>\
**Category:** Graph Improvement Proposals (GIP)\
**Created:** [September 28, 2023, 3:30am UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559 "2023-09-28T03:30:20Z")\
**Posts on this page:** 9\
**Page:** 1

<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:** [September 28, 2023, 3:30am UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/1 "2023-09-28T03:30:20Z")

</div>

> GIP: “0060”  
> Title: Early allocation closure  
> Authors: Ariel Barmat [ariel@edgeandnode.com](mailto:ariel@edgeandnode.com)  
> Created: 2023-09-25  
> Updated: 2023-09-25  
> Stage: Draft  
> Category: Protocol Change  
> Dependency: GIP 0051

# Abstract

The protocol imposes over indexers a restriction to wait for at least one epoch must pass before they can close allocations. We propose removing it and allowing them to manage allocations as they see more convenient.

# Motivation

The protocol relies on a Rebate mechanism to ensure that indexers assign a security deposit in GRT proportional to the amount of queries they serve. Before the Exponential Rebate upgrade, it worked by summing all the query fees collected and stake allocated in one pool per epoch in which allocations are closed. As a consequence, it was essential to ensure that allocations last for at least one epoch to calculate the rebates using the Cobbs-Douglas function.

Coordination issues arises when a subgraph developer publishes a subgraph versions multiple times within the span of an epoch. Indexers would allocate to the first version and won’t be able to unlock their stake for use on the second version until the epoch ends reducing the network flexibity and liveliness. This condition might present more often on the L2 because transactions are cheaper and potentially more frequent.

With the introduction of GIP-0051 the rebate formula is now continuous and the pools were removed which opens the possibility of implementing this proposal.

# Specification

The following lines will need to be removed from the `closeAllocation()` function of the `Staking` contract.

```auto
// Validate that an allocation cannot be closed before one epoch
uint256 epochs = MathUtils.diffOrZero(alloc.closedAtEpoch, alloc.createdAtEpoch);
require(epochs > 0, "<epochs");

```

The `effectiveAllocation` parameter that depended on the `closedEpochAt` variable does not longer exist since the Exponential Rebates upgrade, however, we still store `closedEpochAt` to mark the allocation as closed.

### Indexing Rewards

Indexing rewards could still be collected in this proposal because the calculation is performed at the block number level. However, because presenting a valid POI depends on the Epoch Block Oracle for some chains and indexers won’t have the information after an epoch, we recommend setting the POI=0x0 or enforce a restriction on distributions directly in the code:

Calculate the epoch diff:

```auto
uint256 epochsDiff = MathUtils.diffOrZero(alloc.closedAtEpoch, alloc.createdAtEpoch);

```

And then change the rewards distribution section to:

```auto
// Distribute rewards if proof of indexing was presented by the indexer or operator
if (isIndexer && _poi != 0 && epochDiff > 0) {
  _distributeRewards(_allocationID, alloc.indexer);
} else {
  _updateRewards(alloc.subgraphDeploymentID);
}

```

# Backwards Compatibility

The change keeps the current interfaces and is backward compatible. Indexer will be able to close their allocations on the same epoch they opened them immediately after governance approves the upgrade.

# Copyright Waiver

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

---

<div class="post-metadata">

**Author:** ![cryptovestor](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/cryptovestor/32/29_2.png) [@cryptovestor](https://forum.thegraph.com/u/cryptovestor)\
**Post date:** [September 28, 2023, 3:00pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/2 "2023-09-28T15:00:02Z")

</div>

Thanks for putting this together @ari 🤝

I’m in support of this proposal from the perspective of a typical Indexer that strives to be attentive and wants to support consumers by upgrading to their new subgraph version as soon as possible. It is quite common for an initial subgraph deployment to be upgraded very quickly due to some sort of issue identified after deployment. This can incur significant costs and operational management for an Indexer.

Now that transaction fees are greatly reduced, an Indexer is more likely to keep moving to the latest subgraph version and provide service continuity, whereas in the past they may, in a worst case scenario, just give up serving the subgraph if the deployer upgrades very frequently (because it resulted in significant transaction costs for the Indexer).

I’m in support of this proposal from the perspective of the Consumer that needs prompt service on their updated subgraph.

Does anyone have any more thoughts on whether this opens up any potential for gaming the rewards system? I cannot think of any scenarios off the top of my head, but that would be the one area I’d want to be confident about for this proposal to be considered.

---

<div class="post-metadata">

**Author:** ![haupinax](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/haupinax/32/2896_2.png) [@haupinax](https://forum.thegraph.com/u/haupinax)\
**Post date:** [September 29, 2023, 8:57am UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/3 "2023-09-29T08:57:56Z")

</div>

This could prove to be extremely useful, especially in a situation when new subgraphs are released, subgraphs version gets updated the next minute, resulting in allocations getting stuck in the deprecated version of the subgraph until the next epoch.

As of now, I couldn’t identify any potential opportunities for rewards to be gamified.

---

<div class="post-metadata">

**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\
**Post date:** [January 4, 2024, 5:54pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/4 "2024-01-04T17:54:45Z")

</div>

An initial implementation of this GIP can be found here: [feat: remove minimum allocation duration restriction by tmigone · Pull Request #902 · graphprotocol/contracts · GitHub](https://github.com/graphprotocol/contracts/pull/902)

One thing worth noting: in accordance with the GIP this implementation will not distribute rewards when an allocation that is less than 1 epoch old is closed, even if the POI presented is valid. There are some edge cases where this could happen with subgraphs indexing Ethereum mainnet or Arbitrum One, however for simplicity and consistency we won’t be distributing rewards in this case.

For clarity, in order to get rewards the conditions that have to be met are:

- the indexer or operator is closing the allocation
- a valid POI is presented when closing the allocation
- the allocation is at least 1 epoch old (i.e `startEpoch < endEpoch`)

---

<div class="post-metadata">

**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\
**Post date:** [April 22, 2024, 8:42pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/6 "2024-04-22T20:42:41Z")

</div>

Hey, wanted to provide a quick update regarding this GIP. It’s now been deployed to our testnet on Arbitrum Sepolia, it’s now pending review from the Graph Council and it will be ready for deployment on Arbitrum One (note that we won’t be deploying this upgrade to the protocol on Ethereum Mainnet).

Some links with further information:

- [Implementation PR](https://github.com/graphprotocol/contracts/pull/902)
- [Audit by OpenZeppelin](https://github.com/graphprotocol/contracts/blob/2663ae3d75d7d93a7b4d93b02f5262b5f3b37a92/packages/contracts/audits/OpenZeppelin/2024-02-graph-availability-manager-minimum-allocation-removal.pdf)
- [Deployment plan](https://edgeandnode.notion.site/Early-allocation-closure-deployment-plan-dc2fd9153cfb4284aba1961258436b49)
- [Test plan](https://edgeandnode.notion.site/Early-allocation-closure-test-plan-6e4b97b879ea44048846d774efcbe15d)

---

<div class="post-metadata">

**Author:** ![tmigone](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/tmigone/32/1398_2.png) [@tmigone](https://forum.thegraph.com/u/tmigone)\
**Post date:** [May 13, 2024, 5:39pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/7 "2024-05-13T17:39:57Z")

</div>

Contracts were upgraded on Arbitrum One with the changes from this GIP here: [Arbitrum Transaction Hash (Txhash) Details | Arbiscan](https://arbiscan.io/tx/0xce316bd3cb26d71c81279c571cc4ef262f30588f7e3744ea38a86e2bf97340d9)

Latest indexer agent still does not allow closing allocations until one epoch has passed, but we’ll release a new version removing the restriction soon. I’ll post here once that’s ready.

---

<div class="post-metadata">

**Author:** ![indexer\_payne](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/indexer_payne/32/44_2.png) [@indexer\_payne](https://forum.thegraph.com/u/indexer_payne)\
**Post date:** [May 13, 2024, 5:43pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/8 "2024-05-13T17:43:21Z")

</div>

AYYY LETS GO 🚀 🚀 thanks a lot for getting this on mainnet 🙏

---

<div class="post-metadata">

**Author:** ![haupinax](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/haupinax/32/2896_2.png) [@haupinax](https://forum.thegraph.com/u/haupinax)\
**Post date:** [May 14, 2024, 8:04am UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/9 "2024-05-14T08:04:40Z")

</div>

Thank you so much ! This is extremely useful 🙏

---

<div class="post-metadata">

**Author:** ![suntzu](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.thegraph.com/suntzu/32/1815_2.png) [@suntzu](https://forum.thegraph.com/u/suntzu)\
**Post date:** [May 18, 2024, 10:39pm UTC](https://forum.thegraph.com/t/gip-0060-early-allocation-closure/4559/10 "2024-05-18T22:39:28Z")

</div>

finally, this feature is released, thank you.