Explorando HEX

HEX is a project to recrear un producto bancario común llamado Depósito a Plazo Fijo. Es un token ERC-20 y está totalmente automatizado en forma de contrato inteligente en la cadena de bloques Ethereum. La información y las preguntas frecuentes están disponibles en https://HEX.com.

El propósito de este documento es recorrer las características y viñetas del proyecto y verificarlas o explicarlas en términos de lo que realmente dice el contrato inteligente. El fundador del proyecto, Richard Heart, ha proporcionado versiones en desarrollo del código a la comunidad a través del canal de Telegram http://t.me/HEXcrypto. Participé en la discusión en ese canal, revisé el código e incluso señalé un error o dos (que se corrigieron en la próxima iteración). No deseo proporcionar consejos ni comentarios editoriales sobre ninguna de las funciones. Esto pretende ser una explicación objetiva de lo que hará el contrato.

Para obtener una discusión más detallada sobre Staking y las ganancias que se pueden obtener, consulte este documentohttps://bit.ly/hex-staking-guide.complementario

Contrato Inteligente HEX en Español.

Prelanzamiento HEX

La gente de HEX creará una instantánea del estado de la cadena de bloques BTC en alguna altura de bloque futura. Esto significa que cualquier dirección que controle tendrá su saldo en BTC registrado y referenciado por el contrato. *Esta parte no está en el contrato inteligente, pero se hace referencia a él desde el contrato inteligente. *

Antes del lanzamiento, se pondrán a disposición del público 3 cosas para confirmar su precisión.

1. El conjunto de UTXO de la instantánea antes de editar (ver GoxMeNot)

2. El conjunto de UTXO de la instantánea después de la edición

3. El código para generar el árbol merkle y el hash superior

Con estos, cualquier parte interesada podría confirmar

1. La instantánea se tomó correctamente

2. Se editó correctamente

. 3. El hash superior en el contrato es correcto

. Habrá una herramienta de reclamo en el sitio web que ayudará al usuario a firmar la dirección ETH objetivo con su clave privada BTC. Se proporcionarán instrucciones cuando la herramienta esté disponible. *Esta parte no está en el contrato, pero en el contrato se proporciona el material de declaración firmado, la clave pública de BTC y la dirección de Ethereum que se verifican en el contrato*

Reclamo previo HEX

Habrá un día de vigencia del contrato que solo admite una transformación Vestíbulo. Esto garantiza que las personas que compran HEX a través del proceso de transformación puedan comenzar a apostar al mismo tiempo que los reclamantes de BTC. Los detalles sobre este proceso se encuentran a continuación en The Transform Lobbies. Una diferencia notable sobre el primer día es que se distribuyen 1,000,000,000 HEX el primer día. Esto es congruente con la narrativa de que los vestíbulos están llenos de monedas sin reclamar y el primer día antes de reclamar, no hay monedas sin reclamar.

Flujo básico

El contrato emite 10 000 HEX por BTC en poder de la dirección de BTC en el momento de la instantánea. Nos han prometido una advertencia de 2 semanas para la instantánea. Por ejemplo, si recibimos una advertencia el 20 de abril, la instantánea debería ocurrir el 3 de mayo con el contrato vigente el 4 de mayo y el primer día de reclamo el 5 de mayo. No importa cuánto bitcoin tenga en mi(s) dirección(es) el 20 de abril. Solo importa cuánto bitcoin se confirme en mi(s) dirección(es) el 3 de mayo. Supongamos que recibo la advertencia y muevo 3 BTC a la dirección A y 2 BTC a la dirección B el 2 de mayo. Después de la instantánea del 4 de mayo, puedo hacer lo que quiera con esos bitcoins, incluso venderlos. Los vendo el 6 de mayo. Luego, el 19 de mayo (día del primer reclamo + 2 semanas), voy a reclamar y generaré 2 estados de cuenta firmados, uno de la dirección A y otro de la dirección B. Tenga en cuenta que cada billetera puede contener varias direcciones financiadas. Debe presentar un reclamo por separado para cada dirección financiada. Decido consolidar en una sola dirección ETH para ambas reclamaciones. El contrato valida mi firma y me acredita con 10,000 * 3 + bonificaciones – penalizaciones (descritas en breve) HEX para la dirección A a mi dirección ETH porque el 3 de mayo tenía 3 BTC en esa billetera. El contrato valida mi firma y me acredita 10.000 * 2 + bonificaciones – penalizaciones HEX por la dirección B a mi dirección ETH por el mismo motivo. También recibiré algunas bonificaciones y penalizaciones que se describirán en un momento.

