Ethereum, Base, and more"] JS["Job submitters
post problems with rewards"] OP["Operators
mine solutions on quantum
and classical hardware"] subgraph QN["Quip Network"] A["Quip Account
holds your assets"] S["QuipSwap
settles atomic trades"] subgraph SUB["Subnets"] OPT["Optimization
Subnet 1, solves jobs"] RND["Randomness
Subnet 2, serves QVRF"] end end SC --> A A -->|authorizes| S S ==>|pays for work| SUB SUB -->|returns the result| S JS -->|submit jobs| SUB OP -->|mine solutions| SUB style SUB fill:#FFFFFF,stroke:#8B8083 classDef quip fill:#FFEDEE,stroke:#C93A3F,color:#1A1618 class A,S quip ``` The account and swap contracts are deployed onto the supported chains themselves, so your assets never leave the chain they live on. QuipSwap's trades are sealed by the QUIP interlock, the shared-secret construction the protocol is named for; [QUIP: The Quantum Unit Interlock Pathway](/docs/quip-interlock-protocol/quip-the-quantum-unit-interlock-pathway) explains it. Unlike most Web3 platforms, Quip's atomic swaps require no bridge. The swap carries the value between chains, so there is no bridge for anyone to attack and no third-party bridge contract for Quip to depend on. ## Who pays whom The network is a stack of participants, and every payment between layers settles the same way. ```mermaid flowchart LR CC["Compute
Consumers"] -->|USD| AD["Application
Developers"] AD -->|"$QUIP"| ALG["Algorithm
Developers"] ALG -->|"$QUIP"| PD["Protocol
Developers"] PD -->|"$QUIP"| CP["Compute Providers
QPU, GPU, CPU"] LP["Liquidity
Providers"] <-->|"USD to $QUIP,
via QuipSwap"| AD ``` Every $QUIP hop is a payment for work one layer down, and cross-chain payments settle over the QuipSwap protocol. ## Where to go next | If you want to | Read | | --- | --- | | Hold assets under post-quantum protection | [Quip Accounts](/docs/quip-interlock-protocol/quip-accounts) | | Trade without bridges | [QuipSwap](/docs/quip-interlock-protocol/quipswap) | | Buy quantum randomness | [Quantum Randomness (QVRF)](/docs/compute/qvrf) | | Submit an optimization job | [Submit Your First Compute Job](/docs/compute/submit-a-job) | | Run hardware and earn | [Run A Node](/docs/nodes/run-a-node-testnet) | --- # QUIP: The Quantum Unit Interlock Pathway The Quantum Unit Interlock Pathway (“QUIP”) is the basic primitive building block of the Quip Network. Each QUIP is a secure lockbox or vault which protects user funds with a post-quantum signature. The algorithms generating the signature have no known vulnerabilities to quantum computing attackers. Beyond its role in safeguarding assets, the QUIP plays a crucial part in maintaining the integrity and functionality of the Quip Protocol. QUIPs start with a user deposit on any blockchain into a QUIP-enabled smart contract. This action creates a QUIP transaction input, which can be used across the entire Quip Network. This deposit pairs the user’s classical wallet with information that can be used to uniquely generate a compatible post-quantum wallet. In its simplest form, the user can withdraw their funds from a QUIP by signing a transaction with their post-quantum wallet and sending the post-quantum signature to a QUIP-enabled smart contract with their classical wallet. This action could be easily integrated into existing wallets using an extension, such that the post-quantum wallet is hidden within the normal operations of the user’s everyday wallet. The user can also split funds in a QUIP by sending a signed split transaction to the contract, such that some balance is sent to a receiver, and the remaining assets are then shifted to a new QUIP address owned by the sender. QUIPs provide the ultimate protection for anyone worried about quantum computers. While funds are inside the QUIP they are safe even in the advent of a quantum zero day attack. An enterprising quantum attacker will be unable to provide the necessary post-quantum signature, which means they cannot provide a valid classical hash to the host transaction network, and thus they cannot create a valid QUIP transaction to remove the funds from the wallet. This guarantee holds true even if they can break the host transaction network’s consensus or steal funds from classical unprotected wallets. ## Properties The QUIP is a versatile building block: 1. Every transaction enforces ACID (Atomicity, Consistency, Isolation, and Durability) principles. They either complete or they do not. 2. The protocol supports staking, swaps, flash loans, mixnets, zero-knowledge proofs, dark pools, voting, delegation, and any other process dreamable with boolean logic. 3. Each deposit requires no custody or lockup on any one transaction network. 4. Transaction resolution is independent and secure without need for any additional consensus mechanism or validator set. 5. Exchange of funds requires no oracles or cross-chain messaging. 6. Post-quantum guarantees are agnostic to the network consensus model and cryptographic architecture. 7. Clients need only rely on the chains to validate transactions: no state comparisons, intermediate networks, or zero knowledge proofs are necessary to perform the needed validations, beyond those required by the host network consensus model. The states a QUIP moves through are described in [QUIP Lifecycle](/docs/quip-interlock-protocol/quip-lifecycle), and the contract that holds the funds is described in [Quip Accounts](/docs/quip-interlock-protocol/quip-accounts). --- # Quip Accounts A Quip Account is where your assets live under post-quantum protection. This page explains what the account is, how you reach it, how its signatures work, and the one signature behavior every integrator needs to understand before relying on it. ## A lockbox on the chain you already use A Quip Account is a smart contract deployed on the blockchain you already use. It works like a lockbox: your assets sit inside the contract, and the contract releases them only when it is shown a valid signature from a quantum-resistant key. The signature scheme is hash-based, which means its security rests on the strength of a hash function rather than on the mathematical problems that a quantum computer could one day solve. Nothing about your assets moves to a new network. You keep using the chain, the tokens, and the tooling you already have. Your existing wallet still has a job: it submits transactions to the network and pays the fees. The quantum-resistant signature is what authorizes the movement of assets. A factory contract creates each account, and the account's address is derived deterministically from its creation inputs rather than assigned at random. ## One account, two doors Quip Network provides two clients for the same account: a browser extension and the web application at [account.quip.network](https://account.quip.network/). They are two doors into one account, not two wallets. The account itself is the contract on chain. Both clients read the same balances and history and produce signatures for the same account, so nothing you create through one client is trapped in the other. If your application points users at Quip, route Chrome users to the extension and everyone else to the web app. The web app requires no installation and runs in any modern browser. The extension wraps the same account surface and adds the click-the-icon flow and the decentralised application (dApp) connection surface that Chrome users expect from a wallet. ## How signing works Quip Accounts sign with hash-based one-time signatures, packaged in a construction called SHRINCS. A hash-based one-time key can safely sign exactly one message, so SHRINCS commits to a large collection of one-time keys under a single compact public commitment and gives the account two ways to use them: * **The everyday path.** Cheap to verify and used for normal operations. Each signature consumes one slot from a fixed budget that is set when the key bundle is created. Once a slot has been used, it is gone: signing again requires the next unused slot. * **The break-glass path.** A more expensive signature reserved for recovery and for rotating to a fresh key bundle. It does not depend on any record of which slots have been used, which is exactly what you want when that record has been lost. ```mermaid graph TD C["One public key commitment
(the account's quantum-resistant identity)"] C --> A["Everyday path
cheap signatures,
one slot consumed per signature"] C --> B["Break-glass path
expensive recovery signatures,
no slot records needed"] A --> V["Account verifies the signature
and executes the operation"] B --> V ``` The chain verifies signatures; it does not manage your signing state. Which slots have been consumed is state that belongs to the signer, and the Quip clients track it for you. ## If you build your own signer, track your slots This is the one discipline that makes Quip Accounts different from a classical wallet integration. A classical key can sign any number of times. A slot in a Quip Account key bundle must sign at most once. If you integrate at the level of the signing libraries rather than through the Quip clients, you own that state: * Record which slots have been consumed, and update the record before you broadcast, not after. * Never sign two different messages with the same slot. Reusing a slot weakens the one-time scheme it belongs to. * Treat the slot budget as a finite resource and plan for rotation to a fresh key bundle well before the budget runs out. The specific size of the slot budget is an implementation parameter and is not documented here. Design your integration to read the budget from the account rather than assume it. ## Signature checks by other contracts are not one-time Third-party contracts, such as exchanges with off-chain order books or permit-style token approvals, can ask a Quip Account whether it authorized a message through the standard contract-signature interface, ERC-1271 (Ethereum Request for Comments 1271). > **Warning** > **ERC-1271 checks are view-only and do not consume a slot.** A signature verified through `isValidSignature` remains valid for as long as the key it was made with stays installed on the account. The one-time-use guarantee that applies to every other signature path does **not** apply here. This is a deliberate design choice, not an oversight. The consequence for integrators: if your protocol assumes a signature can only be used once, you must enforce that yourself. Common approaches are tracking nonces in your own contract, binding signatures to an expiry, or treating the account's verification key as something to be replaced once its signature has served its purpose. Do not assume replay protection on the ERC-1271 surface, because the account does not provide it there. ## Upgrades are yours to accept Account logic will improve over time, and the upgrade model is designed around user consent: * **Opt-in only.** You are prompted when a new account version is available, and nothing changes until you explicitly approve the upgrade. Quip never upgrades your account for you. * **Your address is preserved.** An upgrade replaces the account's executable logic while the address, balance, and state stay where they are. Funds do not move, and integrations that reference your address keep working. ## Standards lineage Quip Accounts are built on public, citable standards rather than proprietary cryptography. | Standard | What it is | Role in Quip Accounts | | --- | --- | --- | | [RFC 8391](https://datatracker.ietf.org/doc/html/rfc8391) | XMSS: eXtended Merkle Signature Scheme (RFC is Request for Comments) | Baseline for the stateful Merkle-tree component behind the everyday signing path | | [FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | SHA-3 Standard (FIPS is Federal Information Processing Standards) | Defines the Keccak hash family used throughout the signature scheme | | [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final) | Stateless Hash-Based Digital Signature Standard | Conventions and cross-checks for the break-glass recovery path | | [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271) | Standard Signature Validation Method for Contracts | The contract-signature interface described in the warning above | | [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) | Account Abstraction Using Alt Mempool | The smart-account execution model the account contracts follow | | [ERC-7913](https://eips.ethereum.org/EIPS/eip-7913) | Signature Verifiers | The interface exposed by the on-chain signature verifier contracts | A Quip Account is one of four pieces that make up the network. [How Quip Network Fits Together](/docs/quip-interlock-protocol/how-quip-fits-together) shows how it connects to [QuipSwap](/docs/quip-interlock-protocol/quipswap) and the compute network. --- # QuipSwap QuipSwap is Quip Network's protocol for trading assets directly with another party. You agree on the terms of a trade, then each of you locks the assets you are giving up in a shared settlement contract on your own chain. A single secret connects the two locks. When one side reveals the secret to claim their new assets, that same reveal lets the other side claim theirs. If the trade stalls, each side takes back what they locked once a deadline passes. The trade can run across two chains or entirely on one chain, and at no point does a bridge, an exchange, or any other custodian hold your money. ## Quantum protection comes first QuipSwap's design leads with what protects the assets. The bridgeless design is a benefit, but a secondary one. The assets in a swap are held and moved by Quip accounts, the quantum-resistant wallet layer described in [Quip Accounts](/docs/quip-interlock-protocol/quip-accounts). Every authorization above the settlement layer is protected there by post-quantum signatures. The settlement contract itself deliberately uses a simpler tool: a hash lock, a lock that opens only for whoever knows a chosen secret. Hash locks rest on hash functions, and hash functions are not weakened by the known quantum attacks that break ordinary wallet keys. The result is a trade in which no step depends on the kind of mathematics a quantum computer can break: quantum-resistant authentication in the wallet layer above, hash-based locks in the contract below. The contract accepts the asset kinds you would expect on a smart contract chain: the chain's native coin, fungible tokens, and non-fungible tokens (NFTs), in any combination on either side of the trade. ## The swap lifecycle: commit, execute, reclaim A swap moves through three actions. **Commit.** Each party locks the assets they are offering into the settlement contract on their own chain. The contract records the agreed terms of the trade and the hash of the shared secret, and holds the assets in escrow. Both parties can independently check that the two commitments describe the same trade. **Execute.** One party reveals the secret to claim the assets committed to them. Revealing the secret is what unblocks the other side: the secret becomes publicly visible on that chain, so the counterparty can read it and use it to execute on their own chain. **Reclaim.** If the deadline on a commitment passes without execution, the party who committed takes their own assets back. Every committed side of a swap ends in exactly one of two terminal states: it is executed before its deadline, or it is reclaimed after. There is no outcome in which the contract keeps your assets. Taken together, the two sides give the trade its central guarantee: either both legs complete and each party receives the other's assets, or neither completes and each party recovers their own. There is no state in which one side has claimed and the other has permanently lost funds. ## Timeout windows protect each side The two commitments do not share one deadline. The initiator, the party who will reveal the secret first, takes the longer window. The counterparty takes the shorter one. The gap is what keeps the trade fair: if the initiator reveals late, the counterparty still has time to read the secret and claim before their own window closes. The initiator's window must exceed the counterparty's by a safety margin that covers cross-chain observation delays, block confirmation times, and transaction inclusion delays. If the margin is too small, a race can open in which one party reclaims while the other has already revealed the secret. > **Note** > The contract enforces each deadline individually, but it cannot see the other chain, so it cannot check the gap between the two windows. If you integrate QuipSwap, that margin is a safety parameter you own. Choose it deliberately for the pair of chains you are trading across, and reject schedules that are formally valid but operationally unsafe. ## Finding a counterparty: makers and takers The settlement protocol assumes you and your counterparty have already found each other and agreed on terms. The marketplace layer on top of it is how that happens when you do not have a counterparty in mind. A **maker** posts an order: a statement of intent to swap that says what they are offering and what they want in return. A **taker** browses the open orders and takes one. Both parties then commit on-chain, and settlement proceeds through the same commit, execute, and reclaim flow described above. The order book is a convenience layer that runs off-chain; it helps people find each other, and the protocol does not care how the negotiation happened as long as both parties agree on the terms. A maker order works like a request for quote (RFQ) run in reverse: instead of asking counterparties to quote a price, the maker publishes the full terms and waits for someone to accept them. If the maker leaves the amount of the counter asset open, the order becomes a classic request for quote, and takers respond with the price they are willing to give. ## Who can start a swap today The settlement contract is gated: only Quip wallet contracts can initiate a swap. You cannot drive a swap from an ordinary account or from your own contract today. The gate is deliberate. The guided wallet flow is part of the protocol's safety boundary, not a convenience: the wallet can observe both chains, bind you to the intended swap instance, and reject unsafe timing that the contract alone cannot check. Opening the contract to arbitrary callers would expose users to workflow-bypass, phishing, and timing-misuse risks that the wallet flow exists to reduce, so the team treats removing the gate as a future protocol-hardening decision, not a configuration switch. ## What QuipSwap does not do QuipSwap is a settlement primitive, and it keeps its scope narrow on purpose. * **No trade discovery, matching, or broadcast in the protocol.** The contract does not find counterparties, match orders, or announce open trades. Those jobs belong to layers built on top, such as the marketplace described above, or to whatever channel you and your counterparty prefer. * **No slashing.** The protocol does not penalize a party who commits and then walks away. The honest party waits out the deadline and reclaims, losing time but not assets. Penalizing bad behavior requires a non-spoofable proof of commitment, which is an open problem, so any deterrence beyond reclaim is left to integrators. ## Why QuipSwap exists Quip's network sells quantum computing work. QuipSwap is the payment rail that makes that work purchasable: it lets you exchange value from the chain you are already on, without migrating your assets to a new chain first. A swap is how assets on any supported chain become buying power on the Quip network, which is why Quip built the swap protocol rather than wait for a third party to provide one. The propose, approve, and claim state machine underneath these steps is set out in [QUIP Lifecycle](/docs/quip-interlock-protocol/quip-lifecycle). --- # QUIP Lifecycle A user creates a QUIP when they deposit funds to a QUIP-enabled smart contract or QUIP-enabled wallet. At any time, the user can transfer the QUIP to another owner using a regular cryptocurrency transaction. The QUIP also has three additional states that enable programmability:
The QUIP Lifecycle
The layers of the Quip Network Protocol
The different participants in the compute protocol
network"] TN -->|stores and
processes QUIPs| C TN -->|splits fees| V["Quip Network
validators"] V -->|publishes QUIP
commitments| TN V -->|pays yield| N["Nominators"] N -->|stake funds| V N -->|pays bounties| W["Whitehat
hackers"] W -->|proves algorithm
security| N ``` | Payor | Payee | Service | | ----------------------- | ----------------------- | ----------------------------- | | Client | Transaction Network | Store & Process QUIPs | | Transaction Network | Quip Network Validators | PubSub QUIP Commitments | | Quip Network Validators | Nominators | Endorses via Staked Assets | | Nominators | Whitehat Hackers | Proves Security of Algorithms | ### Clients Clients come in many shapes and sizes, from retail to institutional, as lenders, traders, insurers, and end-users of the underlying protocol. To take advantage of a QUIP, they pay fees for the necessary computation and storage on the underlying transaction network and the QUIP extension will determine any additional fee retained by the protocol. Wallet providers and treasury management solutions may wish to integrate QUIPs as a secure add-on for their clients, in order to streamline the process of forming and executing more complex QUIP exchanges. Institutions may wish to employ QUIPs as a second layer of security on their cold storage funds, or else integrate QUIPs directly into low volume hot wallet transactions that touch more sensitive and valuable assets. Even transaction networks with highly sensitive contracts, such as Ethereum’s validator staking contract that holds more than 45% of all ETH, may wish to integrate a QUIP directly into the contract so that stakers can rest secure in the knowledge their funds are safe. ### Transaction Networks Transaction networks don’t have to explicitly form partnerships with the Quip Network, as any deployer can post a QUIP-enabled smart contract or cryptographic primitive to any sufficiently sophisticated network. However, protocols and traditional payment rails may wish to subscribe to the Quip Network’s validators and create a plan for restoring a canonical chain state in the event of a significant reorganization by a quantum attacker. If the Quip Validators are unable to show that certain accepted post-quantum signatures are still included in the heaviest block or tip of any network, it is a signal that the network may have been compromised by a quantum attacker. Such an eventuality can be planned for, and the miners or validators can adopt a set of criteria for rejecting chain states that do not include recent QUIP commitments. ### Validators In addition to the developers and the foundation, the Quip Network will employ Nominated Proof of Stake Validators to maintain and upgrade services for any transaction network that has not yet implemented post-quantum security, and to provide automation to individual depositors and clients who do not wish to directly manage the Quip Protocol on a peer-to-peer basis. Alongside the miners who solve Proofs of Useful Work and broadcast winning blocks, validators are one of the three consensus roles — validators, miners, and nominators — that receive the $QUIP token for running the chain. A validator is a full node. These infrastructure providers maintain indices of all proposed quips and process messages and transactions between willing counter-parties in return for $QUIP. They can aggregate together multiparty quip transaction signatures and batch the processing for cost savings, provide mixnet or privacy-preserving functionality, and execute other post-quantum multi-party computation services. In return for locking up funds on target networks to facilitate liquidity and collateral, these node providers receive yield in the form of network fees on the indexed networks, as well as $QUIP emissions. Validators also track the current state of each host transaction network to ensure that no quip has been orphaned by a block reorganization or other malicious attack on consensus. These records can be used by host networks as a canonical checkpoint in case of a rewind attack by a quantum attacker — the commitment-omission defense — and can improve the security of the underlying transaction network. Storing and attesting the presence of quips on host networks earns attestation fees on top of emissions. For enterprising node providers with insufficient funds to meet the minimum bond required of a trusted validator, they can accept stakes from nominators and share yield from validation. ### Nominators Nominators can supply funds to validators with insufficient capital to meet the minimum stake, and can restake the coupon and yield tokens as collateral for further Quip Network activity. An added bonus of the validator and nominator staking structure is that node providers can choose the post-quantum algorithms that they trust most to protect their own funds, and nominators can choose the validators using the post-quantum algorithms they trust most. This stakers’ collective choice of post-quantum algorithm will provide an implicit betting market on the safety, storage, and throughput tradeoffs of each paradigm, which can incentivize quantum attackers to prove that any given post-quantum algorithm is flawed. The protocol will provide a built-in bug bounty mechanism, where a quantum attacker can reveal the private information necessary to slash validator and nominator stakes to keep a percentage of the compromised funds. Some percentage of this stake will also be used to stake a bug bounty showing that ECC256 has been broken, and that quantum supremacy has arrived. ### Whitehats Arguably one of the most important participants in the network, these enterprising cryptographers and computer scientists can earn automated bug bounties for showing that existing cryptography is now insecure to contemporary methods. By using vulnerabilities in classical and post-quantum algorithms to reveal private keys, they can slash the stake of all the existing validators and nominators and prove that a given algorithm is no longer secure. This activity creates a more resilient ecosystem of decentralized services, and will increase demand for the security guarantees provided by the Quip Network and the remaining secure algorithms. The more any one algorithm is preferred by the validators, the larger incentive remains for a white hat to claim their pro rata share of the stake. The $QUIP token these participants earn and spend is described in [Token](/docs/network/token), and the properties the network has to hold to for them is set out in [Key Properties](/docs/basics/key-properties). --- # Token The $QUIP token is a shared compute credit across all the operators in the decentralized compute protocol. In addition to being used to reserve spot capacity on quantum and classical hardware, it is an integral component to the functioning of the protocol. ## Token Purpose & Value Accrual The $QUIP token serves as the incentive layer that ensures Quip Network remains secure, performant, and decentralized: * Reward miners for proving availability on the network * Punish bad actors for breaking shared programs * Simplify consumer experience with a shared compute credit * Facilitate quantum-resistant transactions across chains ## Buy & LP Mechanism $QUIP implements a value accrual mechanism: 1. Users pay transaction and network fees in $QUIP 2. A portion of these fees buys $QUIP back off the market and pairs it into permanent 50/50 liquidity pools — nothing is ever burned 3. Smart contract deployers earn tokens of their choice for each execution 4. Node operators earn $QUIP for providing services 5. The protocol earns AMM transaction fees when consumers buy or sell $QUIP As the network grows and demand for quantum compute increases: * More demand requires more computation * More computation requires more $QUIP to buy space in the next block * All these revenues are used to buy and LP $QUIP * Increasing demand + decreasing float + deeper liquidity = upward price pressure and lower price volatility More quantum demand = more $QUIP buy pressure = more $QUIP liquidity This creates a $QUIP-native economy where the protocol continuously earns a larger portion of transaction volume denominated in $QUIP. The more activity on Quip Network, the more $QUIP flows into buying and locking active trading pairs in captive liquidity pools, creating price stability and token scarcity. ## Tokenomics Overview * Ticker: $QUIP * Initial allocation: 1 billion QUIP will have been emitted when all pre-mine allocations finish vesting, split 40% subnet emissions / 20% Quip Foundation / 15% early investors / 15% builders / 10% community programs * Emission: 40 million QUIP per year, fixed and flat — emissions continue at this rate after the first billion has vested, so the first billion is not a maximum supply * Implicit decay: each new subnet competes for a share of the same 40M annual emission, so issuance per subnet falls as the network grows — no halvings, no burns * Token Standard: PSP-3 on Substrate, ERC-20 on Ethereum, SPL on Solana ## Governance Emissions are routed by the Quip Control Asset (QCA). In its canonical implementation, veQUIP, holders lock QUIP in an Interlock-enforced escrow to gain control weight that grows with lock duration, then vote each epoch to divide the fixed emission among subnets. The escrowed position remains liquid — it can be lent, borrowed, or posted as collateral while it votes. The Control Asset binds to a zero-knowledge identity credential so the protocol can apply per-identity limits, such as quadratic decay in marginal control weight, that a token-only system cannot enforce against an actor splitting a balance across wallets. Subnet backers can also pay veQUIP voters through an explicit, permissionless incentive market, turning emission routing into a transparent auction that prices demand for each problem class. For who earns and spends $QUIP, see [Participants](/docs/network/participants). To buy compute with it, see [Submit Your First Compute Job](/docs/compute/submit-a-job). --- # Run A Node (TestNet) You can run a quip testnet node using the node manager application: [https://gitlab.com/quip.network/quip-node-manager/-/releases](https://gitlab.com/quip.network/quip-node-manager/-/releases) The primary user interface is a graphical user interface which will walk you through and test your environment to ensure you can connect to the network. This tool also has a command line only terminal UI as well with the same functionality. ## Running on a Server If you're a little more tech savvy, can verify your own connectivity, and want to run this on a server, you can trivially deploy on servers using a docker-compose deployment repository: [https://gitlab.com/quip.network/nodes.quip.network](https://gitlab.com/quip.network/nodes.quip.network) In general, you will need to open a port (20049 recommended, but you control it) and configure the node through the config file. It is also highly recommended to install the cron job so the node automatically updates as updates come out. ## Developers Developers can download, compile, and run a node here:\ \ [https://gitlab.com/quip.network/quip-protocol/](https://gitlab.com/quip.network/quip-protocol/) We do not recommend doing this UNLESS you are experimenting For what your hardware will actually be solving once the node is running, see [Miners](/docs/nodes/miners). To generate quantum-resistant keys as well, see the [Quickstart](/docs/getting-started/quickstart). --- # Miners Two families of hardware mine on Quip Network. **Classical miners** are the compute platforms that do not support entanglement: CPUs, GPUs, TPUs, NPUs, and the like. While the network often leads with quantum computing as a differentiator, these traditional architectures are first-class citizens that help validate the quantum computers are really delivering improved performance. The network currently publishes Metal and CUDA solvers as well as direct implementations for x86 and ARM CPUs. **Quantum miners** are any compute platform that supports entanglement through adiabatic quantum computing, or gate-based platforms featuring CNOT or Toffoli gates: neutral atom, trapped ion, superconducting, photonic, or otherwise. The ultimate goal of the network is to maximize the utilization of all quantum processors everywhere and to connect them together to solve the hardest problems as one unified quantum system. ## Node Requirements Node requirements are minimal. There is no barrier to entry for running a node, but you will have to fit the blockchain on local storage and your block rewards will be correlated with your ability to efficiently solve the Proofs of Useful Work supported by the network. The first Proof of Useful Work is finding the ground state energy of a Hamiltonian, often called an Ising Model problem. These solutions can be used in a variety of optimization and constraint programming problems, providing useful outputs for real businesses. Future Proofs of Useful Work may include things like Verifiable Random Functions, Hidden Subgroup Problems, Search, Quantum Key Distribution, or otherwise. The network currently publishes Qiskit and Ocean SDK solutions for the Ising subnet. If you have another framework or instruction set you would like to support, please submit an issue on [GitHub](https://github.com/quipnetwork). ## Run a Node Please see the [Run a Node](/docs/nodes/run-a-node-testnet) section. --- # Toolchain XQuad compiles quadratic optimization problems into bytecode for a single virtual machine, the XQVM, and runs that bytecode on whichever backend you point it at. A problem written once runs unchanged on a D-Wave quantum processor, a GPU annealer, a local CPU sampler, or the Quip Network. It plays the role LLVM plays for compilers: one intermediate representation, many targets. > **Note** > **Early public release.** The instruction set, binary format, and public API may change before v1.0. ## What it models Combinatorial problems that reduce to quadratic binary models: QUBO, Ising, and discrete formulations. Traveling salesman, graph coloring, knapsack, set cover, maximum independent set, and portfolio optimization all fall in range. You write the model in a constraint-programming DSL or in `.xqasm` assembly, compile it to a `.xqb` binary, and hand the result to a solver. ## Components A Rust core does the execution. Python packages wrap it and add the modeling and solver layers. | Package | Language | Role | | --- | --- | --- | | `xqvm` | Rust | The VM interpreter, opcode table, and bytecode codec. Builds `no_std + alloc`, so it also runs inside WASM runtimes and Substrate pallets | | `xqasm` | Rust | Assembler for the `.xqasm` text format | | `xqcli` | Rust | The `xquad` command: `asm`, `dism`, `run`, `verify` | | `xqffi` | Python | PyO3 bindings that expose `xqvm` and `xqasm` to Python | | `xqvm_py` | Python | Pure-Python reference VM, used as the conformance oracle | | `xqcp` | Python | Constraint-programming DSL that compiles to `.xqasm` | | `xqsa` | Python | Solver adapters for every supported backend | | `xquad` | Python | Umbrella package with the interactive `Program` / `Session` / `RunResult` API | A written specification defines every behavior, and CI runs each conformance vector on both the Rust VM and the Python reference VM. If the two disagree, the build fails. ## Backends | Backend | Hardware | Install | | --- | --- | --- | | Simulated annealing | CPU | `pip install xquad` | | CUDA annealer | NVIDIA GPU | `pip install xquad[cuda]` | | Metal annealer | Apple Silicon GPU | `pip install xquad[metal]` | | D-Wave Advantage | Quantum annealer | `pip install xquad[dwave]` | | Quip Network | Network-provided solvers | `pip install "xquad[quip]"` | Extras compose: `pip install xquad[cuda,dwave]`. ## Getting started ```sh pip install xquad # Python toolchain cargo install xqcli # the `xquad` binary ``` The full documentation covers installation, modeling, the instruction set, worked examples for a dozen classic problems, and the reference for every package. To run a model on the Quip Network rather than on your own hardware, see [Submit Your First Compute Job](/docs/compute/submit-a-job).