IOTA anchors
3
Merkle roots reales en testnet para delivery, pharma y agro.
Proof Verify permite que un cliente, auditor o inversor compruebe que una evidencia existia y no fue cambiada, sin ver el dato sensible que genero esa evidencia.
Testnet live cockpit
Esta pantalla conecta Demo Lab, API, IOTA y Polygon: nexID genera el evento privado, publica solo evidencia hash-only y deja que un tercero lo verifique sin acceder a datos sensibles.
IOTA anchors
3
Merkle roots reales en testnet para delivery, pharma y agro.
Memo receipts
3
Raw input legible y decodificable desde explorer.
IOTA contract
live
Anchor contract separado de datos privados nexID.
Polygon ownership
mint
NFT/certificado para propiedad, garantia o claim.
Para empresarios
No hace falta entender blockchain: se verifica si la evidencia esta incluida y que informacion quedo privada.
Para auditores
El SHA, el Merkle root, la tx y el Raw input se pueden contrastar contra el explorer externo.
Para producto
IOTA queda para evidencia; Polygon queda para propiedad, warranty y certificados transferibles.
Para Cliente o auditor
Pega un SHA o Raw input y ve si la evidencia existia, sin acceder al dato privado.
Para Empresa
Muestra integridad externa para QA, DPP, custodia o reclamos sin publicar UIDs ni rutas.
Para Inversor o C-level
Entiende en una pantalla que IOTA prueba evidencia y Polygon prueba ownership separado.
1. Evento
Puede ser un tap valido, QA de lote, entrega, custodia, DPP o reporte logistico.
2. Hash
El sistema genera un sha256 del evento canonico. No publica UIDs, clientes, rutas privadas ni keys.
3. Anchor
Varios hashes se consolidan en un root auditable local o externo, segun politica del tenant.
4. Recibo publico
IOTA puede guardar un texto publico minimo: caso, recurso, eventos, root y privacy=hash-only.
5. Verificacion
Con el hash, un auditor o cliente confirma si esa evidencia esta incluida sin ver el dato privado.
Polygon ownership layer
Esta capa prueba propiedad, warranty transferible o reclamo comercial. No se mezcla con la evidencia privada: es el certificado publico del activo.
IOTA proof layer
Esta capa prueba que un evento existia sin mostrar el evento. Es ideal para DPP, QA, cadena de custodia y auditoria externa.
Demos publicos verificables
Estos casos no usan marcas reales ni datos sensibles. El backend calcula hashes canonicos, Merkle roots reales y muestra la transaccion IOTA testnet cuando ese caso ya fue anclado.
Logistica premium
Caja sellada, custodia y reclamo verificable sin exponer datos privados.
SHA principal
sha256:fd056fe8caf73243fec9c83075f2a693311cbcb5af81264c6ad0bf4388d2089d
Memo publico en IOTA
Demuestra que un paquete sellado tuvo custodia y entrega verificable sin publicar receptor ni manifiesto.
Pharma regulado
Lote sensible con temperatura, tamper y liberacion QA verificable.
SHA principal
sha256:46da892d32fdb4cca3fbf47fcb1a635a8ebd5580d47c023152af770ac9be7eb5
Memo publico en IOTA
Demuestra que un lote sensible tuvo liberacion QA, control frio y revision de tamper incluidos en un mismo root.
Agro quimico
Insumo agricola con origen, canal autorizado y uso responsable verificable.
SHA principal
sha256:0ea0478b694f01a5a76eda955a78c74701786b3d13ac241e6f6cfc3363938320
Memo publico en IOTA
Demuestra origen, canal autorizado, escaneo de campo y politica de reclamo para un insumo agricola.
Resultado
El hash existe dentro de uno o mas anchors. Si hay explorer_url, tambien se puede abrir la prueba externa.
Caso explicado
Un operador puede mostrar que el paquete fue sellado, transferido y entregado con evidencia hash-only. El comprador ve integridad; la empresa conserva manifests y datos sensibles dentro de nexID.
NFC 424 asignado al paquete antes de salir del deposito.
sha256:fd056fe8caf73243fec9c83075f2a693311cbcb5af81264c6ad0bf4388d2089d
El operador registra handoff sin publicar manifiesto ni identidad del destinatario.
sha256:a1981863bbd87e9e7f0871f048437a982a6efa4ffc3551904184ebd3dd6bb1ec
La entrega queda probada sin revelar receptor, documento ni direccion.
sha256:c46e3a8c5fce125d4b52f084c1f761fe1f93b3bf93d4176386003144f3ae94bf
Recibo publico on-chain
Demuestra que un paquete sellado tuvo custodia y entrega verificable sin publicar receptor ni manifiesto.
Para operaciones: el cliente ve una prueba externa de integridad; la empresa conserva la ruta completa, permisos y documentos en nexID.
nexID-proof-v1|case=secure-delivery|vertical=logistica-premium|resource=secure_delivery_pack:SDL-AR-2026-0007|events=3|root=sha256:f27117194b62885a39abda2e5dcb1dc70b3d31eb887acc56b7ba1439be674917|privacy=hash-only
Hash del memo
sha256:5f3d043787078d92611be1219039ca859afa08a413d3a3ac0f15e3007f38ad16
Capas del caso
activo
Fuente privada de eventos, permisos y manifest
testnet-ready
Merkle root para auditoria hash-only
opcional
Certificado de ownership o warranty separado
Como se conecta
Para gente normal
Que ese hash fue incluido en un anchor con fecha, provider, red, Merkle root y, si aplica, transaccion externa.
No reemplaza la validacion NFC/SUN, el dashboard privado ni el certificado Polygon. Es una prueba externa de integridad, no una copia de toda la base.
Mostras Demo Lab, elegis un evento de negocio, ensenas su hash y despues lo verificas aca. La empresa entiende privacidad, auditoria y compliance en menos de un minuto.
Solo se verifica el hash. La prueba no revela UIDs, manifests ni identidad del destinatario.
Polygon queda para ownership/certificados. IOTA/local proof queda para auditoria y DPP.
La API acepta POST JSON en /public/proof/verify y /public/proof/decode.
Mensaje comercial correcto
Proof Verify existe para explicar auditoria sin complejidad blockchain: el cliente no necesita ver contratos, wallets ni payloads privados para comprobar integridad.
Publico
case, vertical, resource class, event count, Merkle root, privacy policy
Privado dentro de nexID
UID/NFC secret material, customer or patient identity, route manifest, internal QA documents, commercial contract data
Anchors
11111111-1111-4111...1111111111
confirmedProvider
iota / iota-evm-testnet
Tx
0x37d65322827ba485...16fc6190c8
Proof Decoder
En IOTA EVM el memo queda dentro del campo Raw input. El explorer lo muestra como hex; nexID lo decodifica como texto UTF-8 y lo explica para gerencia, auditoria o ventas.
Lectura ejecutiva
Secure Delivery: este recibo publico confirma 3 eventos sobre secure_delivery_pack:SDL-AR-2026-0007 dentro del Merkle root sha256:f27117194b62885a39abda2e5dcb1dc70b3d31eb887acc56b7ba1439be674917.
Lectura de negocio: prueba custodia y entrega verificable de un activo fisico, sin publicar manifiesto, receptor ni direccion privada.
Explorer Decoder para C-level
Esto es lo que se copia del explorer. Se ve como hex, pero representa el recibo publico escrito en la transaccion.
0x6e657849442d70726f6f662d76317c636173653d7365637572652d64656c69766572797c766572746963616c3d6c6f676973746963612d7072656d69756d7c7265736f757263653d7365637572655f64656c69766572795f7061636b3a53444c2d41522d323032362d303030377c6576656e74733d337c726f6f743d7368613235363a663237313137313934623632383835613339616264613265356463623164633730623364333165623838376163633536623762613134333962653637343931377c707269766163793d686173682d6f6e6c79
Mismo contenido, sin hex: caso, vertical, recurso, cantidad de eventos, Merkle root y politica de privacidad.
nexID-proof-v1|case=secure-delivery|vertical=logistica-premium|resource=secure_delivery_pack:SDL-AR-2026-0007|events=3|root=sha256:f27117194b62885a39abda2e5dcb1dc70b3d31eb887acc56b7ba1439be674917|privacy=hash-only
Como se lo explicas a gerencia
Caso, tipo de recurso, cantidad de eventos, Merkle root y politica hash-only.
UID secreto, cliente, manifiesto, ruta, QA interno, precio, contrato y datos personales.
Auditoria externa sin convertir blockchain en base de datos publica. Sirve para ventas, compliance, DPP, QA y reclamos.
secure-delivery
Identifica el flujo que genero el recibo publico: Secure Delivery.
logistica-premium
Ubica la prueba en una industria o unidad de negocio: Logistica Premium.
secure_delivery_pack:SDL-AR-2026-0007
Clase secure_delivery_pack con referencia publica SDL-AR-2026-0007. No revela UID/NFC secreto ni cliente final.
3
Cantidad de hitos de negocio incluidos en el Merkle root: 3.
sha256:f27117194b62885a39abda2e5dcb1dc70b3d31eb887acc56b7ba1439be674917
Huella criptografica que resume los hashes de eventos. Si un hash cambia, este root deja de coincidir.
hash-only
Solo se publica evidencia minima. Los datos sensibles quedan dentro de nexID.
1. Explorer
Abrir memo tx y copiar Raw input.
2. Decoder
nexID traduce hex a contexto.
3. SHA
Verificar inclusion exacta.