Para reclamos de BTC, el contrato asigna inmediatamente el 90% del HEX reclamado por un mínimo de 350 días. Esto estará mediado por la interfaz de usuario y permitirá apuestas más largas (los #días se pasan como un parámetro de reclamación). El 10% restante se acuña a la dirección del reclamante. En el ejemplo anterior, el 90 % del HEX (es decir, 45000 + bonificaciones – penalizaciones) se apuesta por un período de tiempo proporcionado por el usuario de no menos de 350 días.restantes 5000 + bonos se acuñan y están disponibles de inmediato para apostar durante cualquier período de tiempo o vender en el mercado.

Ahora tengo algo de HEX. Puedo transferirlo como cualquier otro token ERC-20 o usar una función de contrato para hacer Stake. Replantear significa bloquear mi HEX en el contrato, reduciendo mi saldo transferible. El beneficio de Staking es que cuando finalizo mi período Stake, el contrato devolverá no solo el HEX que ingresé, sino HEX adicional basado en una tasa de interés y características adicionales de pago de bonificación codificadas en el contrato.

Ejemplos

de reclamación La bonificación de reclamación es mejor y las penalizaciones son más ligeras cuanto más cerca de la fecha de lanzamiento se apueste. Las bonificaciones se describen en detalle a continuación, por lo que para estos ejemplos solo se aplicarán. Supondré una reclamación de 5 BTC para estos ejemplos

Reclamaciones normales

Día de lanzamiento de

5 BTC * 10 000 HEX/BTC * 1 (sin penalización por retraso) * 1,2 (bonificación por velocidad) = 60 000 HEX

Dos semanas después del lanzamiento

5 BTC * 10 000 HEX/BTC * 0,96 (penalización por retraso) * 1,192 (bonificación) = 57 216 HEX

Un mes después del lanzamiento

5 BTC * 10 000 HEX/BTC * 0,914 (penalización por retraso) * 1,1829 (bonificación por velocidad) = 54 073 HEX

Seis meses después del lanzamiento

5 BTC * 10 000 HEX/BTC * 0,5 (penalización por retraso) * 1,1 (bonificación por velocidad) = 27 500 HEX

Último día de reclamación elegible (~1 año después del lanzamiento)

5 BTC * 10 000 HEX/BTC * 0,0029 (multa por retraso) * 1,00057 (bonificación por velocidad) = 143

reclamaciones de ballenas(1000 BTC <= reclamación < 10 000 BTC)

Día del lanzamiento

5000 BTC * 10 000 HEX/BTC * 0,3889 (ballena tonta) * 1 (sin penalización por retraso) * 1,2 (bonificación por velocidad) = 23 333 333 HEX

Dos semanas después del lanzamiento

5000 BTC * 10 000 HEX /BTC * 0.3889 (ballena tonta) * 0.96 (penalización tardía) * 1.192 (bono de velocidad) = 22,250,667 HEX

Un mes después del lanzamiento

5000 BTC * 10,000 HEX/BTC * 0.3889 (ballena tonta) * 0.914 (tarde penalización) * 1,1829 (bonificación por velocidad) = 21 028 571 HEX

Seis meses después del lanzamiento

5000 BTC * 10 000 HEX/BTC * 0,3889 (ballena tonta) * 0,5 (multa por retraso) * 1,1 (bonificación por velocidad) = 10 694 444 HEX

Último día de reclamación elegible (~1 año posterior al lanzamiento)

5000 BTC * 10 000 HEX/BTC * 0,3889 (ballena tonta) * 0,0029 (penalización tardía) * 1,00057 (bonificación de velocidad) = 55 587 HEX

Reclamaciones de mega ballenas (>= 10 000 BTC)

Día del lanzamiento

50 000 BTC * 10 000 HEX/BTC * 0,25 (ballena tonta) * 1 (sin penalización por retraso) * 1,2 (bonificación por velocidad) = 150 000 000 HEX

Dos semanas después del lanzamiento

50 000 BTC * 10 000 HEX/BTC * 0,25 (ballena tonta) * 0,96 (penalización por retraso) * 1,192 (bonificación por velocidad) = 143 040 000 HEX

Un mes después del lanzamiento

50 000 BTC * 10 000 HEX/BTC * 0,25 (ballena tonta) * 0,914 (penalización por retraso) * 1,1829 (bonificación por velocidad) = 135 183 673 HEX

Seis meses después del lanzamiento

50 000 BTC * 10 000 HEX/BTC * 0,25 (ballena tonta) * 0,5 (sin penalización por retraso) * 1,1 (bonificación de velocidad) = 68 750 000 HEX

Último día de reclamación elegible (~1 año después del lanzamiento)

50 000 BTC * 10 000 HEX/ BTC * 0,25 (ballena tonta) * 0,0029 (sin penalización por retraso) * 1,00057 (bonificación de velocidad) = 357 347 HEX

Los vestíbulos de transformación

La otra forma de adquirir HEX es entrar en un vestíbulo de transformación (llamado Amplificador de adopción en el sitio web). Todos los días, 1/350 de los BTC no reclamados se convierte a HEX. ETH acumulado en el día anterior se convierte en HEX. Por ejemplo, si hay 350 000 bitcoins sin reclamar al final del día 200, mil de ellos se convertirán a HEX, es decir, 10 000 000 HEX (10 000 * 1000). Si se acumularon 500 ETH en el transcurso del día 200, en cualquier momento del día 201 o después, un usuario podría reclamar HEX equivalente a 10 000 000 * <ETH que contribuyeron> / ETH total. Si enviaran 1 ETH ese día, cobrarían 20.000 HEX.

Entrar en un lobby de transformación implica enviar ETH a la función de contrato joinXfLobby. Todos los ETH enviados durante un día determinado se cuentan y cualquier día siguiente, LeaveXfLobby se puede llamar aEs posible realizar múltiples entradas en un día y la LeaveXfLobby toma tanto el número de día como el número de entradas para resolver como entradas.

Nota: El sistema Transform también paga por referencias, por lo que si está utilizando o promocionando un enlace de referencia, esta es otra vía para ganar HEX.

Replantear

Replantear es invocar una función en el contrato inteligente para comprometer su HEX por un período de tiempo. Actualmente la unidad de tiempo son los días. Puedo apostar 10,000 HEX durante 10 días, por ejemplo. Durante este tiempo no puedo acceder a esos HEX, pero al final de 10 días termino mi Stake y recibo mis 10,000+ pagos. Esta es la funcionalidad del Certificado de Depósito.

Los pagos se extraen de un grupo basado en mi parte del total de Acciones. Uso «Acciones» aquí intencionalmente porque los bonos de participación se calculan como una escala de su HEX en Acciones. Es decir, si apuesto 10 HEX y calificar para bonos del 40%, entonces mis 10 HEX se convierten en 14 Acciones. Mi pago se basa en mis Acciones divididas por el número total de Acciones, no en HEX dividido por el número total de HEX. Esto es importante porque significa que acumular bonos es la forma de obtener el mejor pago, quizás incluso más económico que comenzar con más HEX. Es mucho más fácil obtener un bono del 40 % que comprar un 40 % más de bitcoins, consulte LongerPaysBetter/BiggerPaysBetter a continuación.

Precio de las acciones

Para garantizar que las participaciones más largas y más grandes paguen mejor con el tiempo, existe un mecanismo de fijación de precios integrado en el contrato. Cada vez que finaliza una participación, las ganancias de esa participación se calculan en forma de un precio de acción que todos los participantes futuros pagarán para convertirsu HEX en acciones. Una nota importante aquí es que la unidad base de HEX es el Corazón. Los corazones son para HEX como los Satoshis para Bitcoin. Hay 100,000,000 Corazones por HEX.

El precio de la acción en el lanzamiento será de 1 acción por Corazón. La forma en que se mueve el precio está relacionada con el retorno de la inversión de una participación. Por ejemplo, si en el día 5 alguien termina su participación y tiene una ganancia del 20 %, se traduce en un precio de acción de ~1,2 corazones por acción. Si ese usuario desea apostar nuevamente, sus Corazones se dividirán entre 1,2 para determinar su número de acciones. Dado que Ethereum solo admite matemáticas enteras, esto se logra utilizando un escalar que se enumera a continuación.

La fórmula exacta es:

(BPB + cappedHearts) * stakeReturn * SHARE_RATE_SCALE / ((LPB * acciones) / (LPB + extraStakedDays) * BPB);

Definiendo esos términos:

• «BPB» es 10 veces el valor máximo para la bonificación
• BiggerPaysBetter «stakeReturn» es el monto total pagado por finalizar la apuesta
• «SHARE_RATE_SCALE» es un escalar para mantener la precisión en la salida (al momento de escribir, tiene 5 decimales)
• «shares» es el número de acciones en esa participación
• «LPB» es 1820
• «extraStakedDays» es el menor de 3640 y (stakedDays – 1)
• «CappedHearts» es el menor de su stakeReturn y la cifra máxima BiggerPaysBetter

Esto significa que es un cálculo de sus ganancias, ajustado por el bono adicional BiggerPaysBetter que obtendrá por apostar su HEX devuelto.

La intención es que las matemáticas funcionen de tal manera que solo pueda volver a ingresar una participación con, en el mejor de los casos, la misma cantidad de acciones que acaba de cobrar.

De esta manera, garantiza que las apuestas más largas y más grandes pagarán mejor con el tiempo porque nadie más puede jugar juegos para obtener más acciones en el sistema. Esto también significa que siempre es mejor apostar ahora porque el precio solo subirá.

Cálculo de pago e interés

El contrato acumula un fondo de pago por día. El grupo de pagos se llena con la inflación diaria del 0,009955 % del suministro total de monedas. Esto resulta en 3.69% por 52 semanas, compuesto diariamente. Hay entradas adicionales al grupo de pagos que se analizan a continuación. Al finalizar su participación al final de su compromiso, el contrato pasa por cada día de su plazo y acumula un pago total de sus Acciones/Total de Acciones * pago del día. El contrato acuña el HEX y te lo acredita.

Unstake Gotchas

Early/Emergency Unstake Unstake

El contrato tiene una función por la cual un usuario puede cancelar su participación antes del tiempo comprometido. El usuario paga una multa por esto. El contrato calcula el pago por la mitad (redondeado hacia arriba) de los días comprometidos, por ejemplo, 182 por un compromiso de 52 semanas, y lo resta de los fondos devueltos al usuario. Siempre se aplicará al menos una sanción de 90 días. Por ejemplo, hago stake durante 52 semanas (alrededor de 1 año) y retiro de emergencia después de 266 días (38 semanas). El contrato calcula mi pago para los días 1 a 182 y lo marca como penalización. Los fondos que se me devuelven son mi principal + (Días 183 a 266) pagos.

Si el usuario cancela la participación de emergencia antes de que se cumpla la mitad de sus días o si su participación es inferior a 179 días debido al mínimo de 90 días de penalización, la penalización puede reducirse en Principal. El contrato solo calcula la mitad de los días o 90, lo que sea mayor, de los pagos, estimando los días futuros no atendidos, y lo resta de los fondos devueltos.

Por ejemplo, apuesto durante 364 días y luego desactivo el día 140. Se llevan a cabo varios pasos para determinar mis monedas devueltas finales.

• El contrato calcula mi pago por 140 días y luego estima una multa
• . Debido a que no he cumplido la mitad de mis días comprometidos, calcula la diferencia aplicando una proporción de medio día comprometido / días servidos * pago
• En este caso, eso es 182 días (la mitad de 364 días comprometidos) dividido por 140 días servidos. Por tanto, la sanción es de 182/140 * pago (½ día dividido por los días servidos).
• Mi HEX devuelto es igual a Principal + pago-penalización.
  • La penalización se puede definir como una versión escalada del pago, por lo que mi HEX neto devuelto será Principal + (140/140 * pago) – (18 2/140 *pago)
  • Lo que se simplifica a Principal – (42/140 * pago).

• Esto significa que mi retorno será menos de lo que puse. Lee eso de nuevo. Su principal puede ser penalizado si cancela la participación antes de que se cumpla la mitad de los días comprometidos O si la duración de su participación es inferior a 179 días debido a la penalización mínima de 90 días.

Unstake tardío

El sistema penaliza a un usuario por dejar su Stake desatendido después de que se haya sentado durante el período comprometido. Hay un período de gracia de 14 días y luego, al finalizar la apuesta, el HEX devuelto se reducirá en un 0,143 % por día de retraso (1 % por semana de retraso). Por ejemplo, si he apostado durante 52 semanas, tengo los días 365 – 379 para finalizar mi participación y recibir mi HEX, el interés ganado y la bonificación HEX. Después de eso, mi pago total será penalizado con un 0,143 % por día. Esto incluye el Principal, por lo que si tengo 700 días de retraso (poco menos de 2 años), recibiré 0 HEX independientemente de la duración de la apuesta o del Principal.

Ejemplo

Este será un ejemplo simplificado para demostrar cómo funciona el flujo del contrato. Ignora la bonificación LargerPaysBetter porque quiero mostrar unidades lo suficientemente pequeñas para que tengan sentido, lo que significa bonificaciones porcentuales pequeñas e inútilmente confusas. Habrá información más detallada disponible en https://bit.ly/hex-staking-gainzHEX

• el mismo día y por coincidencia cada uno termina con 10,000
• apuestas HEX A 10 000 HEX durante 182 días (6 meses), B apuesta 10 000 HEX durante 364 días (alrededor de 1 año) y C apuesta 10 000 HEX durante 1820 días (alrededor de 5 años)
• Para simplificar, supondremos que son los únicos 3 jugadores y obtienen una tasa de participación de 1:1.
• El contrato convierte HEX en acciones utilizando el escalar LongerPaysBetter (días/1820) que da como resultado
  • (A) 10 000 * (1 + 182/1820) = 11 000 acciones
  • (B) 10 000 * (1 + 364) /1820) = 12 000 acciones
  • (C) 10 000 * (1 + 1820/1820) = 20 000 acciones Las acciones
  • totales son 43 000

