GIP-00XX Liquid Delegation Tokens

Apologies for formatting (did this on mobile)


This proposal is an informal draft GIP that aims to add additional support for delegators by allowing for transfer of delegation in the form of Liquid Delegation Tokens (LDT).


The Graph (GRT) currently forces a 28 day thawing period on locked delegated tokens before they are transferrable out of an address. This locking mechanism allows for an efficient un-gamable delegation where delegators cannot constantly track which indexers are likely to pay out next, and move their delegation there. If this thawing period was lifted the delegation mechanism would be negatively affected.


LDT’s offer a mechanism similar to liquid staking tokens offered by many decentralized protocols. It allows GRT to have a deeper role in the thriving yield DEFI markets (Indexer-delegation ETF’s, Yield farming, etc.), it allows delegation to be transferred from address to address (move funds immediately upon possible seed phrase exposure), and it continues to enforce the 28 day thawing period currently implemented.

Introducing LDT’s presents an opportunity to widen the use of GRT in DEFI while maintaining delegation integrity. Additionally, it allows for new economies to be build around GRT delegation.

High Level Description

This proposal requires the following additional logic:

1	Introducing LDT's that correlate to individual indexer delegation - ideally in the form of a ERC-20 LD-token
2	Introducing fee architecture for transferred/minted LDT's


Upon delegation to an indexer delegators will have to option to mint a LDT. These LDT’s will follow current industry standards (ERC-20 compatability) [1]. With this approach LDT’s sent from separate addresses can be pooled into a single address without having to keep logic from the initial delegation. This offers the possibility of pooled delegation ETF’s by combining multiple LDT’s into a single address - further developing GRT’s presence in DEFI. These ETF’s can be offered by The Graph - Allowing users to present their ETF’s to the market and collecting a fee set by them. Similar to indexer fee’s. Additionally, this gives indexers who work closely together an opportunity to bundle their efforts together and allocate delegation as they see fit.

LDT Minting Fee

Upon minting the delegator will incur a fee on their current rewards from the indexer. Fee’s will have a max upper boundary and will be set by the indexer. This allows for negative fee’s where indexers can incentivize liquidity for their delegation. See equation example in Pseudocode section.

Detailed Specification


Delegating. Alice deposits tokens to mint curation shares.

1	Alice has M GRT tokens and wants to delegate to X indexer
2	Alice delegates M tokens and mints N LDT's 
3	Alice’s wallet locks M GRT in the delegation contract and receives N LDT’s which are transferrable
4	Alice’s new balance is represented by a fee function they encountered upon minting the LDT:
a	M GRT + M GRT rewards - (M GRT rewards) (mint fee) = N LDT

Transfer. Alice has previously minted LDT trasnfered to a new address.

1	Alice has N LDT and wishes to transfer to a new address P because she fears her seed phrase may be compromised.
2	Alice pays ethereum gas fees for the token transfer to address P
3	Alice's address P now has N LDT balance

Undelegating. Alice burns previously minted shares to receive GRT and begin unlocking delegation.

1	Alice wants to undelegate
2	Alice burns N LDT’s and receives M GRT + M GRT rewards - (M GRT rewards) (mint fee) = S GRT total balance
3	Alice’s S GRT go through the 28 day thawing period
4	After 28 days Alice can remove S GRT

Upgrade Path

This change should be implemented for across the entire protocol.

Backwards Compatibility

This proposal will be a major update to delegating and core code changes will be introduced.


This proposal relies on modifications to current delegation framework.

Risks and Security Considerations

Fund Centralization

A possible risk is centralization of funds if certain ETF’s gravitate the majority of market shares. Similar to gravitation of LIDO’s stETH, though this does not pose security risks to the protocol.


The changes introduced here should go through a smart contract audit and receive community feedback, with special focus on Delegators, Subgraph Developers and Indexers.

Rationale and Alternatives

Transfer Fee

Transfer Fee’s can be introduced and actively changed to meet current market conditions & incentives. If GRT wants to influence higher LDT holdings they can lower fee’s or vise versa.

Copyright Waiver

Copyright and related rights waived via CC0.


[1] ERC-20 Token Standard |


Is it absolutely necessary to do this within the protocol or is there some downside to doing it extra-protocol?

1 Like

Great to see this proposal, thanks @Synthquest.

Liquid derivatives have enormous utility as collateral and in supporting a secondary-market for in-protocol assets. This value added utility has network effects, and drives capital to a power law distribution of issuers (i.e. the big player wins).

This can be concerning because it centralises GRT in an extra-protocol layer that is likely governed by a token other than GRT (and therefore a different set of stakeholders). This could create some level of systemic risk for the protocol (censorship risk, hack risk, etc).

I think extra-protocol liquid derivative wrappers are an inevitable outcome for protocols that do not issue a native derivative. Given the risks above, I see good reason for the protocol to issue derivatives natively.

1 Like

Chris’s response about contract risk and gravitation of funds is great.

Id also like to add that functional use (trading/selling, perpetuals on LDT’s?, etc) would all most likely take place in an external protocol. The LDT’s ideally are issued by theGraph as it would make building around it much easier among many other things - Single point of contacts, less contract interactions, user experience simplicity. . .