No confíes en ello. Verifícalo.
Cada día, AutoCoin convierte los resultados de sus estrategias en una raíz Merkle mediante hash, la firma y la ancla en Base. Esta página vuelve a ejecutar las comprobaciones en TU navegador a partir de los bytes publicados. Nuestra palabra no forma parte de las matemáticas.
- 1.Obtiene la atestación del día, los documentos hoja, la firma y el registro de claves de firma desde este sitio
- 2.Recalcula cada hash de hoja y la raíz Merkle a partir de los bytes en bruto, en tu navegador, usando WebCrypto
- 3.Comprueba la firma ed25519 sobre el mensaje firmado canónico frente a la clave registrada para esa fecha, y comprueba esa clave frente a las claves publicadas en esta página
- 4.Comprueba la continuidad de la cadena: la atestación de cada día se compromete con la raíz del día anterior
- 5.Comprueba la transacción de anclaje on-chain en Base, opcionalmente a través de una URL de RPC que tú proporciones
Quién firma los archivos diarios
El signature.json de cada archivo diario debe verificarse con la clave registrada para su fecha. Ambas claves aparecen aquí y vienen integradas en el verificador de esta página, así que una clave cambiada solo en el servidor de datos no pasa la comprobación.
2a32879031e04b7cfddb5bb752fc3e24ebd07f3c0d5b871d79223437d3842180Generada en nuestro servidor de publicación y guardada solo allí. Firma cada archivo diario desde el cambio en adelante.
Id de clave autocoin-pop-publisher-2026-09 · Toma el relevo de la firma en el cambio; el registro de claves indica su primera fecha.
31b4b9cbcdbe5a91d6c013539265b4f406250f7feebbfc5efee1ef90684d150cCreada en junio de 2026 mientras se construía el publicador; los archivos anteriores la llaman "LOCAL STUB KEY". No se acepta para ninguna fecha posterior al cambio.
Id de clave autocoin-pop-placeholder-2026-06 · Firmó los archivos diarios anteriores; el registro de claves indica sus fechas.
Qué clave firmó qué fechas: /pop/keys.json
Qué demuestra esto y qué no
Demuestra que el registro no ha sido modificado. No demuestra que el registro fuera correcto cuando se escribió.
Hacemos hash de lo que midieron nuestros sistemas. Si una medición fue incorrecta, el número incorrecto es el que queda sellado, a la vista. Ejemplo en vivo que publicamos en lugar de ocultar: la atestación del 2026-06-11 contiene filas de instantáneas con patrimonio negativo de un error contable conocido (ya corregido). Ese archivo se queda exactamente como se selló, porque reescribir la historia, incluso una historia con errores, es exactamente lo que este sistema hace imposible. Cada atestación posterior se construye a partir de la base de datos tal como estaba el día en que se selló; para entonces esas filas ya se habían corregido o eliminado, así que no aparecen después del 2026-06-11, y comparar ambos días muestra ese cambio abiertamente.
El modo Demo no es en vivo.
Cada hoja y cada fila de instantánea en los datos firmados lleva su entorno y su fuente. Los resultados en Demo son simulaciones con ejecuciones idealizadas. Esta página nunca muestra una serie sin su etiqueta.
El historial retroactivo solo empieza a ser fiable desde la primera publicación.
Las raíces de fechas anteriores al primer anclaje on-chain se generaron de forma retroactiva. La evidencia de manipulación solo es real desde el momento en que una raíz queda on-chain; todo lo anterior es coherente con la base de datos de hoy, no demostradamente inalterado desde esa fecha. La marca de tiempo del anclaje se muestra junto a la fecha de la atestación.
Atestamos nuestras propias mediciones, no los registros del exchange.
Ningún venue cofirma estas cifras. Cada cifra de patrimonio es nuestra propia medición diaria, sellada tal como se midió; en cuentas de brokerages y exchanges es nuestra lectura de la API del venue. Una atestación temprana (2026-06-11) incluye además una hoja con diez operaciones cerradas de Hades en Solana; ninguna atestación posterior incluye operaciones de Hades, así que el registro actual se apoya solo en las cifras de patrimonio de las estrategias.
El conjunto de estrategias puede cambiar.
Una estrategia eliminada de la base de datos deja de aparecer en las atestaciones posteriores, pero sus filas en las atestaciones anteriores no pueden cambiar. Cualquiera puede comparar las listas de hojas de dos días para ver exactamente qué estrategias dejaron de aparecer, y el bloque de cobertura de cada atestación también enumera las filas de instantáneas cuya estrategia ya no existe.
Para qué sirve la attestation.
Para que puedas confiar en que las cifras son reales, recalculadas en tu propio navegador a partir de los bytes publicados. AutoCoin es software autodirigido, y el historial es lo que hizo la máquina, a la vista de todos, todos los días.
La seudonimización es unidireccional.
Las identidades de los clientes no se pueden derivar de las referencias de usuario publicadas. Alguien que ya conozca un id interno concreto podría confirmar su presencia; los ids internos no son públicos.
Qué cuenta la cifra de capital.
El capital en la plataforma agrega todas las flotas en ejecución, tanto cuentas en vivo como demo. Es una cifra de escala de operaciones de los sistemas que se verifican aquí, no activos de clientes bajo gestión.
Los archivos anteriores llevan una firma provisional.
Los primeros archivos diarios, desde el 2026-05-27 hasta el cambio a la clave del publicador, se firmaron con una clave provisional creada mientras se construía el publicador, y su signature.json la llama "LOCAL STUB KEY". Conservamos esos archivos exactamente como se publicaron y nunca los volvemos a firmar. Su integridad se apoya en las raíces Merkle ancladas en Base: cada anclaje es una transacción pública con su propia marca de tiempo que no se puede editar después. Cada archivo diario posterior al cambio se firma con la clave del publicador de AutoCoin que aparece arriba, generada en nuestro servidor de publicación y guardada solo allí.
La página es una comodidad. Cada archivo que comprueba es público en /pop/, así que cualquiera puede repetir las mismas comprobaciones offline con herramientas estándar de SHA-256 y ed25519; cualquier disputa se resuelve frente a esos archivos y las raíces ancladas en Base.