• Todos los días se acumula un fondo de pago a partir de la inflación * (1 + de masa crítica + bonificación de viralidad ). Supongamos, por simplicidad, que no hay más reclamos, por lo que la masa crítica y la viralidad permanecen constantes.
• Para este ejemplo, suponga que la inflación es 714,285 HEX/día, 15 % de masa crítica, 25 % de viralidad, con un pago diario de 714,285 * (1 + 0,15 + 0,25). = 1,000 HEX/día
  • Día 1, digamos que el grupo es 1,000 HEX entre 43,000 acciones
  • Día 2, el grupo es 1,000 HEX entre 43,000 acciones
  • Etc. hasta el día 182

• El día 182, (A) finaliza su participación sin penalización
  • El contrato pasa por cada día, 1 – 182
  • Acumula un pago para (A) utilizando las acciones de (A) / acciones totales
    • 1000 HEX * 11 000 acciones (A) / 43 000 acciones totales = 255,81 HEX
      • Lo hace durante los 182 días, lo que da como resultado 46 557,42 HEX como el pago
      • Esto se acuña a su dirección junto con sus 10,000 HEX iniciales
      • Su dirección ahora tiene 56,557.42 HEX.

Este proceso también ocurrirá para (B) y (C) una vez que venzan sus apuestas, aunque para datos de 364 y ​​1820 días.

