#

l2

(54 articles)

Your Documents in an AI World: Why Our Platform Was Built for What's Coming

## Who We Are Block9 LLC is a blockchain consulting, education, and services company based in Missouri. We run workshops, advise businesses on blockchain strategy, and build products that put decentralization to work. Our dApp — a document tokenization platform built on the Stacks blockchain — is our first product, and it's the direct result of what our team has learned across more than 15 years in enterprise technology and nearly a decade in Bitcoin. Our team's roots go back to 2010 in corporate IT — virtualization, cloud computing, EHR systems, and CRMs. We've lived through many waves of enterprise infrastructure. In 2017 we got into Bitcoin. In 2021 we started building on Stacks. In 2024 we launched Block9 to bring all of that experience together: enterprise tech knowledge, blockchain conviction, and a product that solves a real problem. Our dApp runs on Stacks, a Bitcoin Layer 2 network. Through Stacks' Proof of Transfer (PoX) consensus mechanism, miners submit block-commit transactions to Bitcoin that include hashes of Stacks blocks, recorded in the OP\_RETURN field of Bitcoin transactions. This means the entire history of the Stacks chain — including the integrity records for every document on our platform — is cryptographically anchored to Bitcoin's blockchain. To be clear: your actual document content never sits on Bitcoin or Stacks. *The encrypted content lives on IPFS or in your offline vault.* What* goes on-chain is the cryptographic fingerprint *that proves your document is authentic and untampered — *along with the full ownership record, signatory roles, sharing permissions, amendment history, and authority rules that govern the document. *That's a complete governance layer living permanently on the blockchain. After the Nakamoto upgrade, reversing any of it would require reorganizing Bitcoin itself. We're not just a document platform. But the dApp is where our mission becomes tangible: give people and organizations full, sovereign control over their most important documents — with no middleman standing between them and what's theirs. Block9 cannot see our end users documents. ## What We're Focused On ### Three things define the product: **Document tokenization.** When you create a document on our platform, it becomes a blockchain-native NFT. Not a gimmick — a real cryptographic record. A unique fingerprint of your encrypted content is written permanently to the Stacks blockchain, and through PoX, that fingerprint proof record is anchored to Bitcoin. Your actual document stays encrypted on IPFS or offline — only the fingerprint goes on-chain. That fingerprint can never be altered, deleted, or disputed. You can prove exactly what you created, when you created it, and that it hasn't been tampered with. Client-side encryption you actually control. Every private field in your document is encrypted inside your browser before it ever touches a network. The encryption key is ***generated locally and stored on your device* **— or exported to an offline vault file protected by a memory-hard algorithm designed to resist brute-force attacks from even the most powerful hardware. **We never see your keys. We can't recover them.** That's by design. On-chain identity and authority. Your verified credentials serve as your master identity on the platform. They control every document bound to them. Authority transfers, signatory roles, amendment histories, sharing permissions — all enforced by smart contract logic on-chain, not by an app-level permission system that someone could override from a dashboard. ## The Problem Traditional Apps Can't Solve The rise of AI changes the threat landscape for documents in ways most traditional platforms aren't built to handle. AI can now generate convincing fake contracts, forge signatures on PDFs, fabricate realistic credentials, and produce deepfake media — all in seconds. The question is no longer "does this document look real?" It's "can you cryptographically prove this document is the original?" Traditional document platforms — the leading cloud storage, e-signature, and collaboration tools most businesses rely on — were designed for a pre-AI world. They operate on a trust model: you trust the company to store your files securely, to verify signatures honestly, to keep access logs accurately, and to not be breached. That trust model has three structural problems that AI is accelerating. ### Problem 1: Centralized servers are high-value AI targets Traditional platforms store your documents, your keys, and your identity credentials on their servers. That makes them a single point of failure — and a single point of attack. AI-powered reconnaissance, credential stuffing, and social engineering are making breaches faster and cheaper. When a centralized platform is compromised, everything inside it is exposed at once. With our platform, there's no central vault to breach. Your encrypted documents are distributed across IPFS. Your encryption keys exist only on your devices. Your identity and document records are on a public blockchain. An attacker would need to compromise your individual browser, your wallet, and your encryption keys — to access a single document. ### Problem 2: Trust-based verification doesn't survive AI forgery When you receive an e-signature envelope from a leading provider, you're trusting their servers to tell you the signature is authentic. When you open a PDF, you're trusting the sender. When you view a document in a popular collaboration tool, you're trusting their version history. AI makes that trust fragile. A convincing deepfake of a signed document, a forged audit trail, a manipulated version history — these are increasingly trivial to produce. And the verification step still comes down to: do you trust the platform? On our platform, verification is mathematical, not institutional. The viewer decrypts your document, computes a cryptographic hash of the content, and compares it against the immutable hash record stored on-chain. If they match, the document is verified. If they don't, it's been tampered with. No server needs to vouch for it. No company needs to be trusted. The cryptography either checks out or it doesn't — and that on-chain proof record is anchored on chain. ### Problem 3: You don't actually own your documents On traditional platforms, your documents live on someone else's infrastructure, governed by someone else's terms of service. The platform can change access, revoke features, shut down, or be acquired. Your data goes with it. On our platform, your document is an NFT you own in your wallet. The encrypted content lives on IPFS (or fully offline in a vault file you control) — not on the blockchain. What lives on-chain is the ownership record, the integrity hash, the signatory roles, sharing permissions, amendment history, and the authority rules that govern the document (plus any other fields you deem public). That's not just a receipt — it's a full governance record for your document, permanent and permissionless, that exists as long as the chain exists. No company can revoke your access to your own document, because no company controls the blockchain it lives on. ## What This Means in Practice We've already built over 80 document types with more than 1,300 fields — from certificates of authenticity and bills of sale to tickets, passes, agreements, and invoices. Users can also build their own reusable templates through our template creation system, tailored to their specific workflows. This isn't a proof of concept — it's a near production-ready platform with the depth to handl documents across industries. When you tokenize an agreement, a bill of sale, or a certificate of authenticity on our platform, you're creating something that can be independently verified by anyone, anywhere, without trusting any company — including us. A business partner can verify a signed agreement without relying on a SaaS provider's audit log. A buyer can confirm a bill of sale is the original, unaltered version. An AI agent acting on your behalf can present a pass or invoice that's cryptographically provable, not just a PDF someone could have fabricated. Our team's years of experience working with digital records in enterprise environments — directly shaped how we designed this platform. We understand how records are created, stored, shared, audited, and disputed in the real world. That operational knowledge is baked into every document type, every field structure, and every permission model we've built. That's the shift. In an AI world, provability replaces trust. And provability requires cryptography, immutability, and user-controlled keys — not better cloud security on someone else's server. ## The Bottom Line AI is making document forgery trivially easy. The platforms most people rely on were built before that was a real threat, and their architecture — centralized storage, server-held keys, trust-based verification — isn't built to withstand it. Block9 was designed from the ground up for a world where you can't trust what you see — only what you can prove. Client-side encryption. Bitcoin-anchored proof records. User-controlled keys. On-chain authority. No middlemen.\ \ Our goal from the ground up has been to extend the existing principles that Satoshi Nakamoto put forth to a document-focused solution, one based upon *"crypto-proof instead of trust". *We're excited for our upcoming V1 launch and look forward to learning and improving every step of the way. ![](https://blossom.primal.net/44a5d3b943aea7a74fe5c57cb8e4d405ed3b6bf6ee56c49cc2a7ab4166de00b3.jpg) ### Your documents. Your keys. Your proof. Get in Touch Website: [www.block9.app | ](http://www.block9.app)Email: [sales@block9.app | ](mailto:sales@block9.app)Phone: (636) 224-8069 dApp: Launching soon. Patent pending. *Block9 LLC is a software service provider — not a financial advisor, legal expert, money transmitter, or investment advisor. We are focused on technology and provide software services. Nothing in this article or on our platform constitutes financial, legal, tax, or investment advice. Documents created on our platform are tokenized using blockchain technology but do not constitute legal instruments unless applicable law in your jurisdiction recognizes them as such. Consult qualified professionals for any financial, legal, or compliance decisions. All blockchain transactions are final and irreversible.*

