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
Ejemplo pensado para una empresa pharma enterprise: la auditoria confirma existencia e integridad del evento sin publicar datos de pacientes, rutas privadas ni documentos de calidad.
QA aprueba el lote y calcula evidencia minima del evento canonico.
sha256:46da892d32fdb4cca3fbf47fcb1a635a8ebd5580d47c023152af770ac9be7eb5
Sensor o operador confirma que el rango frio se mantuvo.
sha256:1e3e1a4f15024a7f029c474e7848208c954b467e6989071864fe1504eb9e100d
El sello llega intacto y queda listo para auditoria o reclamo.
sha256:92fdd6fc4a58cbd646c1f54ada796b6c052079d9a32c2a854a3afa2a4b1d2a89
Recibo publico on-chain
Demuestra que un lote sensible tuvo liberacion QA, control frio y revision de tamper incluidos en un mismo root.
Para calidad/regulatorio: la prueba sirve para auditoria, DPP y reclamos sin publicar pacientes, certificados internos ni rutas privadas.
nexID-proof-v1|case=pharma-cold-chain|vertical=pharma-regulado|resource=pharma_batch:PHR-LOT-2026-0142|events=3|root=sha256:1e22212d42fc7a553cd08c8e7e8f4fcf5b76b74e461dcf967ed934c230b016c7|privacy=hash-only
Hash del memo
sha256:a866ca593d0e90ea805203730a86c63a1eddd5290d67a4989451f717c38cee03
Capas del caso
activo
QA, permisos, evidencia offline y dashboard privado
testnet-ready
Anchor externo de integridad para auditor o inversor
opcional
Ownership transferible solo si el caso comercial lo necesita
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
22222222-2222-4222...2222222222
confirmedProvider
iota / iota-evm-testnet
Tx
0x08435e67455a82e1...5fe686a13a
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
Pharma Cold Chain: este recibo publico confirma 3 eventos sobre pharma_batch:PHR-LOT-2026-0142 dentro del Merkle root sha256:1e22212d42fc7a553cd08c8e7e8f4fcf5b76b74e461dcf967ed934c230b016c7.
Lectura de negocio: prueba que un lote regulado tuvo hitos de calidad incluidos en una evidencia publica, sin exponer pacientes, rutas internas ni documentos QA.
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.
0x6e657849442d70726f6f662d76317c636173653d706861726d612d636f6c642d636861696e7c766572746963616c3d706861726d612d726567756c61646f7c7265736f757263653d706861726d615f62617463683a5048522d4c4f542d323032362d303134327c6576656e74733d337c726f6f743d7368613235363a316532323231326434326663376135353363643038633865376538663466636635623736623734653436316463663936376564393334633233306230313663377c707269766163793d686173682d6f6e6c79
Mismo contenido, sin hex: caso, vertical, recurso, cantidad de eventos, Merkle root y politica de privacidad.
nexID-proof-v1|case=pharma-cold-chain|vertical=pharma-regulado|resource=pharma_batch:PHR-LOT-2026-0142|events=3|root=sha256:1e22212d42fc7a553cd08c8e7e8f4fcf5b76b74e461dcf967ed934c230b016c7|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.
pharma-cold-chain
Identifica el flujo que genero el recibo publico: Pharma Cold Chain.
pharma-regulado
Ubica la prueba en una industria o unidad de negocio: Pharma Regulado.
pharma_batch:PHR-LOT-2026-0142
Clase pharma_batch con referencia publica PHR-LOT-2026-0142. No revela UID/NFC secreto ni cliente final.
3
Cantidad de hitos de negocio incluidos en el Merkle root: 3.
sha256:1e22212d42fc7a553cd08c8e7e8f4fcf5b76b74e461dcf967ed934c230b016c7
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.