Bonos/Modificadores

Todos los bonos y modificadores que describo aquí se anuncian en el sitio web y están codificados dentro del contrato. Los vi todos y validé la precedencia matemática y de operadores utilizando la documentación de Solidity (si eso no tiene sentido para usted, significa que me aseguré de que hace lo que dice hacer).

Relacionados con reclamaciones

Estos se enumeran en el orden en que se aplican.

GoxMeNot: El sitio web dice que no permite reclamar algunas direcciones conocidas de malos actores (por ejemplo, Mt. Gox). *Esto se logrará durante la construcción del árbol Merkle de instantáneas. Richard dice que publicará información suficiente para permitir a los usuarios crear el árbol de Merkle de instantáneas para que podamos validar que la instantánea sea precisa, pero aún no se ha publicado dicha información, por lo que no puedo verificar que esto suceda en este momento.*

SillyWhalePenalty: Al reclamar, si la dirección BTC proporcionada tenía 1000 o más bitcoins en el momento de la instantánea, la reclamación se reduce. La escala va desde el 50 % para 1000 hasta el 75 % para más de 10 000 bitcoins. Esta escala es lineal, por lo que 5500 reclamos de bitcoin (½ camino entre 1000 y 10 000) se reduce en un 62,5 %. Esto significa que un reclamo de 1000 BTC solo se acredita con 500 veces 10k HEX. Las reclamaciones de 10 000 BTC solo recibirían 25 000 000 HEX (2500 * 10 000 HEX/BTC). El reclamo de 5500 BTC solo recibiría 20,625,000 HEX. Consejo profesional: esta penalización se puede evitar dividiendo las direcciones grandes en varias direcciones, cada una de las cuales contiene < 1000 BTC *antes de que se produzca la instantánea*.

