Grace period after maxAllocationEpochs on closeAllocation by delegator
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- solidity
- Área
- blockchain
Línea de trabajo
Comienza revisando closeAllocation() y el comportamiento existente de maxAllocationEpochs descrito en el issue. Determina cómo un período de gracia separaría las penalizaciones leves de las severas y documenta la decisión y cualquier cambio de contrato necesario; el issue se completa cuando se acuerdan el comportamiento y el alcance.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
closeAllocation() is the function that allows unallocating tokens assigned to a particular subgraph and eventually collecting all funds from state channels.
To avoid an indexer never closing an allocation and as a consequence never distributing the funds, we allow delegators to force close an allocation after maxAllocationEpochs.
An indexer would want to close the allocation before maxAllocationEpochs. It has two incentives to do so:
- Effective allocation stops counting after maxAllocationEpochs.
- If a delegators close the allocation a POI won't be able to be presented and no rewards are distributed.
I wonder if it is a good idea to also include a grace period after maxAllocationEpochs to detach these two times.
- indexers can close any time
- soft penalty: no effective allocation is counted after maxAllocationEpochs
- hard penalty: delegators can force close after maxAllocationEpochs + gracePeriod
For simplicity we can keep only maxAllocationEpochs and then add a grace period if necessary.
- Lenguaje dominante
- Solidity
- Estrellas
- 374
- Forks
- 176
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de graphprotocol/contracts
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
graphprotocol/contracts#1361 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
graphprotocol/contracts#1360 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
graphprotocol/contracts#1355 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
graphprotocol/contracts#1033 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 30/100
graphprotocol/contracts#985 ·
Todos los issues de graphprotocol/contracts
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
OpenZeppelin/openzeppelin-community-contracts#292 ·
Los mantenedores suelen responder en 2 días
-
submission
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Uniswap/hooklist#10463 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
lambdaclass/ethrex#7329 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
status-im/nimbus-eth1#4867 ·
Los mantenedores suelen responder en 1 día