Kelly Birr | Neil Taylor | David Iseminger
ironweave@upheaval.io
www.ironweave.io
Version 2026.2
A blockchain fabric of unlimited scale, with digital interactions involving any number of participants, any type of data, providing an integrated value exchange would herald a new and vastly more private and secure computing environment. Such a fabric would require next-generation improvements in current blockchain architecture to meet expanding demand in consumer, business, finance, industry, and digital asset environments. IronWeave achieves this by creating a multi-dimensional blockchain fabric with unlimited individual chains, immutably and securely weaving participants together using a shared block created with each independent interaction. The result of IronWeave’s novel and unique architecture is a fabric of unlimited scale, unlimited flexibility, inherent privacy, quantum-ready security, and unmatched integrity, making it the essential infrastructure for programmable digital currency and privacy-preserved AI-driven economies.
## **1. Introduction** Despite significant cryptocurrency circulation and large market caps for some, a common collection of limitations has prevented current offerings from realizing blockchain’s potential as a secure, pervasive, disruptive, transformational digital medium. What is needed is a blockchain fabric with the scalability to match the world’s digital and currency demands, the flexibility to accommodate the diversity of imagined uses, types of data, all with the security facilities to enable individuals, groups, institutions and commercial entities to engage safely, and privately, when privacy is desired. The blockchain fabric must also be holistic, enabling each participant to engage with any other, when permitted, with the capability to interact with data both inside and external to the fabric itself. IronWeave introduces a novel approach to blockchain technology, using unique shared-block architecture to address the need for an environment with massive scale, exceptional security, intentional privacy, interoperability with existing systems, and the facility for true global decentralization. Its shared-block architecture creates a multi-dimensional blockchain fabric that removes limits inherent to current blockchain approaches. To facilitate the explanation, we must contrast the shared-block architecture of IronWeave to current blockchains, which we refer to as monolithic blockchains. In all monolithic blockchains, such as Bitcoin\[1] and Ethereum, and blockchains in Polygon or Cosmos, each block is created and connected in linear series to the previous block, using a hash of the previous block for immutability. This is similar to a physical chain, where each link is connected to the immediately previous link. This approach requires blocks to be created serially (one after the other) and in uni-dimensional fashion, which inherently limits scale, flexibility, responsiveness, and other aspects. In IronWeave’s shared-block architecture, there is no limit to the number of blockchains that exist within the fabric. A block is created when two or more participants interact (each participant is an independent blockchain, referred to as a \_chain\_for simplicity), creating a shared block that is placed on each participant’s chain. The shared block includes a hash from each participant chain’s previous block, connecting those two or more participant chains for immutability. Subsequent interactions may be with different participant chains, thereby interconnecting each chain with every other chain with which it interacts, as well as each chain with which it previously interacted, fanning out over time in a multi-dimensional mesh. In addition, each block is independently encrypted with its own unique keys and thus, each block can only be decrypted by the participants of that individual shared block.  Many benefits can be realized with IronWeave’s shared-block architecture. For purposes of clarity and brevity, we focus this paper on its benefits for scale, security, privacy and its ability to create a blockchain data system of ample performance (measured in interactions per second, which is similar to transactions per second, or TPS). ## **2. Interactions** In IronWeave, a block is created whenever two or more chains engage in an interaction. A chain in IronWeave can represent any person, process, place, device, object, event, currency exchange, or anything else that might participate in an interaction involving data. In IronWeave, a digital currency token is simply one type of data that requires specific, robust and secure validation. Other types of data may also require validation, whether specific or generic; validation of any such data becomes possible with IronWeave’s extensible validation architecture. A single person may have one or a collection of chains, containing data of many sorts, including digital currency, and organizations may have thousands or millions of purpose-driven chains. The concept of an initiator and one or more participants exists for a given interaction. Such interactions are of concern and accessible only to those participating in the interaction, and are otherwise unknown and inaccessible to any other participants in IronWeave. With no limit to the number of chains in IronWeave, participants A and B can create an interaction, while simultaneously participants X, Y, and Z can create a separate interaction, in parallel and with no bearing or impact on the other. Indeed, participants A and B have no knowledge of X, Y and Z’s interaction nor access to that interaction by any means, and vice versa. There is no limit to the number of simultaneous parallel interactions that can occur between or among the independent-chain participants in IronWeave. As such, the IronWeave architecture provides facility for unlimited horizontal scale.  As interactions increase, additional nodes can engage, thereby distributing scale horizontally with each additional node. With each shared block, multiple duplicates of the block are immediately dispersed to further decentralization and opacity. Any given block is placed on many dispersed nodes, however it need not be propagated to every node; only to enough nodes to mathematically ensure reconstitution should the need arise. IronWeave is agnostic to the type of data in each block; its shared-block architecture results in the ability to create blocks of any reasonable size, using any type of data for any purpose, whether that be value exchange (such as digital currency, native to IronWeave or otherwise), secure messages, application usage data, contract execution, physical or medical sensors, private real-time communications, IoT connectivity, supply chain management, NFTs, and others. Among other benefits including scalability, performance and low latency, IronWeave’s shared-block architecture results in the entire platform, and each block, becoming more secure with ongoing interactions. As shared blocks are created, chains are immutably interconnected with each participant’s previous block hash, strengthening and hardening the entire fabric with each shared block much like concrete cures over time. ## **3. Privacy and Security** When an interaction occurs between two or more chains in IronWeave, each participating chain submits a hash of its previous block to include in the new shared block. With three participants, the new shared block will contain three different hashes – one from each participant. In addition, each block in IronWeave is issued its own set of encryption keys ensuring only participants in that shared block can access its contents, further protecting and securely isolating each interaction on IronWeave as it occurs, ensuring that the content of each block is private to (accessible by) only its participants. Such security mechanisms are pervasive in IronWeave, whether the data is created natively in IronWeave, or imported/ingested from an external data source and brought into (or onto) an IronWeave chain. With each interaction, likely among different participants than the previous block, the expanding weave of hashes interconnecting and securing blocks becomes multi-dimensional, hardening immutability and making any attempted unraveling or tampering exceptionally difficult. The concept of sharing information exists, where a participant can share a single block, a collection of blocks based on type, category, time constraint, or any combination thereof, or an entire chain can be shared with one entity or person, a collection of entities, or everyone. From a security perspective, each block is encrypted with its own set of keys, rendering the block accessible only to the participants in that shared block, specific to each atomic interaction (rather than many interactions aggregated into a larger block), with its existence known only to participants. From a privacy perspective, since each block is independently encrypted, and with no central chain to which all blocks must reconcile, there is no central chain acting as a single point of recordation or exposure, preventing existence of a single structure to which all activity would otherwise be accessible or vulnerable to anyone watching, snooping, waiting, analyzing, or exporting. ### **3.1. Next-Generation and Quantum Security** IronWeave’s security is engineered to be future-proof and quantum-resistant. The fabric’s cryptographic agility is achieved because encryption is componentized and modular, allowing for straightforward upgrades to post-quantum or advanced encryption standards as they mature and become available. This architectural design enables new block data to be secured using forthcoming advances in quantum-resistant encryption, protecting applications against evolving cryptographic threats. Furthermore, the architecture provides ransomware resistance as each block is its own atomic data unit, each block is uniquely encrypted and, if tampered with, can be automatically reconstituted by a duplicate copy, mitigating centralized data compromise, large-scale data exposure, and data loss and corruption risks. ### **3.2 Block Payload Encryption** The payload of any given block in IronWeave may contain a combination of clear and encrypted information, or data. Encrypted data uses a uniquely generated *payload key* for each block, which is encrypted with the public encryption key (not the signing key) of every chain in the interaction and/or every allowed reader. The IronWeave fabric and its various nodes have zero knowledge of the encrypted data, and at no point does the IronWeave fabric gain the keys to decrypt such data. ### **3.3 Block and Chain Security and Granular Control** While anyone can use IronWeave tokens (ISE) to engage, participate, or integrate data and applications into the IronWeave fabric, each independent chain within IronWeave requires authenticated credentials to gain access to any chain in the fabric. Data on IronWeave is not open to the public domain, and is encrypted in transit and at rest, visible only to permissioned parties (which are the participants in any given block-creating interaction). IronWeave considers all data to be private and takes appropriate precautions to secure such data from unauthorized access, on a block-by-block basis. The security model offers granular access control, allowing data owners to define exactly who or what (including specific AI agents) can read, write, or reference each data object. Accordingly, a validator will never offer the HEAD or metadata of any chain in IronWeave unless the requester can prove knowledge of the keys to said chain or block with a Zero-Knowledge proof (a ZK proof). A similar ZK proof is required to retrieve any block from a node, to ensure the requester is an authorized reader of that chain’s data, unless the chain’s Access Control List (ACL) is intentionally set to *public* (or some similar permissive intentional setting) by its owner. ## **4. Fabric** A data fabric is a unified environment of data, interconnected technologies, and services. By virtue of its shared-block architecture, the multi-dimensional independent interactions among various participants, and the capacity to address any chain within IronWeave, IronWeave becomes a holistic, interconnected, globally scalable and extensible data, compute and currency system fabric. With IronWeave’s security architecture, it is possible to create secured ‘walled gardens’ within which interactions among allowed participants (e.g., a consortium within IronWeave that limits participation to members, a geographical region within which created data remains, a collection of nodes where certain data restrictions apply to meet compliance requirements, others) is created and secured against common interactions. Such walled gardens in IronWeave are called a *Region*. Exchange of value and shared or private data, either within a single organization or a secure group, is unaffected.  A holistic fabric could include services such as the following, whether on a global scale or reserved for approved participants (i.e., consortium, organizational, industry-wide, corporate, other). A credentials system could ensure provenance, enabling issuers, holders, or allowed verifiers to quickly determine authenticity, held by the individual or organization presenting it, and validate its current status with immutable certainty. Such a counterfeit- and fraud-resistant system could be used to issue licenses, educational degrees, safety qualifications, identity verification, passports, and many other credentials. Data residency could be assured by preventing data created in a region from leaving (via constrained propagation) its country or region of origin. Supply chain and RFID integration can be achieved with creation of industry-specific block categories that map to supplies, goods, regulation, oversight, and compliance, all ensuring service level agreements are met during transport by integrating IoT devices with IronWeave data and custom block types. Regulatory compliance could be streamlined using block categories specific to a regulated industry. Activities or events requiring compliance can have the owner’s compliance chain an automatic participant, with a customized data share event with the regulatory agency to provide compliance activity details, or even specific forms and submissions. Such systems could automate compliance, fee collection, or statutory requirements for documentation. An oracle, or a system or oracles, could be created with the ability to manage subscriptions or fees for approved subscribers to the validated data feed. A validator infrastructure could be created, independent of the IronWeave validator infrastructure, that confirmed the source or veracity of such data meeting integrity or checking requirements set forth. Each feed could be its own chain, each update its own block, and subscribers could read the block (with permission) or be participants in the shared block and have a listener chain automatically updated with the shared block from the oracle, thereby enabling any combination of events to be triggered based on the results of such oracle data or event. An exchange could be created, with an independent chain dedicated to the exchange, or one chain for each asset offered on the exchange, with price updates written as independent blocks on said chain(s). With no limit to the number of interacting chains and sub-second block creation times, a multitude of options exist for creative finance applications on IronWeave, all of which can inherit whatever level of per-chain or per-block privacy the creator wants to implement or enforce. A traditional financial services application could interact in IronWeave using IronWeave language-agnostic APIs, enabling the existing finance software to interact with digital currencies – any digital currency that is bridged into or interoperates with IronWeave – allowing execution of sensitive code to reside on institutional premises, but interactions to occur within IronWeave. Such an application (or collection of applications) could create shared blocks in IronWeave with select participants, leveraging the security and privacy inherent in IronWeave, yet gain access to the ecosystem of digital currencies and decentralized finance resources, providing a ‘foot in both worlds’ environment that is secure, extensible, immutable, with each interaction instance private to its participants, and each interaction encrypted with its own set of keys. General blockchain development can also occur, without the need to run a node. IronWeave APIs are compatible with nearly all modern programming languages, providing flexibility and widening the potential development community to include traditional enterprise companies, institutions and agencies, large integrators, or solution providers. ### **4.1 Chain versus Address** In most public blockchains, each account, wallet, participant, or contract has an *address*, and all transactions across all addresses are grouped into global blocks by the blockchain’s miners (using bidding for placement with a high enough fee, or bribery) and committed to the monolithic chain. In contrast, in the IronWeave fabric there are unlimited independent chains that have properties similar to basic addresses on monolithic chains. In contrast to other public blockchains, and in contrast to all monolithic blockchains, IronWeave does not create global blocks. IronWeave blocks only include one or more chains as participants in the shared block, but never all, creating a fabric of interconnected chains that dramatically increases performance while also improving privacy, security, and efficiency. Users of monolithic chains can have multiple addresses; in a corollary but vastly more expansive concept, users in IronWeave can have multiple (and indeed, an unlimited number of) independent chains, for various reasons, and can create new chains for any purpose or activity. The ability for users or organizations to have unlimited chains in IronWeave, and the flexibility of use or purpose for any given chain in IronWeave, provides opportunity for developers to add functionality, value, service, or unique solutions for either independent chains, unique block types when applied to a given chain or set of chains, or any combination thereof. Such flexibility of independently interacting IronWeave chains and custom block or block types in IronWeave enables many of its advanced capabilities. It also provides further opportunity for the transition of existing services onto IronWeave (such as web2 services, to provide parity of existing functionality within IronWeave plus the advantages available within such a novel blockchain fabric), and for the creative development of net-new applications with globally scalability, private and secure atomic interactions and shared service types, immutability, and other advantages unique to blockchain, and more so, to the IronWeave blockchain fabric. Such atomic interactions and privacy-enabled chains go far beyond the basic addresses found in most blockchains today, and bring about a generational advancement in functionality for any application built on, transitioned to, or integrated with IronWeave. ### **4.2 Applications on IronWeave** IronWeave does not suffer from the same application limits or constraints that exist with monolithic public blockchains. IronWeave does not require a specialized language for applications, nor is it necessary on IronWeave to deploy applications onto the chain network as open-source smart contracts. Instead, IronWeave-enabled applications can be developed in nearly any modern programming language, and run on nearly any platform, cloud, server or device, and from there can interact with the IronWeave network using high performance industry-standard gRPC APIs. IronWeave applications author their own block payloads (referred to as *proto-blocks*) and can place them onto any chain they own, enabling developers or integrators to organize and prioritize interactions and transactions in whatever manner is most beneficial to the application. These proto-blocks are submitted to the network, for validation and co-signature (if such validation is required), and once validation is achieved (if required), the block is written to the fabric. An application can own any number of chains, which can interact on the IronWeave fabric (or with any data source or external chain that has been connected to IronWeave) with efficiency, flexibility, and exceptional performance, and importantly, can do so deterministically. Developers or their applications and services are never required to bribe miners with high gas fees to get IronWeave blocks or transactions recorded quickly; a distinct and welcome departure from current environments (and constraints) of most monolithic blockchains. IronWeave’s infrastructure is designed and engineered to handle multiple applications running simultaneously, without the need to wait for a single centralized block to be organized, transactions selected (or excluded) and eventually minted to any central chain. In IronWeave, application blocks can be created and placed independently of any other interaction happening on the IronWeave fabric, at any given time, in parallel. Such flexibility, independence and timeliness on IronWeave enables development and deployment of time-sensitive or scale-sensitive applications that otherwise would never be considered on existing public, monolithic chains. ### **4.3 Data Ingest into IronWeave** Data is published on an IronWeave chain by an application. This is similar in concept to how smart contracts record information on existing public chains, but infinitely more flexible. Blocks in IronWeave are flexible and agnostic to data payload, with no set size or type. Block types, and entire categories of block types, can be designed and specified in size, fields, or other attributes to facilitate any type of application or use. This is similar to how DNS Resource Records, of various types and structures, facilitate creation of unlimited underlying services with unique yet deterministic structures, providing advantages that only such extensibility can provide. Such block types or categories can be universally defined and available (within the fabric) or can be specific on an application-use basis. As such, an application defines their block payload of a specific *category* containing any combination of transactions and/or data. Even arbitrary data or files can be recorded on-chain and shared with other chains using shared blocks, which can be available to a subset of users (such as subscribers), all participants owned by a collection of users (like walled gardens), or by anyone with a presence in the IronWeave fabric (such as an oracle, or collection of oracle services). ### **4.4 Inbound from External Chains** The aggregate performance of IronWeave allows, among other things, the entire public chain of other networks, such as Bitcoin or Ethereum, to be written into unencrypted blocks on a single IronWeave chain that could be open and available for all IronWeave participants to read. The consuming applications could simply request the blocks from an IronWeave Storage node and act upon them, presuming such applications are able to read the native Bitcoin block data structure. Alternatively, an application (created natively or by third party developers) could read the Bitcoin chain and deconstruct the block data into an IronWeave standard *public token record* format (for example) and then write that onto some other chain for consumption. Creating such a *public token record* format would have the advantage of allowing applications to understand transaction data across multiple tokens and various chains, using one code base. The same can be done for other popular tokens, such as ETH and/or other ERC-20 contract tokens on Ethereum, enabling IronWeave to ingest and publish near-real-time data about other chains in the fast execution and horizontally scalable IronWeave fabric. ### **4.5 Outbound to External Chains** Publishing from IronWeave to any other chain is a simple process, involving a smart contact on the destination chain to record the information, and an IronWeave application reading the committed blocks from the source IronWeave chain. In the case of currency bridging, wrapping, or exchange, multiple outbound verifier applications could confirm the transfer to the locking chain on IronWeave, and then vote to release the tokenized funds on the destinations smart contract. This straightforward example is but one possible capability of using information created or stored on IronWeave to be used in other chains, for various reasons. ### **4.6 Infrastructure for AI** Unlike traditional defenses that fall short in AI contexts, IronWeave’s architecture provides a foundation for GenAI systems by treating every data object as a secure, independently encrypted container. This architecture, and each block acting as an atomic encrypted data unit, facilitates many otherwise unavailable capabilities. For AI economies the architecture facilitates seamless and secure payments, and data interactions, between autonomous AI agents. For provenance verification, each data unit (block) maintains a cryptographically verifiable origin and full audit trail, preventing models from training on poisoned data or generating hard-to-trace hallucinations. And for governance and compliance for AI, the architecture ensures a secure platform for tracking AI model instantiation, training and deployment, ensuring accountability through immutable records. The concept of an AI model marketplace within the IronWeave fabric extends the capabilities inherent to the IronWeave fabric such as data provenance, verification, and the concept of rent or leasing such AI models or capabilities, to any such models. Audits of AI agents become deterministic and any inputs or outputs are immutable, verifiable, and traceable by owners of such AI agent chains, or the source of their models or interactions. ## **5. Sequencing** In shared-block architecture, sequencing effectively supplants timestamps for the purpose of native ISE value exchange, and for many other data interactions. Timestamps are still a useful part of IronWeave in block creation, but the integrity of value exchange is not dependent on timestamps, and thus does not suffer from the risk of drift or the use of clocks that are out of sequence, or have timestamp-inherent dependencies or exposures. For example, if Chain A creates a shared block with Chain B, then Chain B creates a shared block with Chain C, it is possible to deterministically determine that the Chain A + Chain B block was created and placed prior to the creation and placement of Chain B + Chain C block, based on included hashes in Chain B and the sequence of events (based on hashes and chain height) without the need for, or potential conflict associated with potentially unsynchronous would-be timestamps. Effectively, the IronWeave fabric and its multi-dimensional collection of immutable and multi-hashed shared blocks become a mechanism for determining predecessors and successors of block creation, interop data sequencing, and other interactions in a graph-like format, including value exchange. ## **6. Transactions** A transaction is an interaction in IronWeave that exchanges value, such as an IronWeave Secure Exchange (ISE, pronounced “ice”) token, or a token from an external monolithic blockchain. Transactions must maintain integrity against elements such as double-spend, theft, counterfeits, and fraud. In monolithic blockchains, such requirements place significant constraints on scalability and performance and create onerous custodial and inadvertent loss risks for cryptocurrency wallet holders. In IronWeave’s multi-dimensional and flexible blockchain platform, many such limitations are resolved or significantly mitigated. The following paragraphs describe how transactions in IronWeave leverage its shared-block architecture. The process focuses on IronWeave’s native currency, ISE; however, the novel and secure approach to transactions in IronWeave also applies to digital currency (or other value-related data types) from data sources external to IronWeave, including cryptocurrency from other blockchains bridged into IronWeave, when interacting (whether through block creation, DApps, external integrated apps, custom-built solutions running in/on IronWeave, and others) within the IronWeave fabric. We begin with a few common tenets: all IronWeave Secure Exchange tokens (hereafter ISE tokens) are created within the IronWeave platform with verifiable genesis, balance and transaction history. All ISE exchanges occur and are recorded within the IronWeave platform. These initial tenets are common to monolithic blockchain value transfers as well. With IronWeave’s patented and unique shared-block architecture innovations, many aspects of value exchange evolve. In IronWeave, a chain is owned or controlled by an individual or by an organization. All chains have multiple layers of security, for access or for use in interactions. The following tenets are unique to IronWeave. ISE tokens reside in a block on individual chains within IronWeave. Multiple blocks on any given chain can store ISE (or other token) value. Any chain can be used for multiple purposes; it can be an individual’s only chain, or a purpose- or product-driven chain, and can contain various types of blocks or categories of interactions, in addition to holding ISE tokens. Some chains may be dedicated to holding currency. To spend ISE, an initiator submits a custom block type called a Spend block to the validator set for its Zone, which also includes the hash from its immediately previous block. Spend blocks are not allowed to enter a spend amount that exceeds the value + fee necessary to complete the spend. This custom block type (a Spend block, part of the Transaction category of custom IronWeave blocks) locks the spending chain until it receives the signed Transaction block from its validators, confirming verification of available ISE and successful completion of the transfer. The Spend block can only be written if the immediately previous hash matches the immediately previous hash in the submitted Spend block; this further protects against double-spend, attempted region spoofing, and ensures proper sequencing.  Validators ensure that spenders have sufficient ISE balance using a novel application of ZK proofs and confirm sufficient ISE currency balance to validate and complete the Spend block transaction. Upon a sufficient consensus among validators engaged in the Spend block request, spends (debits, for institutional nomenclature, and the opposite ledger credit) are written into a Transaction block and transmitted as a shared block to all participating chains. Since the spender’s chain is locked (no other blocks can be initiated, participated in, or completed) until the transaction is verified and complete, double-spend is resolved. This alleviates the inherent bottlenecks of validation by community block, as well as longest chain risk and latency; burden and risk are placed on the spender rather than the validation mechanism, with additional safeguards described later in this paper. Malformed spend requests are subject to forfeiture of some or all of the requested spend. Neutral actors attempting to spend ISE are unlikely to be confronted with forfeit of their requested ISE spend; only intentional attempts at nefarious or bad-actor submissions of illegitimate spend requests are likely to result in forfeiture. Multiple and varied injections of bad-actor controls and detection mechanisms will make stakes and forfeiture of malformed spend requests more difficult to create, more costly to inject, and subject to increased staking exposure. The concept of “canary” transactions to protect against improper processing or activities by validators, and adherence to staking commitments by such validators, will also be part of the validation process and architecture. The result is that ISE token transactions have a deterministic and private history, immutably detailed in the IronWeave platform and deterministically verifiable for ownership and validity across a compartmentalized (by Zone) collection of independent validators, and across each participant in each transaction. Keeping currency and other data on independent chains, rather than using traditional and simplistic accounts and wallets that are detached and subject to loss or inaccessibility, IronWeave utilizes its security, privacy and authentication infrastructure to enable any participant chain to store value, which provides multiple and extensible benefits, for ISE currency, other digital currencies, digital property, data, experiences and more. Instead of placing the burden of value verification on a central monolithic chain, which invariably results in performance constraints, IronWeave shifts the burden onto spenders. The shift to spenders alleviates the inherent performance constraints of a single bottleneck (the monolithic chain) and creates a horizontally scalable currency system that favors spender accountability and truly decentralized validator authorization, facilitates value exchange decentralization and accelerates finality. By introducing a myriad and regionally confined mesh of decentralized validators, a collection of scale, performance, decentralization, extensibility, and randomization is realized for any type of data validation, value exchange, or any other sort of economic activity that requires validation. Collectively, these advances in blockchain architecture facilitate a modernized value exchange environment that has inherent and vast capacity to grow (by adding Zones and validators as scale requires) and continually responds to the needs of an ever-expanding global digital economy. ### **6.1 Zones and Regions in IronWeave** IronWeave operates on the concept of Zones, similar to how the Domain Name System (DNS) uses zones for its horizontal scalability. Each Zone in IronWeave operates as an individual consensus boundary for the sake of validation and chain management. The Chain ID for an IronWeave chain identifies the Zone in which the chain operates. The Chain ID will use either 12 bits or 14 bits of its address space (initially) to identify the Zone in which it operates, resulting in an initial 4,096 or 16,384 available Zones. IronWeave will reserve 16 bits of the Chain ID address space for zones, resulting in the capacity for 65,536 Zones. Each Zone in IronWeave thus is capable of handling the throughput associated with a dBFT (Delegated Byzantine Fault Tolerance) consensus protocol, thereby enabling horizontal scalability. The boundary of a Zone is only used for consensus and is not an interaction boundary. For example, chains in different Zones can interact just as if they were in the same Zone, but any validation that must occur for such chains will happen in their “home” Zone. Traversing Zones in IronWeave is facilitated by the fabric itself and is transparent to users or applications. IronWeave employs multiple verification methods to create a global verification mesh that makes local collusion mathematically futile and economically ruinous, including randomized Validator assignment and rapid epoch rotation, witness notarization, fraud proofs, economic firewalls, and others. A Region in IronWeave is a special-purpose Zone. Just as a Zone is a chain and validator boundary, a Region is also a chain and validator boundary, but with specific and intentional constraints. Each Region can have different kinds of constraints applied, to meet the needs of various industry, uses, compliance requirements, geographical boundaries that must be observed, stringent encryption that must be used, or even constraints on the types of blocks or block categories that can be employed. There may be various reasons for creating a Region. There may be one (or many) Healthcare Region(s), where HIPAA compliance (for example) requires data handling or validation to occur in approved datacenters. There may be a Geographical Region where data must remain in a geographic region. There may be Government Region(s) where interacting with a specific government has additional constraints on the type of encryption used, the location and security of validators, and the availability of interactions (or constraints thereon) for any chain residing in that Region. There are many possible reasons for a special-purpose Region, just as there are many use cases for IronWeave (as either a transaction platform, a data platform, an AI-enabled platform, or others). In each Region, validator requirements will be established, and validators will be subject to both Proof of Stake (PoS), Proof of Performance (PoP), and Proof of Authority (PoA). Such requirements enable specific Regions to apply governance and/or operational constraints required for such engagements. Each Region is simply a single Zone in IronWeave, so the availability of Regions in IronWeave is also horizontally scalable. ## **7. Consensus and Validation** IronWeave uses a combination of Proof of Performance (PoP) and Proof of Stake (PoS) for the collection of node types that operate in the fabric. The combination doubly strengthens the fabric; PoP ensures performant and cost-effective transactions and data storage for end-users of the IronWeave fabric, and PoS ensures their incentive to ongoing operation of the fabric (and disincentive to act in ways counter to designed operation) are firmly in place. Any Spender submitting double-spend forfeits the spend, which is placed onto a special-use Philanthropy Chain. Any validator that submits a shared-block update with double-spend forfeits the double-spend amount, forfeits the fees associated with the transaction (to the Philanthropy Chain), and loses its slot as a validator. This mechanism is designed to operate and provide proper incentive and safeguards in IronWeave, and by providing affinity for traffic to validators that consistently further the performance and decentralization of participating nodes, ensures ongoing incentives for proper node operation. Validators can aggregate Spend blocks from multiple Spenders rapidly; validators are not subject to locks (only Spenders are subject to locked chains). Rapid verification of validity and available balance results in equally rapid aggregation of spends and finality. ### **7.1 Proof of Performance (PoP)** In IronWeave Zones, nodes are in a competitive environment to deliver on compute, transmission, storage, and validation performance, and also compete on cost (the cost of a given transaction, block creation, storage, so on). The underlying protocol implementation of PoP in IronWeave is an algorithmic combination of validation throughput, latency, cost per transaction, cost per byte (storage), and cost per read (block retrieval). The PoP protocol rewards high-performance nodes, though not at the expense or exclusion of other nodes in the Zone, nor oncoming (new) validators. The design of the IronWeave PoP protocol is to promote and maintain affordability (for customers), ensure consistency of costs (for customers), ensure competition among providers (nodes, whether validators or other nodes such as storage nodes, and others that may be introduced for future on-fabric services), and ensure economic viability (for node providers) and potential profit (better performance results in more traffic/activity/rewards) for providers as well. In effect, PoP is designed to facilitate decentralization of Internet storage and online services, where the rewards are based not on capitalistic aggregation, but on performance available to any newcomer or incumbent, on as equal footing as possible, with safeguards to ensure such equal footing is built into the protocol. For Regions, the IronWeave implementation of Proof of Authority requires validator nodes are authorized by a decentralized committee (DAO) based on many factors, including technical ability and capacity to provide robust validator services, and also on their alignment with the mission of privacy of individual and organizational online activities, including the exchange of property. Other technical or location requirements pertinent to the compliance requirements of the purpose of the Region are also applied. Proof of Authority applicants will also be subject to digital audits of their validator node activities. Such digital audits may take various forms, including processing of interaction types that can confirm their proper operation, submission of operation audit logs, and other mechanisms that will evolve, strengthen, and be refined during development and throughout operation. This alignment to the mission of privacy (for Regions in particular, and also for Zones in general) is not unlike the Guardians used in the LayerZero interop service, and many other crypto-related services that require the digital equivalent of: trust but verify. Proof of Stake (PoS) is a well-known protocol in blockchain technology and does not merit further explanation here. ### **7.2 Validation of Currency Transfers** A transfer of ISE, or any token in IronWeave (such as wrapped or burned/minted ETH or SOL, or a token natively minted on IronWeave), is a simple process that requires multiparty validation for the transfer to be valid. The following steps describe the process of transferring ISE or any other token in the IronWeave fabric: 1. The initiator (spender) authors the proto-block (a Spend block request) enumerating the outgoing transfers of tokens, or partial tokens, to one or more recipients. 2. The initiator includes all recipients of funds and initiates validation by submitting the proto-block to a validator. The responding validator confirms the block is the head-of-chain, locks the chain from any further activity until the spend request is complete and submits the request to the current lead validator for the chain’s Zone for the current Frame (a frame is a slice of time for which a validator for a given Zone is elected its leader). 3. The submitted spend is received by the Zone’s validators which then engage in validation and co-signing of the Spend block. 4. The spending chain is locked (no other blocks can be placed on the chain) while the validators evaluate the Spend Block on the spending chain, and using a novel ZK proof ensures the balance of the chain has sufficient available funds. 1. The validator and receiver chains do not need to be locked. 2. When validation succeeds, each engaged validator submits its co-signature on the block. 3. Once co-signatures are confirmed, the block commits and is placed on each participant’s chain, including initiator (spender), all recipients, and each co-signing validator. The spend process does not require the use of a smart contract for value transfer within the IronWeave fabric, further securing the process, and enabling privacy for participants in each spend/receive interaction. This is not dissimilar to how UTXOs operate on Bitcoin (no need for smart contracts). ### **7.3 Compliance** Value transfers in IronWeave are designed to enable compliance with applicable laws. The compliance infrastructure in IronWeave applies to deterministic and verifiable data types (such as value transfer, which must be validated for sufficient balance) and is extensible to an unlimited number of asset types and classes. The following steps describe the compliance process in the IronWeave fabric: 1. A compliance request is sent to a Governance Committee, overseen by the IronWeave Foundation (or other decentralized or DAO-based governance entity tasked with such governance, for example). 2. The Governance Committee determines whether the compliance request is valid, and whether to comply with the request. The Governance Committee will engage with appropriate legal counsel and representatives to ensure proper compliance. This process is common to technology providers and compliance requests\[2]. 3. If the request is valid, the request is placed on the shared Compliance Watch Chain (an IronWeave fabric chain), signed by the Governance Committee Team key. The request includes: 1. The Chain IDs included in the compliance request. 2. The Category IDs of the blocks (block types) being requested. 3. Time boundaries within which the compliance request is valid. 4. The Chain ID and public key of the (newly created) chain onto which compliance requests are to be written (the request-specific Compliance Response chain), in the form of encrypted blocks (of type: Compliance Response Block). 4. Validators watch the Compliance Chain for compliance request orders and process them in spare cycles. Sequencing and validator history enable IronWeave to determine that any given validator should have the block(s) in question, and failure to respond to the request is a potential slashing event and a factor in the validator’s score in PoP algorithms. 5. Each validator that finds a matching combination of Chain ID instance + block category + time boundary in its validated block repository re-encrypts any relevant block payloads onto the request-specific Compliance Response chain, using the chain’s supplied Chain ID and its public key. The design of IronWeave’s compliance architecture ensures the Governance Committee is unable to access or view data being reported, preserving the security and privacy of the compliance data. The process, once a request is deemed valid and placed onto the Compliance Watch Chain, is automated by the IronWeave validator binaries, and participation is mandated by validator node staking agreements. ### **7.4 Leader Election** When a validator is a leader, it is responsible to confirm back-references and head updates to other nodes. The elected leader also echoes any updates (logs) to all non-leader validators (secondaries) serving that Zone. When acting as a secondary, a node maintains an open connection with the leader and receives and commits any logs to be prepared to run in the next election. The secondary also acts as a witness to watch the updates and can challenge the leader if a false update is detected. Writers choose random secondaries to witness commits, thereby ensuring no leader can falsify commits undetected. Elections are held with weighting differences and algorithms plus scoring designed to reward high-performance nodes (validator nodes, and others) without excluding others or newcomers, for one frame (period of time, such as 5 seconds) at a time. Only secondaries that are up to current on the partition’s log are eligible for election to leader. When a node needs to catch up on such logs, come online, or join a secondary, it submits a request to the leader for a full dump of logs from its last checkpoint. ### **7.5 Extensibility of Validation Infrastructure** The validator infrastructure operating on IronWeave is extensible. With the design of IronWeave and its shared-block infrastructure, and the architectural design of the validator infrastructure running on IronWeave, validation of data is possible for any type of data for which there is a deterministic (or deemed-authoritative source) validation mechanism. For example, there could be an IronWeave Region dedicated to unique and singular personhood, and by extension, unique verifiable identification. In that Region, validators could be developed that can check for identity against a deterministic collection of authoritative trusted sources, validated on-chain based on any combination of acceptable proofs (biometric, hash-chain proofs based on person activities, so on), then used as secure proof of provenance of identity (and personhood). This project (solution, service, offering) is not currently on the IronWeave roadmap; it’s provided here as a specific example of what the extensible validator infrastructure operating on IronWeave could provide, when combined with the expandable collection of IronWeave assignable regions. ## **8. Nodes and Incentive** ISE are allocated on a deterministic basis to provide incentive. There are different types of nodes in IronWeave: Validator nodes, Storage nodes, Compute nodes, with the capacity to bring on other nodes as future services and uses require. Each node receives a portion of allocated ISE tokens, based on proportionate contribution to the service and growth of the IronWeave fabric. Validator nodes oversee block creation and chain management and ensure ongoing operation of the IronWeave fabric. Nodes are incentivized with ISE tokens awards, based on performance, traffic, up-time, latency, and other factors that contribute to a robust and increasingly decentralized collection of nodes. The IronWeave Foundation (or an "IronWeave Labs" entity) will maintain a durable collection of online nodes to ensure ongoing performance and operation of the fabric; such nodes will be de-emphasized for node traffic as other capable, dependable, and performant nodes are deployed into a given Zone (or Region). This approach, called curated decentralization, ensures dependable operation of the fabric and sets a floor of performance and reliability for other nodes to match, outperform, and out-earn. Validators perform validation of data, including ISE token exchange and other value transfers. The validator framework is extensible, and additional validator pools can be created for whatever type of data must be independently validated. Token awards for validators are in addition to transaction fees, which are set by validators to bid on a validator slot and for a validator be elected for a given frame during which transaction fees are collection, each of which factor into whether a slot is granted or renewed, and whether election as a leader for an upcoming frame is won. Competitiveness of transaction fees and robust performance are primary considerations for validator slot or frame leader slot is awarded or renewed. The process of curated decentralization will also apply to validators, to ensure high availability, performance, low latency, and fee competitiveness among validators. Validator slots are awarded by competitive performance and fee bid algorithms, based on performance/load needs of a given Zone. Storage nodes store IronWeave blocks and are incentivized with ISE tokens based on the share of total IronWeave storage provided by the Storage node. Awards and active node status are weighted, in part, on lowest fee for storage to ensure competitive, delivery- and value-based provisioning of reliable, responsive, low-latency storage and ongoing proof of storage. Anyone running an active Storage node in IronWeave can receive ISE tokens. Compute nodes, including but not limited to the servicing of IronContracts, are incentivized with ISE tokens based on volume and efficient use of compute and power resources. Awards and active node status are weighted based on competitive, reliable, honest, low-latency compute and Iron Contract execution. All nodes in IronWeave must provide staking to ensure proper alignment (and consequences) for the IronWeave Foundation mission to expand and grow the reach and utility of the IronWeave fabric. Incentives for each node type are designed to ensure that providing each node service is more compelling than potential return on bad-actor activities. ### **8.1 Curated Decentralization** The concept and practice behind *curated decentralization* is designed to provide for the bootstrapping and operational continuity of robust, distributed and performant nodes for the IronWeave fabric, while encouraging and furthering the decentralization of the fabric with incentives, opportunities, and individual creativity and effort. In curated decentralization, IronWeave provides and deploys nodes of each type into the fabric – Validator nodes, Storage nodes and Compute nodes. These nodes create a robust and distributed baseline for performance and reasonable fees as well as reliability for the overall IronWeave fabric. This ensures ongoing operation of the fabric, including regional and cloud / bare-metal node diversity. Incentives for node operation (of any type) is based on various factors, including performance and uptime characteristics of each node, as well as fees to users, with activity and traffic within the IronWeave fabric being directed to the nodes that perform the best, for the lowest fees, with algorithmic safeguards in place to encourage new nodes to come online and provide services. This approach (algorithmic safeguards to encourage new nodes) ensures competition of fees and performance among nodes, creating a healthy opportunity environment for those who want to participate, without tilting toward capitalistic aggregation of services, which happens when a flooding of private resources overtake the good intentions of would-be decentralization. Example: more than 51% of Bitcoin blocks are mined by only two large Bitcoin mining pools\[3], increasing to 73% of all blocks being mined by only four Bitcoin mining pools\[4].  With curated decentralization, IronWeave-provided nodes provide an operational baseline with robust performance and responsiveness, while decentralized node operators come online to participate in operation and earn IronWeave token incentives provided for such operation. Performance of decentralized nodes must engage in healthy performance competition with others, and with the IronWeave baseline nodes, to earn a share of traffic and activity (and thus, token incentives and rewards). Also with curated decentralization, no single cloud provider can disrupt operations (like what happened with Solana); fees cannot skyrocket with collusion among decentralized node providers (too-high fees would send traffic back to IronWeave nodes based on leader elections that also consider fees, which are retrospectively enforced with staking). The curation of globally decentralized, robust and performant nodes will result in IronWeave nodes waiting on the sidelines in case they’re needed, much like a relief pitcher ready to come in at a moment’s notice, if called. ## **9. Evolved Wallets** In IronWeave it is not necessary to run a node to have a chain, a collection of chains, or to program to or interact with the fabric. IronWeave is designed to be consumer-friendly and user-friendly, available for participation by anyone or any organization, without the overhead or technical requirements of running a node. Any individual, institution or organization can create or participate in interactions, whether ISE token exchange is involved or not, by creating a chain and paying the necessary fees for transactions, interactions, storage or compute. An IronWeave wallet, or IronWallet, takes advantage of the inherent security and privacy of IronWeave as well as the programmable capabilities available based on IronWeave’s event-driven architecture, which means you can set up internal (to the IronWeave fabric) or external (such as data outside IronWeave) events to drive interactions on any given chain you control. Such interactions could be basic (when ISE balance exceeds 100, move excess funds to chain B), or more sophisticated operations (when fund transfer exceeds 1,000 ISE, implement biometric approval and require two human approvers from assigned list). Such potential functionality is not constrained to financial transactions or traditional blockchain interactions. IronWeave is agnostic to the data stored or shared blocks, so the IronWeave wallet can become a focused view into any (or all) online interactions – anything involving data – thus providing a focused and validated view into the chain(s) owners fabric interactions. With the capacity for blocks to be categorized, indexed, and structured in many other ways, the use of an IronWeave wallet is as extensible to any sort of online data or online interaction that can be conceived, facilitated, or exchanged on the IronWeave fabric. Further, it can be organized, private, authenticated, and selectively shared. Such functionality, in a wallet that is inherently privacy preserving, can be programmed and operate similar to a smart contract. It also inherits the advantage of IronWeave’s horizontal scalability, effectively bringing about and implementing the three transitions\[5]. ## **10. Conserving Disk Space** In monolithic blockchains, each full node must store the blockchain in its entirety. IronWeave has no such requirement. What is required in IronWeave is a statistical assurance that any given shared block is replicated on a sufficient number of nodes, whether large nodes or small, to ensure reconstitution of any block should the need arise. The number of nodes on which any given shared block is present is based on many factors, including geographical diversity (observing any constraints on the expanse of said diversity, such as GDPR or data sovereignty), logical nearness to common access, frequency of access, cost of storage or compute and other factors. Some storage or compute nodes may be relatively small, others may fill warehouses with efficient resources, each of which implies different incentives. The IronWeave core system maintains multiple maps and graphs of each block’s logical location, allowing for maintenance, statistical availability guarantees, moving of blocks from one node to another for various reasons, and system integrity. One reason for running a node, exclusive of ISE incentives for doing so, might be low-latency access, such as an enterprise institution running a node for its Zone or its Region that is logically near its datacenter location, ensuring at least one copy of its blocks reside in that node for various reasons. Such solutions are possible with IronWeave’s shared-block architecture, whether the underlying reason is conservation of disk space, rapid access to nearby stores, organizational requirements or policy, or others. ## **11. Calculations** IronWeave is not limited to a single monolithic chain, a constraint that plagues other blockchains. In IronWeave there is no central chain to which all transactions or interactions must reconcile. Instead, each individual chain in IronWeave operates independently, and state is only synchronized between two (or more) chains when a shared block is created (and validated, if necessary such as for value transfer) and placed on each participant’s chain. This shared-block architecture inherently enables horizontal scalability. Each Zone in IronWeave operates as an independent consensus boundary. As such, each Zone is capable of reaching the performance metrics of its underlying consensus mechanism, making the collection of Zones an additive overall throughput environment, indicative of being a fabric, rather than a monolithic chain. With each zone operating a separate instance of its underlying dBFT consensus mechanism (yet as a fabric, maintaining the ability to interact across Zones as a holistic environment), the scalability of the fabric becomes equivalent to the overall capacity of its (expandable) collection of Zones. There are a few BFT consensus mechanisms that have been battle-tested in production chains, including those from the NEO blockchain\[6] and the Mysticeti DAG-based BFT protocol\[7]. With the NEO dBFT consensus protocol a benchmark performed by them reached approximately 16,000 Transactions Per Second (TPS), and with the Mysticeti protocol a benchmark reached approximately 300,000 TPS. In IronWeave, these are benchmarks that can be achieved in each IronWeave Zone. With an initially considered reservation of 12 bits of an IronWeave Chain ID to represent the Zone, the initial throughput metrics for IronWeave would be the following (a monolithic chain, with the equivalent of one Zone, is included as the first row as a comparison to monolithic chains): | Number of Zones | Total Transaction Throughput (NEO dBFT Consensus) | Total Transaction Throughput (Mysticeti DAG-based BFT) | | -------------------- | ------------------------------------------------- | ------------------------------------------------------ | | 1 (monolithic chain) | 16,000 TPS | 300,000 TPS | | 4,096 | 65,536,000 TPS | 1,228,800,000 TPS | If we account for processing overhead associated with the common occasions when IronWeave interactions occur among chains in different Zones, we can adjust downward the throughput of the IronWeave fabric by 20%. From a compute and performance throughput perspective, an overhead of 20% for such instances is very high, and more likely that performance overhead would be in the single-digit percentage range. To be conservative, we will consider 20% overhead, resulting in the following: | Number of Zones | NEO dBFT Consensus with 20% cross-Zone overhead. | Mysticeti DAG-based BFT with 20% cross-Zone overhead | | -------------------- | ------------------------------------------------ | ---------------------------------------------------- | | 1 (monolithic chain) | 12,800 | 240,000 | | 4,096 | 52,428,800 | 983,040,000 | If we further consider that the future capacity for IronWeave Zones using 16 bits of the Chain ID, we can calculate Zones available increasing to 65,536. The following table shows the horizontal scalability available to IronWeave when using 16 bits for Zone identification, and with 20% overhead for cross-zone interactions. | Number of Zones | NEO dBFT Consensus with 20% cross-Zone overhead. | Mysticeti DAG-based BFT with 20% cross-Zone overhead | | -------------------- | ------------------------------------------------ | ---------------------------------------------------- | | 1 (monolithic chain) | 12,800 | 240,000 | | 65,536 | 838,860,800 | 15,728,640,000 | While it may be difficult to conceive of a blockchain fabric requiring over 800 million interactions per second, it’s worth noting that the initial production version of the Internet Protocol (IPv4) has the capacity of 4,294,967,296 (over four billion) IP addresses. Early in the days of the Internet, that amount of IP addresses was expected to be more than the world would ever need. We know better now. So the idea of needing over 15 billion interactions per second (for IronWeave) may also seem inconceivable, we are in the early days of the Artificial Intelligence Age and must plan for expansion and extended functionality accordingly. Also note that some blocks will be larger than others, potentially impacting throughput. So these estimates are necessarily based on existing transaction sizes in respective dBFT benchmarks. We have built flexibility into our IronWeave architecture (no set block size, for example) so such benchmarks are means of measure, not final capacities. In addition, research will continue on expanding the performance and throughput of BFT consensus protocols and mechanisms, so these are benchmarks only for today. In addition, more bits are reserved in the Chain ID for future expansion of Zone ID, in case such expansion is necessary. Worth noting again is that these are TPS benchmarks (Transactions Per Second, or as we prefer to consider them, Interactions Per Second). There is no inherent limit to the number of interacting chains that can exist in the IronWeave fabric. ## **12. Conclusion** We have proposed a blockchain data fabric and integrated currency system, based on novel shared-block architecture, that can secure interactions in a private manner and scale to meet global demand with no inherent limits. With unlimited independent blockchains in the fabric, and a block created upon interaction of two or more chains, many otherwise unconsidered blockchain capabilities and services become possible. One such capability is placing the burden of preventing double-spend on the spender, rather than a performance-constrained single entity. Validation becomes a safeguard of the system, rather than the arbiter of value exchange. To engage participants, incentives are issued for those who provide fabric management, validation, storage and compute and thus reward a thriving and growing environment, with incentives biased toward performance, cost efficiency for users, and continued decentralization of all such nodes. Other capabilities, such as the following, may not be immediately apparent but are equally compelling. To protect participants, each block is encrypted with unique keys, making data only available to its participants; to modernize systems, custom blocks or categories of any use can be defined and created, publicly or privately, to facilitate secure data exchange and immutable interactions. This architecture enables each chain to have a unique, secure, it- or they-focused digital perspective (point-of-view) of its online interactions and experience. Rather than a single monolithic channel into which all voices must shout, the IronWeave fabric is an infinite collection of private and individual voices communicating with those with whom they want to engage, an engagement which is theirs alone to control and maintain and own. Further, in contrast to global squandering of duplicative effort to achieve a single, monolithic view that will always have inherent limits on scale, flexibility, security, and privacy, IronWeave conserves resources in its multi-dimensional environment by implementing unlimited parallel distribution of blockchain interactions. Each core facility of the fabric – validation, block creation, storage and compute – is provided incentives necessary for veracity, continuity, decentralization and sustainable fee structures. The result is a flexible digital ecosystem of unlimited scale, delivering global and intrinsically local blockchain advances, in a holistic, secure, privacy-enabled blockchain environment that combines its modern data fabric with a robust and responsive, interoperable data and digital currency system. ## **References** \[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. \[Online].