LatePenalty: el sistema premia las reclamaciones rápidas y castiga a las que reclaman con lentitud. La intención es reducir el valor de su reclamo en un 0,286 % por día (~2 % por semana), reduciéndolo a 0 después del día 351 del lanzamiento del proyecto. La función es fácil, simplemente multiplica su reclamo por (350 – días pasados)/350. Entonces, en el primer día de reclamo, pasaron 0 días, obtiene un reclamo * 350/350. Tres semanas después, solo recibe el reclamo * 329/350. Por ejemplo, una reclamación de 1 BTC generaría 10 000 HEX el primer día y solo 9400 HEX tres semanas después. En el ejemplo anterior de reclamar 2 semanas después del primer día de reclamación (19 de mayo), incurriríamos en una multa de 2000 HEX en nuestra reclamación de 50 000, como se muestra en la Ejemplos de reclamaciones .

Velocidad: en la sección Flujo básico, reclamé un total de 50 000 HEX en 2 direcciones BTC. Se aplica un «Bono de velocidad» a estas reclamaciones. La bonificación se aplica durante los primeros 350 días de reclamo después del lanzamiento y comienza en un 20 % el primer día y cae un 0,057 % cada día a partir de entonces. Por ejemplo, un reclamo de 5 BTC el 5 de mayo me otorga el 20% completo (5 * 10,000 HEX base + 10,000 HEX de bonificación), lo que eleva mi total a 60,000 HEX. En nuestro ejemplo, reclamamos 2 semanas tarde, por lo que nuestro reclamo base ahora es 48,000 HEX y la bonificación se redujo al 19.2% de ese nuevo valor base, o 9216 bonificación HEX. Si, en cambio, reclamé 175 días (aproximadamente 6 meses) más tarde, pierdo la bonificación y parte de mi reclamo se ha redistribuido a través de We Are All Satoshi. Mi valor de reclamo base ahora sería 25,000 HEX (LatePenalty) y la velocidad es solo del 10% o 2500 HEX adicionales.

Referencias: El sitio web le permite generar un enlace de referencia. Esto establece una cookie en el navegador de la persona que hace clic en ella. La cookie simplemente indica su dirección ETH y la herramienta de reclamo la lee. El contrato recibe una dirección “remitente” y en el momento del reclamo, paga a la dirección “remitente” el 20% del valor del reclamo *incluyendo el bono de Velocidad*. Mejor aún, le paga a la persona que usa el enlace una bonificación del 10 % por tener un referente. Para reafirmar, el uso de un enlace de referencia le otorga un 10% adicional. Su referente gana el 20% del valor total de su reclamación. Por ejemplo, si reclama 1 BTC en el primer día de reclamación, obtendrá una bonificación de velocidad completa del 20 %, lo que dará como resultado 12 000 HEX. Hacer clic en un enlace de referencia genera un 10 % adicional para usted, 1200 HEX, y un 20 % para su referencia, 2640 HEX.

La autorreferencia funciona, lo que significa que puede generar un enlace de referencia para su propia dirección ETH, hacer clic en él, reclamar su HEX y recibir el bono de referencia del 20%. Menciono esto porque debería ser obvio que podría hacer esto utilizando una dirección ETH «ficticia» para recibir bonificaciones de reclamo y su dirección «real» para reclamar. Luego consolide o no a su gusto. Si esto ahora significa que no desea hacer clic en mi enlace de referencia en la parte superior, considere simplemente enviar una sugerencia HEX a 0xd30bc4859a79852157211e6db19de159673a67e2.

Stake Related

modifica el fondo de pago

We Are All Satoshi