Camada de Mercúrio, protocolo Bitcoin MPC camada 2

Tecnologia de escalonamento #Bitcoin Layer-2 baseada no conceito de statechains, que permite que chaves privadas para depósitos BTC (UTXOs) sejam transferidas com segurança entre proprietários fora da cadeia. Mercury Layer é uma implementação de um protocolo statechain de camada 2 que permite a transferência e liquidação fora da cadeia de saídas de Bitcoin que permanecem sob a custódia total do proprietário o tempo todo, enquanto se beneficia de transações instantâneas e de custo zero. A capacidade de realizar esta transferência sem exigir a confirmação (mineração) de transações em cadeia tem vantagens em uma variedade de aplicações diferentes. um sistema de transferência e controle de propriedade do Bitcoin, especificamente focado em saídas de transações não gastas (UTXOs), um resumo detalhado dos principais elementos e procedimentos do sistema: 1. Saída de Transação Não Gasta (UTXO): UTXO é a unidade fundamental que representa valor e propriedade no Bitcoin. Cada UTXO é identificado por um ID de transação (TxID) e um número de índice de saída (n) e possui duas propriedades essenciais: valor em BTC e condições de gasto, definidas em um Script. As condições de gasto geralmente envolvem uma chave pública que requer uma transação assinada com a chave correspondente. 2. Transferência de Propriedade sem Transação On-Chain: O sistema permite a transferência de propriedade de UTXOs controlados por uma única chave pública (P) de uma parte para outra sem a necessidade de executar transações na cadeia (on-chain) do Bitcoin ou alterar as condições de gasto. Isso é facilitado por um mecanismo chamado "Statechain Entity" (SE). 3. Compartilhamento de Chave Privada: A chave privada (s) para a chave pública P é compartilhada entre o SE e o proprietário. No entanto, nenhuma das partes conhece a chave privada completa. Isso requer cooperação entre o proprietário e o SE para gastar o UTXO. 4. Atualização/Transferência de Chave: A propriedade do UTXO pode ser transferida para um novo proprietário através de um processo de atualização de chave. Isso envolve a substituição do compartilhamento de chave privada do SE para que corresponda ao compartilhamento de chave do novo proprietário, tudo sem revelar compartilhamentos de chave ou a chave privada completa. 5. Transações de Backup: Além da transferência de propriedade, o sistema inclui transações de backup que podem ser usadas para reivindicar o valor do UTXO pelo atual proprietário, caso o SE não coopere ou desapareça. Essas transações são assinadas cooperativamente pelo proprietário atual e pelo SE e possuem um bloqueio de tempo (nLocktime) que permite a recuperação dos fundos em uma altura de bloco futura especificada. 6. Mecanismo de Redução do Backup de Timelock: Para limitar o número de transferências possíveis durante um período de tempo, o sistema utiliza um mecanismo de decremento do nLocktime. O usuário é responsável por enviar as transações de backup no momento adequado. 7. Cadeias Estaduais (Statechains): O sistema opera usando cadeias estaduais, que são uma camada adicional que permite a transferência de propriedade de UTXOs. O SE precisa seguir o protocolo, mas não armazena informações sobre compartilhamentos de chave anteriores. 8. Cegagem (Blinding): O servidor da camada Mercury (SE) é cego, o que significa que não tem conhecimento das moedas que está assinando. Isso é alcançado através do uso de criptografia de chave pública para ocultar informações de chave privada compartilhada entre as partes. 9. Protocolo de Camada Mercury: O protocolo detalha os procedimentos desde o depósito inicial até a transferência de propriedade, atualizações de chave, retiradas ordenadas e recuperação de backup. 10. Recuperação de Backup: Caso o SE não coopere ou desapareça, o proprietário atual pode recuperar os fundos, enviando a transação de backup quando o nLocktime for atingido. 11. Publicação de Compartilhamento de Chaves: O SE não tem acesso aos IDs de transação individuais das moedas, mas publica compartilhamentos de chaves públicas para cada moeda na lista de ativos. Essa lista é comprometida com a blockchain para provar a exclusividade da propriedade. Este sistema é projetado para fornecer uma maneira segura e eficiente de transferir e controlar a propriedade do Bitcoin, permitindo a recuperação de fundos em caso de problemas com o servidor. No sistema de controle de propriedade de saídas de transações não gastas (UTXOs), cada UTXO é uma chave compartilhada composta por duas partes: o proprietário e o servidor de compartilhamento. Juntos, eles colaboram para criar transações de backup com bloqueio de tempo, que transferem a propriedade da UTXO para o novo proprietário. Durante essa transferência, a chave pública compartilhada permanece inalterada, mas o compartilhamento da chave do servidor é atualizado por meio de um Protocolo de Computação Multifuncional (MPC) para se alinhar apenas com o novo proprietário. Essa atualização resulta na criação de uma nova transação de backup, direcionada à chave pública do novo proprietário, com um tempo de bloqueio mais curto. A confiabilidade do servidor é essencial, pois ele é responsável por excluir o compartilhamento de chave anterior. Isso garante que não seja possível conspirar com os proprietários anteriores. O proprietário atual pode gastar a UTXO a qualquer momento, desde que o faça em cooperação com o servidor. No entanto, se o servidor for desligado ou desaparecer, o proprietário atual deve aguardar até que o tempo de bloqueio expire antes de enviar sua transação de backup. É importante ressaltar que o remetente nunca possui a chave privada completa; ele possui apenas uma parte do compartilhamento. Assim, todas as transações requerem a assinatura conjunta do servidor. Quando a UTXO é transferida para um novo proprietário, o compartilhamento do servidor é atualizado para que ele não possa mais assinar em nome do proprietário anterior, apenas em nome do novo proprietário. Esse sistema de transações de backup com bloqueio de tempo é projetado para proteger contra cenários de não cooperação ou apreensão do servidor, garantindo a segurança das UTXOs e a integridade da rede. https://github.com/layer2tech/mercury-wallet https://mercurylayer.com/ https://twitter.com/TTrevethan/status/1689929527420387328?t=0f5oF6w_ZRjWRYGah3HX8Q&s=19