Como parte del proceso de instantánea, se calcula la cantidad total de bitcoin existente. Cada día después del primer día de reclamo durante 350 días, se captura el 0,2857 % de este total, menos las monedas reclamadas. Por ejemplo, supongamos que hay un total de 17 500 000 bitcoins en la instantánea. Al final del primer día, se han realizado la mitad de las posibles reclamaciones, lo que significa que 8.750.000 bitcoins no han sido reclamados. Al día siguiente, se toman 25 000 bitcoins del grupo de 8 750 000 y se registran como «no reclamados». Al día siguiente, suponiendo que no haya más reclamos, se agotan otros 25,000 bitcoins y se agregan a la cantidad no reclamada. Etcétera.

Si más personas reclaman, el fondo común diario no reclamado se reduce según el tamaño de sus reclamaciones. Para ser claros, el tamaño de su reclamo se reduce al mismo ritmo que las monedas se marcan como «no reclamadas», por lo que todo se escala de manera adecuada. Es decir, si tengo 50 BTC y no reclamo durante 35 días (5 semanas), solo obtengo 45 BTC en HEX. El grupo no reclamado marcó 5 de mis BTC como no reclamados. *Las matemáticas en el contrato funcionan de tal manera que las reclamaciones y los pagos no reclamados se equilibran.*

Después de que finaliza la fase de reclamación, 352 días después del lanzamiento del contrato, todas las monedas tabuladas no reclamadas se pagan a los participantes. Cómo se logra esto en la práctica es que si tiene una apuesta que incluye este día especial, además de su pago de intereses, recibirá un pago único de su parte de todas las monedas no reclamadas. Por ejemplo, arriba imaginamos que se reclaman 8,750,000 BTC y no más. Después del final de la fase de reclamo, cualquier apuesta activa en ese día recibirá una porción única de las monedas no reclamadas al apuesta. Si tiene el 5 % de las acciones de todos los participantes, recibirá un pago adicional de 0,05 * 8 750 000 BTC * 10 000 HEX/BTC = 4 375 000 000 HEX

Masa crítica/viralidad

Los enumero juntos porque funcionan esencialmente de la misma manera y se calculan juntos en el contrato. Critical Mass es una bonificación que se aplica al fondo de pago igual a las monedas reclamadas/total de monedas posibles. Entonces, si hay un total de 17 500 000 bitcoins reclamables y se han reclamado 13 125 000, la bonificación es del 75 %. La viralidad es similar pero para las direcciones de bitcoin. Es el número de direcciones elegibles reclamadas/total de direcciones elegibles. Los bonos son aditivos, lo que significa que se calculan por separado y ambos se suman al pago (pago * (1 + monedas reclamadas/total de monedas + direcciones reclamadas/total de direcciones)).

Retirada anticipada/tardía No

se trata de bonificaciones, sino de penalizaciones en las que incurren otros participantes. Como se describe en la sección Unstaking Gotchas, hay acciones que un usuario puede realizar que incurren en penalizaciones. La mitad de todos los HEX eliminados de la devolución del apostador por penalizaciones se agregan al fondo de pago el día en que finaliza la apuesta o se lleva a cabo una «buena contabilidad». Por ejemplo, supongamos que una apuesta finaliza antes de tiempo e incurre en una penalización de 10 000 HEX. Lo hacen el día 910. El grupo de interés para los participantes activos en el día 910 aumenta en 5000 HEX. Luego, en el día 1050, una apuesta que llega tarde tiene una «buena contabilidad» y se pierden 15,000 HEX por una penalización por retraso. Al fondo de pago de ese día se le agregarían 7500 HEX. Etcétera.

Modifica su participación

Estas bonificaciones son la forma en que su HEX se multiplica para convertirse en Acciones. El bono para LongerPaysBetter tiene un límite de 2x, lo que significa 10 años o 3641 días, y el bono para BiggerPaysBetter tiene un límite del 10% para 150,000,000 apuestas HEX. Esto significa que con una apuesta de 10 años, sus Acciones equivalen al triple de sus monedas. Con una apuesta de 75 000 000 HEX, recibes un bono del 5 % además de eso. El total después de las bonificaciones es el número que se utiliza para calcular las Acciones.

LongerPaysBetter

Cuanto más tiempo apueste, más ganará. La fórmula es (días apostados – 1) / 1820. Parece complicado pero sale un 20% por año de participación (el contrato usa 364 días/año). El «menos 1» representa el período mínimo de apuesta de 1 día.

BiggerPaysBetter

Cuanto mayor sea su apuesta, más ganará. La fórmula de bonificación es HEX/150*10^7, con un límite del 10 % para apuestas de 150 000 000 HEX. Nota: el porcentaje está limitado, la bonificación HEX no lo está. Apuestas de ejemplo

• 1.000.000 HEX = 0,0667 % de bonificación, o 667 HEX de bonificación
• 10.000.000 HEX = 0,667 % de bonificación, o 66.667 HEX de bonificación
• 100.000.000 HEX = 6,67 % de bonificación, o 6.666.667 HEX de bonificación
• 200.000.000 HEX

origen0

Elcontrato especifica una dirección ETH como la dirección de origen. Esta dirección recibe pago HEX por contrato de varias maneras

• El origen recibe la mitad de todo el HEX reclamado por multas (la otra mitad se destina al grupo de pago)
• El origen recibe una copia de todos los pagos de bonificación
  • reclamación de velocidad Bonificación de
  • recomendación
  • Somos Todos los incrementos de Satoshi
  • Bonificaciones de viralidad/masa crítica

Funciones del contrato

Esta sección será un poco más técnica y discutirá las diferentes funciones expuestas por el contrato HEX y puede ser invocada por cualquier persona que desee pagar el gas. Algunas de estas funciones están marcadas como «externas» y otras como «públicas». Según la documentación de Solidity, no hay diferencia para una persona que llama, excepto que las funciones «externas» a veces son más eficientes en el uso de gas. Sospecho que esto se usa más como un marcador por parte del desarrollador de qué funciones están destinadas a ser llamadas regularmente por un cliente externo.

Funciones externas

Estas son las funciones «externas» que son las principales interacciones normales con el contrato

informativas

. Funciones

. globalInfo

el estado global del contrato en forma de una

• .
• valores
• devuelve
• Esto
• de
• matriz
• LatestStakeId
• ClaimedSatoshisTotal
• UnclaimedSatoshisTotal
• ClaimedBtcAddrCount
• currentContractDay
• totalSupply (es decir, suministro circulante) addedSupply

Devuelve

el suministro total de HEX en circulación más el HEX bloqueado agregado. Esto es muy diferente de la función ERC-20 totalSupply porque el contrato se quema HEX bloqueado, lo que significa que totalSupply.

totalSupply

Devuelve el HEX acuñado total, que es sinónimo del suministro circulante de HEX.

dailyDataUpdate

Toma como entrada un número de día, siendo 0 interpretado como “día actual”. Esto calcula y establece de manera idempotente los datos de pago del día antes del número de día dado. Por ejemplo, 1 año después del lanzamiento, llamo a esta función con `343` como entrada y calculará los datos de participación de todos los días para los días 1 a 342 o los días que aún no se hayan calculado.

dailyDataRange

Toma como entrada un número de día y una cantidad de días. Esta es una función de obtención de datos que devuelve la lista de datos de pago para el rango de días solicitado. Los datos se empaquetan en valores uint256 (instantánea de satoshi no reclamada << 160, total compartido << 80, pago total).

currentDay

Devuelve el día actual del contrato.

Transform

Functions para participar en Transform Lobbies y funciones relacionadas

xfLobbyEnter

Ingresa el ETH proporcionado en el Transform Lobby del día actual. Si se proporciona una dirección de referencia, se captura para acreditar a esa persona con bonificaciones de referencia normales al salir del lobby (recolectando HEX). Se pueden realizar múltiples entradas en un día y se ingresan en una cola, resueltas primero en entrar, primero en salir al momento de «salir».

xfLobbyExit

Toma un día objetivo y una cantidad de entradas para resolver. Por ejemplo, te unes al lobby del día 3 cuatro veces. Después del día 3, puede llamar a esta función con 3 para el día y 0-4 para el número de entradas a resolver. 0 significa «todos». El contrato resolverá el número proporcionado de entradas de la más antigua a la más nueva, acumulando HEX para ser acuñado a la persona que llama y acuñando HEX de bonificación por referencia a los remitentes a medida que se resuelven las entradas.

En el ejemplo anterior, digamos que la primera y la segunda entrada tienen referencias diferentes, A y B. Si llamo a LeaveXfLobby(3, 2), el contrato calculará mi HEX transformado para la primera entrada, acuñará la bonificación de referencia a A, calculará mi transformación HEX para la segunda entrada, acuña el bono de referencia a B, luego acuña el HEX transformado total para mí.

xfLobbyflush

transformó ETH en una dirección de descarga predefinida.

xfLobbyRange

Devuelve los valores de lobby para un rango de días especificado por las entradas de los días de inicio y finalización

. xfLobbyEntry

Devuelve el ETH y la referencia para una entrada determinada en un día determinado. La entrada «entryId» es un valor lleno de bits del día + índice en la cola de entrada.

xfLobbyPendingDays

Devuelve una serie de días que tienen entradas pendientes elegibles para la recopilación.

Replantear

Funciones para replantear o directamente relacionadas con replantear

stakeStart

Comienza un replanteo. Toma como entradas el monto de la apuesta y la duración de la apuesta. El contrato calcula las acciones en función de la duración de la participación y agrega una entrada de participación para el usuario. The identifier for this stake is a just a number equal to the number of stakes in the system plus 1. For example, I have 3 active stakes and other users have a combined 20 active stakes. The global “next stake id” is 24 and start a new stake. To refer to the new stake later, its id is 24. Starting a stake burns the committed HEX and accounts for them in the global “allocated supply”.

stakeEnd

Ends a stake. The logic changes quite a bit if the stake ends early, late, or on time. The details are covered above. The necessary inputs are an id for the stake (this was determined when the stake was created) and the index of the stake among the user’s active stakes. This mints new HEX to fulfill the stake return and adds to the total (ie circulating) supply.

stakeGoodAccounting

This function safely ends a mature stake. If the stake is not mature, the function errors. It does *not* pay out to the staker. It can be invoked by anyone on behalf of any staker. It takes as input a staker address and a stake id for that address.

stakeCount

This returns the number of open stakes a user has.

Claim

Functions to claim or directly related to claiming

btcAddressIsClaimable

Takes a BTC address and returns whether it can be claimed, meaning it has not been claimed yet and is valid

btcAddressIsValid

Validates whether claim parameters BTC address, satoshis, and proof constitute a valid claim

merkleProofIsValid

Validates a Merkle proof and Leaf are valid for the Merkle Tree built from the UTXO set

btcAddressWasClaimed

Takes a BTC address and returns whether it has been claimed or not.

claimBtcAddress

This is a big one. This is the claim function that could be called by a naive client but certainly is intended to be invoked by the claim tool. It takes several inputs to validate a bitcoin claim and returns the resulting “free” HEX including the speed bonus, late penalty, and referral bonus (10% if other-referred, 32% if a self-referral). “Free” has a special meaning here, see below.

For folks interested in the technical details, the inputs are:

• `referrer` is the referring ETH address, if any
• `v`, `r`, and `s` are known parameters needed for the ECDSA signature validation
• `addrType`, `pubKeyX`, and `pubKeyY` are parameters to convert a public ECDSA key into its associated BTC address
• `claimToAddr` is the destination ETH address that shall receive the HEX should the claim be valid
• `proof` is the data used to prove that a given address is in the snapshot (`verifyProof` function). The details here are technical, but rest assured this is standard and in fact one of the benefits of the data structures used for BTC data
• `rawSatoshis` the claim amount in Satoshis, the smallest denomination of BTC (think pennies to bitcoin’s dollar)
• `autoStakeDays` – this is unrelated to the claim verification but rather a new contract Rule, explained below

The contract now automatically stakes 90% of a claim’s value for a minimum of 350 days. The function takes autostake days as an input and validates that it is as least 350 days. Emergency unstaking is disabled before 350 days. For example, a “default” claim with 350 day autostake will be allowed to end that stake at maturity but not before. An aggressive user may claim with supplied autostake days of 700. After 350 served days, they may unstake albeit with all applicable early unstake penalties.

The remaining 10% of claimed HEX is minted to the claimant and may be traded or staked as desired.

Public Functions

These are the `public` functions that the contract exposes to be called but may or may not make sense. This statement will make more sense shortly.

claimMessageMatchesSignature

Synthesizes a claim message from a key then compares the extracted address from the recreated message and the address converted from the public key

pubKeyToEthAddress

Converts a public key to an ETH address

pubKeyToBtcAddress

Converts a public key to a BTC address

Contract Events

The Events have been restructured in the contract to use custom bit-packing so these values are not correct. The values they capture are all documented below with roughly the sizes indicated.

Bit packing means that the author of the contract and wallet uses only uint256 values and has an encoding scheme that fills in the 256 bits in predictable chunks. This is because Solidity only allows uint sizes in increments of 8 bits, but many values in HEX require numbers close to a multiple of 8. This means that some gas efficiency can be gained by using more precise sizing and encoding the values into uint256 values.

XfLobbyEnter

Emitted upon joining a daily lobby

Fields

uint40 timestamp,

address indexed memberAddr,

uint256 indexed entryId,

uint96 rawAmount,

address indexed referrerAddr

XfLobbyExit

Emitted upon resolving a lobby entry. For xfLobbyExit calls of multiple entries, multiple events are emitted.

Fields

uint40 timestamp,

address indexed memberAddr,

uint256 indexed entryId,

uint72 xfAmount,

address indexed referrerAddr

DailyDataUpdate

Emitted upon completion of daily data updates. A single event is emitted per batch of daily data computed.

Fields

uint40 timestamp,

uint16 daysStoredAdded,

uint16 daysStoredTotal,

bool isAutoUpdate,

address indexed updaterAddr

Claim

Emitted upon completion of a BTC claim

Fields

uint40 timestamp,

address indexed claimToAddr,

bytes20 indexed btcAddr,

uint8 claimFlags,

uint56 rawSatoshis,

uint56 adjSatoshis,

uint72 claimedHearts,

address indexed referrerAddr,

address senderAddr

ClaimAssist

Emitted upon completion of a BTC claim wherein the claimant is not the sender of contract call. This is emitted in addition to the above Claim event.

Fields

uint40 timestamp,

address claimToAddr,

bytes20 btcAddr,

uint8 claimFlags,

uint56 rawSatoshis,

uint56 adjSatoshis,

uint72 claimedHearts,

address referrerAddr,

address indexed senderAddr

StakeStart

Emitted upon starting a stake.

Fields

uint40 timestamp,

address indexed stakerAddr,

uint40 indexed stakeId,

uint72 stakedHearts,

uint72 stakeShares,

uint16 stakedDays,

bool isAutoStake

StakeGoodAccounting

Emitted upon call to stakeGoodAccounting, if successful.

Fields

uint40 timestamp,

address indexed stakerAddr,

uint40 indexed stakeId,

uint72 payout,

uint72 penalty,

address indexed senderAddr

StakeEnd

Emitted upon ending a stake

Fields

uint40 timestamp,

address indexed stakerAddr,

uint40 indexed stakeId,

uint72 payout,

uint72 penalty,

uint16 servedDays

ShareRateChange

Emitted if the share rate is changed by an stakeEnd with the new share rate.

Fields

uint40 timestamp,

uint40 shareRate,

uint40 indexed stakeId