# Table of Contents - [Overview | Wiki](#overview-wiki) - [RAILGUN Privacy System | Wiki](#railgun-privacy-system-wiki) - [Getting Started | Wiki](#getting-started-wiki) - [Trusted Setup Ceremony | Wiki](#trusted-setup-ceremony-wiki) - [Zero-Knowledge Cryptography | Wiki](#zero-knowledge-cryptography-wiki) - [Privacy Overview | Wiki](#privacy-overview-wiki) - [Using Private Tokens | Wiki](#using-private-tokens-wiki) - [Wallets and Keys | Wiki](#wallets-and-keys-wiki) - [Community Broadcasters | Wiki](#community-broadcasters-wiki) - [Shielding Tokens | Wiki](#shielding-tokens-wiki) - [Private Proofs of Innocence | Wiki](#private-proofs-of-innocence-wiki) - [Integrating RAILGUN | Wiki](#integrating-railgun-wiki) - [Gasless Interactions | Wiki](#gasless-interactions-wiki) - [RAILGUN SDKs | Wiki](#railgun-sdks-wiki) - [Adapt Modules | Wiki](#adapt-modules-wiki) - [Example - DEX Swaps | Wiki](#example-dex-swaps-wiki) - [RAILGUN Deductions | Wiki](#railgun-deductions-wiki) - [Unshielding Tokens | Wiki](#unshielding-tokens-wiki) - [Helpful Links | Wiki](#helpful-links-wiki) - [RAILGUN Assurance Suite | Wiki](#railgun-assurance-suite-wiki) - [Koinly Tax Exports | Wiki](#koinly-tax-exports-wiki) - [RAIL Token Overview | Wiki](#rail-token-overview-wiki) - [RAIL Active Governor Allocation | Wiki](#rail-active-governor-allocation-wiki) - [RAIL Tokenomics | Wiki](#rail-tokenomics-wiki) - [How to Lock RAIL | Wiki](#how-to-lock-rail-wiki) - [Decentralized Governance | Wiki](#decentralized-governance-wiki) - [Overview | Wiki](#overview-wiki) - [Private Proofs of Innocence | Wiki](#private-proofs-of-innocence-wiki) - [RAIL Token Overview | Wiki](#rail-token-overview-wiki) - [Gasless Interactions | Wiki](#gasless-interactions-wiki) - [RAILGUN Deductions | Wiki](#railgun-deductions-wiki) - [Community Broadcasters | Wiki](#community-broadcasters-wiki) --- # Overview | Wiki ![Page cover](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FNjmkxKYP9z0w2ZC17mYq%252FWiki%2520banner%2520%283%29.png%3Falt%3Dmedia%26token%3D8d652614-1ac7-430d-ad34-944c24ada28b&width=1248&dpr=3&quality=100&sign=92827e9e&sv=2) [hashtag](https://docs.railgun.org/wiki#what-is-railgun) What is RAILGUN? ------------------------------------------------------------------------------ RAILGUN is code that exists on every Ethereum node. It's a privacy system built directly on-chain for Ethereum, BSC, Polygon, and Arbitrum. It uses Zero-Knowledge (ZK) cryptography to enable private use of smart contracts and DeFi, all without leaving the security of the user’s preferred chain. The RAILGUN code has no owner. Interactions on your chain of choice are made private. The RAIL token is purely a governance token and is not a privacy coin. Holding RAIL is not necessary to use the protocol and it does not confer any rights to holders. You can read more about governance [here](https://docs.railgun.org/wiki/rail-token/protocol-governance) . RAILGUN users have access to a special 0zk address that are confidential on Etherscan, Arbiscan, or any similar resource. Independent wallet providers can use the RAILGUN protocol, head [herearrow-up-right](https://railgun.org/wallets) to select from a list of wallet providers. RAILGUN is 100% non-custodial. The user experience is similar to using a public wallet to interact with Ethereum/EVM chains, just with the added ability to interact privately. As RAILGUN is simply on-chain smart contract code, privacy is achieved without the need to move to a separate chain. This provides 2 main advantages: 1. **Security & Decentralization** - No centralized control, no extra validators, and no trusted bridges. 2. **Full Ecosystem** - Rather than an isolated ecosystem on a standalone privacy chain, RAILGUN users have full access to all the economic activity and functions that the chain provides, and benefit from the rich history of existing dApps and builders. RAILGUN has 2 main components: 1. **RAILGUN-Integrated Wallets** - EVM wallets built by separate independent community developers through which users can use the RAILGUN protocol. A list can be found [herearrow-up-right](https://railgun.org/wallets) . 2. **Developer Tools** – includes TypeScript SDKs for building RAILGUN privacy into existing/new wallets or a privacy enabled dApp. Head to the [developer guidearrow-up-right](https://docs.railgun.org/developer-guide) to start building with RAILGUN. RAILGUN’s code is verified and publicly viewable, and its repository can be found [here.arrow-up-right](https://github.com/Railgun-Community) [hashtag](https://docs.railgun.org/wiki#benefits-and-use-cases-of-railgun) Benefits and use cases of RAILGUN ----------------------------------------------------------------------------------------------------------------- ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252Ft7FMVUqCN90NdQTskJuf%252Frailgun_flowchart_-02.png%3Falt%3Dmedia%26token%3D521dfa7b-0746-4d5c-a9ef-b32ef1d690b0&width=768&dpr=3&quality=100&sign=ffff7492&sv=2) As the diagram shows, looking from the outside in, when tokens are moved into RAILGUN’s smart contract, tokens and wallets become indistinguishable from one another without mixing one user's funds with another. Because of this, all transferring, swapping, lending, borrowing, and dApp calls create more noise and improve privacy for every other user. These DeFi interactions allow RAILGUN to function more privately than other protocols with a similar amount of tokens and users. Read [this articlearrow-up-right](https://medium.com/@Railgun_Project/what-is-crypto-privacy-how-railgun-can-help-7-privacy-tips-for-dank-degens-cce294c6fc70) for more on how privacy works in the RAILGUN protocol. Due to the availability of DeFi transactions, more rigorous privacy is achieved with RAILGUN with less liquidity and in a shorter timeframe than with other privacy systems. Arbitrary dApp interactions within RAILGUN’s privacy system also incentivizes users to hold their tokens for longer in RAILGUN as there is less reason to move tokens out of RAILGUN. Potential use cases: 1. **Alpha Protection:** Traders who want to keep their alpha confidential can trade freely and maintain their informational advantages. RAILGUN’s privacy system enables users to trade with reduced risk of hard-fought trading strategies and patterns being discovered and ripped off by freeloading actors, who can obtain such data on-chain by tracing interactions, then running them through analysis software to reverse engineer said strategies, without doing any of the actual work. 2. **Compliance with Law:** Businesses and professionals must use privacy tools, such as RAILGUN, to make sure that financial data is not leaked when interacting with clients. Lawyers, doctors, and psychologists, for example, are not allowed to reveal that their clients have paid for advice. They must protect the identity of the person engaging their services, as set out in common law, professional rules of conduct, European and British GDPR, the USA’s HIPAA, and other data protection legislation. Other businesses and professionals also have strict laws that apply to them to protect the financial information of their customers & staff. RAILGUN is used to comply with these laws. 3. **Private Payroll:** The privacy features of RAILGUN are needed for payroll services, when companies pay in cryptocurrency. 4. **Donation Privacy:** RAILGUN users can donate to charitable causes using cryptocurrency without needing to publicly reveal their link to these causes. 5. **Personal Protection:** RAILGUN users are not exposed on services like Nansen or Etherscan, where notable wallets are labelled or known. Any cryptocurrency user who wishes to protect their personal privacy can do so using RAILGUN. RAILGUN is a revolutionary toolkit and is objectively the most uncompromising privacy solution for DeFi. Private DeFi will enable new business possibilities for the cryptocurrency industry that are not possible on public blockchains. All other privacy solutions have some trade-offs, such as requiring users to trust custodial bridges or trade with fragmented/non-existent liquidity. ### [hashtag](https://docs.railgun.org/wiki#developer-guide) Developer Guide If you're a developer looking for the SDK documentation. [You can find it herearrow-up-right](https://docs.railgun.org/developer-guide) . [NextGetting Startedchevron-right](https://docs.railgun.org/wiki/learn/getting-started) Last updated 12 days ago Was this helpful? --- # RAILGUN Privacy System | Wiki The RAILGUN privacy system is a series of smart contracts that privatizes blockchain interactions. RAILGUN privatizes: 1. Sender 2. Recipient 3. Token type 4. Amount RAILGUN protects this information by utilizing Private Balances, a confidential set of tokens and users where interactions appear to originate from. These Private Balances are known as an privacy set as, to an outside observer; transactions can be sent by anyone who has previously made a transaction. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system#how-private-are-private-balances) How private are Private Balances? The overall level of privacy from Private Balances is a function of: 1. Total number of unique shield interactions and users. 2. Total Value Locked in the RAILGUN smart contracts. 3. RAILGUN DeFi interaction and Private Send volume. Generally, the higher the total number of unique shield interactions and users, the higher the level of confidentiality as links are less likely to be drawn between depositor and token, as there are a higher number of potential depositors to try and attach interactions to. Some consideration must also be given to token type. For example, using common stables like USDC or DAI will offer greater privacy vs using some unknown meme token with very few interactions. However, RAILGUN has additional privacy boosting capabilities due to its support of complex smart contract interactions and Private Sends. Every interaction that takes place (such as a swap on [Railway DEXarrow-up-right](https://github.com/Railgun-Community/community-faqs/blob/main/common/broken-reference/README.md) ), decreases the likelihood an interaction can be linked to a specific asset, increasing privacy for all users. As RAILGUN enables trading, you can use a small amount of crypto and theoretically trade up to a larger position privately, therefore the total size of the privacy set is less of a factor in maintaining privacy in RAILGUN. This means that privacy in RAILGUN's Private Balances is always greater than other privacy solutions with the same amount of TVL due to increased noise from interactions like Private Sends and swaps. For more detail on privacy in RAILGUN and some tips to further bolster privacy, check out [this articlearrow-up-right](https://medium.com/@Railgun_Project/what-is-crypto-privacy-how-railgun-can-help-7-privacy-tips-for-dank-degens-cce294c6fc70) . #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system#broadcasters-and-utxos) Broadcasters and UTXOs RAILGUN users can send transactions through [Broadcastersarrow-up-right](file:///C:/wiki/learn/privacy-system/community-relayers) , which are wallets that pass information to the blockchain and submit gas on a user’s behalf. Interactions sent by users appear to originate from Broadcasters and cannot be linked to a shielding address. RAILGUN’s transaction system uses [Unspent Transaction Outputsarrow-up-right](https://academy.binance.com/en/glossary/unspent-transaction-output-utxo) (UTXOs), similar to Bitcoin and Zcash’s spending system. A UTXO represents the ability to spend tokens and is implemented in RAILGUN as a [Merkle Treearrow-up-right](https://en.m.wikipedia.org/wiki/Accumulator_(cryptography)) ([accumulatorarrow-up-right](https://medium.com/@aurelcode/cryptographic-accumulators-da3aa4561d77) ), an organized and encrypted data tree which allows the RAILGUN smart contract to trace ownership and balances through cryptographic proofs. The difference here is that RAILGUN’s Merkle Tree is completely private and held in the smart contract. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system#railgun-sdk) RAILGUN SDK At its core, RAILGUN is low-level infrastructure with an SDK (Software Development Kit) for protocol integrations of private smart contract interactions and a private wallet. Users have a public on-chain address, that is a 0x address and a private RAILGUN address which begins with a 0zk. Interactions sent from 0zk addresses are private and appear on blockchain scanners (like Etherscan) as originating from a Broadcaster address. Identifying details are confidential at all stages of the process by encryption using zk-SNARK proofs. [PreviousGetting Startedchevron-left](https://docs.railgun.org/wiki/learn/getting-started) [NextZero-Knowledge Cryptographychevron-right](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography) Last updated 6 months ago Was this helpful? --- # Getting Started | Wiki ### [hashtag](https://docs.railgun.org/wiki/learn/getting-started#what-do-i-need-to-start-using-railgun) What do I need to start using RAILGUN? Using RAILGUN is simple, even for those new to DeFi and blockchains. You will need: * Network base tokens for the chain you wish to use (ETH for Ethereum & Arbitrum, MATIC for Polygon, and BNB for BNB Chain). * Assets held in a self-custodial EVM wallet (popular options include [Framearrow-up-right](https://frame.sh/) , [Rabbyarrow-up-right](https://rabby.io/) , and [MetaMaskarrow-up-right](https://metamask.io/) ) After this, you will need to select a frontend from the list of independent providers at [https://railgun.org/walletsarrow-up-right](https://railgun.org/wallets) , there is no single or official frontend for RAILGUN and all providers are built by independent community members and partners. Once you've selected a frontend, you can generate a 0zk private address to which you can [shield](https://docs.railgun.org/wiki/learn/shielding-tokens) tokens. [PreviousOverviewchevron-left](https://docs.railgun.org/wiki) [NextRAILGUN Privacy Systemchevron-right](https://docs.railgun.org/wiki/learn/privacy-system) Last updated 1 year ago Was this helpful? --- # Trusted Setup Ceremony | Wiki RAILGUN’s zk-SNARK circuits are proved using the [Groth16 arrow-up-right](https://eprint.iacr.org/2016/260.pdf) proof system, a [pairing-based zk-SNARKarrow-up-right](https://zkproof.org/2021/06/30/setup-ceremonies/) [design. arrow-up-right](https://zkproof.org/2021/06/30/setup-ceremonies/) Groth16 is the most widely used zk-SNARK (with [Zcash notably using it for the first ZK shieldedarrow-up-right](http://www.zeroknowledgeblog.com/index.php/groth16) [protocolarrow-up-right](https://www.zeroknowledgeblog.com/index.php/groth16) ) as it allows for efficient verifier performance and short proof strings, requiring less computation time and power. Groth16 requires the generation of randomization for each circuit in what is called a [‘ceremony’.arrow-up-right](https://zkproof.org/2021/06/30/setup-ceremonies/) ​ zk-SNARKs need a common reference string (CRS), a public parameter that is used in proving and verifying and must be generated in advance by a trusted party. This is because zk-SNARK proving systems require the prover and verifier to have access to some public common knowledge (in this case the CRS), that has been pre-generated by a shared algorithm. CRS is generated using these ceremonies by having multiple, independent, and decentralized participants contributing random text. This setup ceremony type involving multiple parties is known as multi-party computation [(MPC), arrow-up-right](https://zeroknowledge.fm/the-power-of-tau-or-how-i-learned-to-stop-worrying-and-love-the-setup/) which prevents any single party involved in the ceremony from gaining knowledge of the underlying mathematic structure of the CRS. The CRS (derived from individual submissions) is a set of encrypted values where at least one of the original un-encrypted values (Toxic Waste) is destroyed to ensure that no actor is able to generate fake proofs to maintain system security. The setup ceremony type used in RAILGUN’s circuits was the [Perpetual Powers of Tau.arrow-up-right](https://medium.com/coinmonks/announcing-the-perpetual-powers-of-tau-ceremony-to-benefit-all-zk-snark-projects-c3da86af8377) It is perpetual in the sense that there are no limits to the number of participants, and is what enables the security derived from the requirement of only 1 participant to destroy the CRS. The Perpetual Powers of Tau are points along the elliptic curve outputted from the ceremony and are used for private and public key derivation. This trusted setup is a requirement of Groth16 and allows for secure encryption, provided that the ceremony is performed correctly. One trusted setup ceremony is sufficient to secure the proving mechanisms, however, new ceremonies are required each time circuits are upgraded for performance, or when new features are added. As RAILGUN has optimized Groth16 zk-SNARK design for verification, the on-chain gas requirements are low considering the level of computation and encryption that is available in the RAILGUN privacy system. This is a more secure privacy system design than relying on an L2 for consensus. However, as above, new upgrades and circuit designs require new trusted setup ceremonies. The transcript of the RAILGUN setup ceremony is [herearrow-up-right](https://ipfs.stibits.com/QmWAySHYhaZqioKi1ufrPJC1n1ZVtHP2w4hLA9XqqJCFne) . [PreviousZero-Knowledge Cryptographychevron-left](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography) [NextCommunity Broadcasterschevron-right](https://docs.railgun.org/wiki/learn/privacy-system/community-broadcasters) Last updated 6 months ago Was this helpful? --- # Zero-Knowledge Cryptography | Wiki RAILGUN leverages Zero-Knowledge Proofs (ZKPs), a foundational tool for privacy preservation. ZKPs allow for advanced logic and contract interactions without information leakage. ### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography#what-are-zk-snarks) What are zk-SNARKs? [Zero-Knowledge proofs arrow-up-right](https://medium.com/web3studio/a-simple-explanation-of-zero-knowledge-proofs-ca574092e73b) are methods for one party, the prover, to mathematically satisfy another party, the verifier, the truth of information without revealing the originating details of the information. This is achieved by the prover-passing components of mathematical problems that deliver the truth and verifiability of the information, being proved to the verifier multiple times. These interactions occur until the verifier is satisfied that it is statistically impossible for the information to not be true or is being faked by the prover, all without revealing the contents of the verified information. ​[zk-SNARK arrow-up-right](https://consensys.net/blog/developers/introduction-to-zk-snarks/) stands for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge”. Put simply, a zk-SNARK is a form of ZKP that does not require direct interaction between the prover and verifier. Rather, they achieve their non-interactivity through the prover simulating the interactions between prover and verifier, and the verifier simply checks that the simulation was performed correctly. These proofs rely on computational assumptions that cannot be cracked. As it stands, it would take millions of years to crack with currently available computational power. For zk-SNARKs to be “succinct”, the proof size and verification cost must be small, logarithmic, or lower. [Elliptic curves allow for smaller key generation arrow-up-right](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/) and therefore more succinct ZK proof outputs. Elliptic Curve Cryptography use points on an elliptic curve graph to generate public and private keys from mathematical equations between the points on the curve. They form the basis of the RAILGUN privacy system, as zk-SNARKs allow a smart contract to act as a verifier. The verifiers in RAILGUN are the smart contracts themselves. RAILGUN uses [EIParrow-up-right](https://eips.ethereum.org/EIPS/eip-197) [197 arrow-up-right](https://eips.ethereum.org/EIPS/eip-197) and [EIP 198, arrow-up-right](https://eips.ethereum.org/EIPS/eip-198) together enables RAILGUN to generate zk-SNARK circuits on-chain. These zk-SNARK circuits are created on the client side and can then be submitted for confirmation on-chain. zk-SNARKs can prove any form of information, such as valid unspent token balances or, in other terms, who has the right to spend which token on a blockchain without revealing details about the person originating the interaction. ### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography#what-is-a-circuit) What is a circuit? ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FXj738bisL5jHpEjo5p95%252FzkSnarks%2520%282%29.png%3Falt%3Dmedia%26token%3D688056a0-a645-4742-a973-8822dfadfc62&width=768&dpr=3&quality=100&sign=8807a6a3&sv=2) Example arithmetic circuit to prove the output using the mathematic gates and inputs a, b, and c ### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography#railguns-zk-snark-circuit-design) RAILGUN's zk-SNARK Circuit Design The advanced cryptography contained in RAILGUN’s privacy system has 54 circuits to enable complex interaction types. Each circuit is differentiated by the number of inputs and outputs, and together they form the cryptographic basis for RAILGUN. Multiple circuits are needed to account for different transaction types as circuits require the number of signals (inputs and outputs) to be instantiated at the setup phase. For example, a transaction that sends DAI to 2 different 0zk addresses might require a circuit with 1 input to 2 outputs. Extending this idea, a transaction that sends DAI comprised of 7 UTXO balances to 2 0zk addresses would require a 7 to 2 circuit. Inputs in these scenarios are equivalent to UTXOs and outputs would be equivalent to recipients. Currently, there are 54 circuits, each with different numbers inputs (UTXOs) and outputs (UTXO destinations). Circuits can be chained together to handle all possible combinations of UTXOs and outputs, and the system will automatically route a transaction through the most gas & cost efficient combination. RAILGUN also supports multiple inputs to singular outputs, such as 5 to 1. These circuits are used for multi-sends, where users send more than 1 token type in the same transaction to a singular recipient. They are also useful for swaps where the price of the token has changed, leaving some leftover change in the original swap token or for paying a Broadcaster in a token other than the one being sent. E.g., if WETH is sent as a Broadcaster fee to send DAI. RAILGUN’s circuit design is flexible in terms of supporting tokens other than just ERC-20, RAILGUN can Shield ERC-721 and ERC-1155 NFTs. For example, with RAILGUN’s circuits and smart contracts, users could potentially provide liquidity on Uniswap v3 privately and shield their LP NFT privately as well. This kind of composability is only possible with the flexibility of RAILGUN’s privacy system and is the result of it being designed from the ground up for real world DeFi use cases. [PreviousRAILGUN Privacy Systemchevron-left](https://docs.railgun.org/wiki/learn/privacy-system) [NextTrusted Setup Ceremonychevron-right](https://docs.railgun.org/wiki/learn/privacy-system/trusted-setup-ceremony) Last updated 6 months ago Was this helpful? --- # Privacy Overview | Wiki With this knowledge of [ZK proofs and zk-SNARKsarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography) , we can see how RAILGUN maintains privacy. Users can prove they can spend tokens without needing to share what those tokens are and how much they have of it. Broadcasters and the privacy set then enhance the data confidentiality for senders and recipients of interactions such that no identifiable information is compromised at any stage in the process. To use an old-world analogy, RAILGUN users are writers of letters, ZK proofs fact check the contents of the letters, RAILGUN smart contracts are a sealed envelope, and Broadcasters are mailmen. All an outside observer can see is that a letter has been posted, but they would have no visibility as to what is in the letter or who has sent it. ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252Ft7FMVUqCN90NdQTskJuf%252Frailgun_flowchart_-02.png%3Falt%3Dmedia%26token%3D521dfa7b-0746-4d5c-a9ef-b32ef1d690b0&width=768&dpr=3&quality=100&sign=ffff7492&sv=2) [PreviousCommunity Broadcasterschevron-left](https://docs.railgun.org/wiki/learn/privacy-system/community-broadcasters) [NextWallets and Keyschevron-right](https://docs.railgun.org/wiki/learn/wallets-and-keys) Last updated 6 months ago Was this helpful? --- # Using Private Tokens | Wiki RAILGUN’s interaction system is similar to the Bitcoin network’s, with the notable exception that everything is privatized by ZK proofs. The Merkle Tree keeps track of all balances held by 0zk addresses in the system which can only be updated if proof that passes the cryptographic validation rules is submitted to the RAILGUN smart contracts. ### [hashtag](https://docs.railgun.org/wiki/learn/using-private-tokens#utxos-and-nullifiers) UTXOs & Nullifiers RAILGUN operates on a [(U)TXO (unspent transaction output) modelarrow-up-right](https://academy.binance.com/en/glossary/unspent-transaction-output-utxo) , (U) is in brackets as transaction outputs are completely secure from outside observers. Each UTXO is an encrypted note of a public key that establishes who can spend the underlying asset, amount, token ID, and a randomness field to maintain encryption. The output of RAILGUN circuits are UTXOs and Nullifiers, which is a hash generated from private keys that cannot be linked to a UTXO by anyone who is not a party to the transaction. Nullifiers are deterministically generated to further guard against double spends - put simply, they nullify a UTXO and disallow it from being spent again in the system. Nullifiers (and therefore circuit outputs) are calculated by a hash of the Spending Key combined with path indices of the Merkle Root/Leaf note, meaning that each note will always generate a unique Nullifier. The party holding the Spending Key is the only actor who can link which Nullifier as belonging to a corresponding UTXO. This also means that Broadcasters cannot change the transaction values, such as amount or destination address, without rendering the hash and note invalid and therefore failing the ZK proof checks. With RAILGUN’s zk-SNARK circuits, users can mathematically prove that they have valid UTXOs and therefore prevent double spend or false transactions whilst not showing any underlying information. Once all the cryptographic validation tests are passed, the Broadcaster will then submit the note to the blockchain for consensus and confirmation and the spend transaction is complete. ### [hashtag](https://docs.railgun.org/wiki/learn/using-private-tokens#railgun-smart-contract-transact) RAILGUN Smart Contract: _transact()_ Spend transactions call the transact() function. This function is used to interact with your private balance in a number of ways. This is accomplished by verifying that the Nullifiers in the internal Merkle Tree path correspond to the circuit-inputs and number of circuit-outputs being spent. Essentially, this function feeds to a zk-SNARK proof to ensure that the number of inputs matches the number of outputs on the circuit, and enforces the rule that Nullifiers must not have been seen anywhere on the Merkle Tree before. If these nullifiers have been seen before, it is then verified that this is not a valid spend transaction and the user does not have the requisite UTXOs (insufficient funds) to send the transaction. The `transact()` function emits the following events which are triggered when the RAILGUN contract detects any balance changes in the system: * `CommitmentBatch` – New zk-SNARK circuit outputs (i.e. new notes) occurring from the send transaction and transact() call. * `Nullifiers` – Private double spend markers that nullify the zk-SNARK circuit inputs used in the send transaction to ensure the UTXOs cannot be used again. For the purposes of integration, only a surface level understanding of the `transact()` function is required to integrate the RAILGUN SDK as the SDK again, and handles the computation on the integrating dApp’s behalf. For RAILGUN transactions to execute, some publicly observable input data will be broadcast to the wider blockchain network. These hashed public inputs are used to represent and validate outputs from the zk-SNARK circuits. This input data is always hashed and cannot be unencrypted by anyone who is not a party to the transaction. Hashing means that whilst the hashed values can be seen, no outside observer can reverse the hashing algorithm to arrive at the unencrypted input data, maintaining complete privacy throughout. The RAILGUN `transact()` function has the following public inputs: * `merkleRoot` * Any previous Merkle Root from the entire Merkle Tree. The RAILGUN smart contract computes a new Merkle Root each time funds are transferred. This does not need to be the newest Merkle Root, rather it is a race condition for the first Merkle Root picked up by the function. * `boundParamsHash` * Each dApp integrated with RAILGUN has its own unique parameters. Due to the constraints of circuit design, i.e., all circuits must be fixed before computation, this hash is computed at the user side for each required parameter instead of designing a custom circuit for each parameter. * Hash of the following values: * `formattedRandom` – Randomization factor to preserve security in hashing * `requireSuccess` – Boolean value that requires the contract call to be successful before progressing * `minGas` – Minimum amount of gas to be supplied to the transaction * `to/value/datanullifiers[nInputs]` – Nullifiers for the input notes * `nullifiers [nInputs]` * Nullifiers themselves are also hashed values. This public input is used to nullify the UTXO being sent in the transaction. The nullification computation occurs in such a way that only the user can determine which UTXO has been spent, and an outside observer cannot link a Nullifier and note. The `[nInputs]` value is the number of inputs. * `commitmentsOut [noutputs]` * Any new inputs being created requires new notes and this parameter is the hashed note of the balance changes from the spend transaction. [PreviousShielding Tokenschevron-left](https://docs.railgun.org/wiki/learn/shielding-tokens) [NextGasless Interactionschevron-right](https://docs.railgun.org/wiki/learn/using-private-tokens/gasless-interactions) Last updated 6 months ago Was this helpful? --- # Wallets and Keys | Wiki RAILGUN wallets (and by extension 0zk addresses/keys) can be created by any wallet infrastructure linked to the RAILGUN SDK. The first such wallet is the [Railway Walletarrow-up-right](https://railway.xyz/) , developed by a partner project of RAILGUN. The RAILGUN SDK follows the BIP-32 standard for key derivation from a seed, which allows for [hierarchical deterministic wallets arrow-up-right](https://river.com/learn/terms/b/bip-32/) along an elliptic curve. To learn more about key derivation standards: \- For bip32, start [herearrow-up-right](https://trezor.io/learn/a/what-is-bip39) with bip39 mnemonics for how seed phrases work. \- [Herearrow-up-right](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for the method to take the randomness the seed phrase represents and derive keys from it, being bip32. \- [SLIP-44arrow-up-right](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) which defines standard paths that wallets derive along to get the key for a particular coin. Users have access to 2 kinds of keys in their RAILGUN wallets: 1. Spending Key – The key that allows users to cryptographically prove they own their tokens and send interactions. Spending Keys are analogous to a regular cryptocurrency wallet private key, only with a private 0zk address. 2. Viewing Key – A key that exclusively allows viewing of all interactions (including private ones) sent by a particular address. Users can define the beginning and ending block for which the Viewing Key can observe in a scoped way. This is useful for auditability purposes, for example, a user can define the beginning and end of a tax year for their Viewing Key by block number. Both the public Viewing Key and Spending Key are encoded in the 0zk address, hence why private addresses on RAILGUN are longer than standard 0x addresses. The key generation method is identical to how most other crypto keys are generated. Private keys are of course, not shared publicly at any stage in wallet generation nor are they shared with any components of the RAILGUN system such as provers, verifiers, or Broadcasters. ### [hashtag](https://docs.railgun.org/wiki/learn/wallets-and-keys#spending-keys) Spending Keys Spending Keys are generated along the [Baby Jubjub elliptic curve, arrow-up-right](https://eips.ethereum.org/EIPS/eip-2494) which is a zk-SNARK-friendly elliptic curve, and follows the BIP-32 standard. Zk-SNARK proof verification on a blockchain requires the embedding of an elliptic curve inside a zk-SNARK circuit to enable succinctness and to fit within a block gas limit. Baby Jubjub enables efficient cryptographic functions to be built on-chain. ### [hashtag](https://docs.railgun.org/wiki/learn/wallets-and-keys#viewing-keys) Viewing Keys Viewing Keys are implemented on Edwards-curve Digital Signature Algorithm [(EdDSA) arrow-up-right](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) curves, specifically Ed25519. Viewing Keys enable the holder to decrypt the encoded interaction information but not send interactions. They merely scan the RAILGUN smart contract events to reveal what has been sent to users and what interactions users have sent. A different key derivation scheme is used for viewing keys as Ed25519 is more efficient if no zk-SNARK circuits need to be used. **NOTE:** _Once a Viewing Key is generated, they are irrevocable, meaning that whoever holds the key can see private interactions forever. An upcoming update will allow Viewing Keys to be scoped by block number, i.e. only display interactions from Block Number X to Block Number Y._ [PreviousPrivacy Overviewchevron-left](https://docs.railgun.org/wiki/learn/privacy-system/privacy-overview) [NextShielding Tokenschevron-right](https://docs.railgun.org/wiki/learn/shielding-tokens) Last updated 6 months ago Was this helpful? --- # Community Broadcasters | Wiki Community Broadcasters are public 0x wallets that submit gas to the underlying blockchain on RAILGUN privacy users’ behalf. Actions coming from 0zk addresses appear to originate from Broadcaster addresses. As they are simply a 0x address, anyone can theoretically be a Broadcaster. Broadcasters run a micro Node.Js that broadcasts gas to Broadcaster Clients (i.e. wallets equipped with RAILGUN). Broadcasters also automatically process interactions when received. When users send an interaction in RAILGUN, they select an appropriate Broadcaster, typically based on low gas and availability. The interaction is encrypted in transit, and its contents cannot be read by the Broadcaster, except for an amount of gas which is packaged to allocate to the Broadcaster’s services. Upon receipt of a interaction, the selected Broadcaster will validate its packaged supply and submit the interaction to the underlying blockchain network. Through submitting the interaction, the Broadcaster obscures the sender, amount, receiver, and token details. This makes interactions confidential so they cannot be associated with the sender’s 0x public address. NOTE: At no point do Broadcasters custodially hold users’ tokens nor do they confirm interactions themselves, they merely transfer encrypted information for confirmation by the underlying blockchain infrastructure. Broadcasters are also unable to decrypt details about the interactions, nor can they change the details of an interaction as changing any information would lead to an invalid hash and be rejected by the system as an incorrect cryptographic proof. The Broadcaster network is robust from a game theory perspective. If a user’s chosen Broadcaster refuses to pass on an interaction for whatever reason, then they can send it to another cooperative Broadcaster. All that it takes is for at least 1 cooperative Broadcaster to submit the data on-chain for the underlying blockchain’s ledger to update. ### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-broadcasters#waku-network) Waku Network Broadcasters communicate with users through the [Waku arrow-up-right](https://waku.org/) peer-to-peer private communication network. Waku is a decentralized messaging protocol with strong privacy preservation such as sender confidentiality, metadata protection, and secure personally identifiable information. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-broadcasters#how-does-railgun-use-waku) How Does RAILGUN use Waku? Waku connects Broadcasters with users to broadcast gas supplies and inform Broadcasters that they wish to have an interaction broadcasted. **Transaction Broadcasts** All interactions that require a Broadcaster generate an additional note addressed to the selected Broadcaster using the Broadcaster's public key. Transaction data is then encrypted and broadcast to the Broadcaster network through the `transact()` function. The user's client then encrypts their transaction data with a shared key derived from the Broadcaster's public key and a randomly generated private key. Broadcasters then attempt to decrypt every message on the chain's where they are listening for messages. Any messages that can be decrypted by a Broadcaster are thus addressed to them. If such a note is found and can be decrypted by the Broadcaster, they verify that the value and token of the note match a previously advertised rate \* the estimated gas of the transaction. Once an acceptable gas submission is included in the transaction, the Broadcaster signs and submits the transaction for consensus by the underlying blockchain. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-broadcasters#interaction-response) Interaction Response The Broadcaster then broadcasts the success/failure status of the transaction in an encrypted message over Waku through the `transact-response.json` file. This status message is encrypted using the shared key derived in the earlier transaction broadcast stage. The client listens to the `transact-response.json` content topic for any message they can decrypt using the previously randomly generated private key. In the event of failure, the transaction sender can retry with the same Broadcaster or select a new Broadcaster. [PreviousTrusted Setup Ceremonychevron-left](https://docs.railgun.org/wiki/learn/privacy-system/trusted-setup-ceremony) [NextPrivacy Overviewchevron-right](https://docs.railgun.org/wiki/learn/privacy-system/privacy-overview) Last updated 6 months ago Was this helpful? --- # Shielding Tokens | Wiki The first step in using the RAILGUN Privacy System is to privatize cryptocurrency tokens. Shielding is the process whereby tokens enter the wallet’s private 0zk address from the public 0x address. Once tokens are in the 0zk address, users can send, swap, and interact with DeFi privately. Further, any token that exists on the public blockchain can be shielded, which would include any ERC-20 token as well as ERC-721 NFTs. Users initiate shielding by sending a shield interaction which contains public data (the token, the amount, and other values called) from their public wallet. The RAILGUN smart contracts then take these values and computes a commitment (called a note). Notes are a hashed value of the public data sent by the user at the start of the shielding process. The hashed value of a note (a circuit output) cannot be reversed to show the original value (an input). Inputs and outputs in this context are the interaction/token data. ### [hashtag](https://docs.railgun.org/wiki/learn/shielding-tokens#railgun-smart-contract-shield) RAILGUN Smart Contract: _shield()_ When a user initiates a shielding interaction, they call the Solidity function, `shield()`. This function includes everything required to shield assets into the RAILGUN privacy system, including the Poseidon hash function for encrypting notes. The Merkle Tree to which new notes are committed is also stored in the smart contract storage in variables called `merkleRoot` and `merkleLeaf`, and is handled by the `Commitments`.`sol` contract. The `shield()` function emits the `Shield` event upon completion. Events within the RAILGUN smart contract contain data within them. Due to RAILGUN’s hashing functions and zk-SNARK proving systems, this data can only be read by the holder of either the Spending Key or Viewing Key, preserving privacy each time the smart contract is called. For developers integrating RAILGUN SDK, the `shield()` function and anything related to shielding tokens will not require specific integration efforts as the SDK will abstract all encryption and interaction generation functions. ### [hashtag](https://docs.railgun.org/wiki/learn/shielding-tokens#railgun-smart-contract-transact) RAILGUN Smart Contract: transact() Spend transactions call the `transact()` function. This function is used to interact with your private balance in a number of ways. This is accomplished by verifying that the Nullifiers in the internal Merkle Tree path correspond to the circuit-inputs and number of circuit-outputs being spent. Essentially, this function feeds to a zk-SNARK proof to ensure that the number of inputs matches the number of outputs on the circuit, and enforces the rule that Nullifiers must not have been seen anywhere on the Merkle Tree before. If these nullifiers have been seen before, it is then verified that this is not a valid spend transaction and the user does not have the requisite UTXOs (insufficient funds) to send the transaction. ### [hashtag](https://docs.railgun.org/wiki/learn/shielding-tokens#private-pools-and-merkle-trees) Private Pools & Merkle Trees ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FeWPHFEiEaq9EdPDmWcVD%252FHash.png%3Falt%3Dmedia%26token%3D074fae6e-2794-4ae4-8ca9-a14e77f9eb59&width=768&dpr=3&quality=100&sign=bb54f009&sv=2) Merkle Tree data structure, the Root (top level) is a hash of all the corresponding leaves (everything below the top level) Once tokens are shielded by the cryptographic methods described above, they’re added to the privacy set in the RAILGUN smart contract. The RAILGUN system contains an efficient internal implementation of a batch-incremental Merkle Tree. Each shield interaction generates a new note which takes the form of a new Root/Leaf on the Merkle Tree. All tokens within the RAILGUN system share the same Merkle Tree. Every interaction that updates the state of the Merkle Tree will generate a new Merkle Root/Leaf that is hashed and secured by the zk-SNARK circuits. During the shielding process, the RAILGUN smart contract requires the amount and sending wallet address. This means that the sender of a `shield` interaction’s public key is broadcast to the wider blockchain network. However, this is a regular blockchain interaction and not a centralized retrieval of the public key and is necessary to send tokens from the public ledger. Shields and Unshields are the only types of RAILGUN interactions that contain public information as they interact directly with public addresses. Once the appropriate proofs and notes have been added to the RAILGUN smart contract Merkle Tree, privacy is achieved. Interactions appear to originate from a Broadcaster, and therefore technically-speaking can have come from anyone in the private pool who has sufficient tokens to send the UTXO associated with the transaction. What’s more, all identifying information such as the amount of transactions are not shown in block explorers. ### [hashtag](https://docs.railgun.org/wiki/learn/shielding-tokens#shielding-nfts) Shielding NFTs The RAILGUN smart contracts supports the shielding of ERC-721 non-fungible tokens. Users are able to add NFTs to their private balance in order to protect the source of NFTs. This creates interesting integration possibilities, like the private auctioning of popular NFTs. But NFTs are much larger than merely JPEG images of primates. Many DeFi protocols, like Uniswap v3, which issues NFTs to represent LP positions. With the integration of NFTs into RAILGUN, users are able to safeguard NFTs in order to: * Auction NFT assets to private buyers * Provide liquidity privately on Uniswap v3 [PreviousWallets and Keyschevron-left](https://docs.railgun.org/wiki/learn/wallets-and-keys) [NextUsing Private Tokenschevron-right](https://docs.railgun.org/wiki/learn/using-private-tokens) Last updated 6 months ago Was this helpful? --- # Private Proofs of Innocence | Wiki ### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#overview) Overview Private Proofs of Innocence is a decentralized bad transaction prevention system built by zero-knowledge (ZK) cryptography researchers. It is an independent partner project to the RAILGUN Project. Anyone can see Private POI in action at [ppoi.infoarrow-up-right](https://ppoi.info/) by entering a RAILGUN transaction hash. Private Proofs of Innocence List Providers: * [Ellipticarrow-up-right](https://www.elliptic.co/) * [ScamSnifferarrow-up-right](https://www.scamsniffer.io/) * [PureFiarrow-up-right](https://purefi.io/) * [SlowMistarrow-up-right](https://www.slowmist.com/) * [Chainalysis Sanctions Oraclearrow-up-right](https://go.chainalysis.com/chainalysis-oracle-docs.html) Private Proofs of Innocence is a tool that monitors tokens entering the RAILGUN smart contract to verify that they are not from a known list of transactions or actors deemed to be illegitimate. Upon a shield, a ZK proof is automatically created that proves that the tokens are not a part of a pre-set list of interactions and wallets. This process is end-to-end encrypted and enables decentralized and private assurance of tokens, without compromising user privacy. Private Proofs of Innocence sits alongside (but is separate from) the RAILGUN smart contracts, and is also open-source infrastructure that can be used by other protocols. Private Proofs of Innocence uses only publicly available data and does not reveal anything else about RAILGUN users or their balances and activity, nor does it give any third party any access into the RAILGUN privacy system. It also does not erode the privacy of using RAILGUN nor does it change how the underlying smart contracts’ spending system works; all interactions from 0zk addresses are and always will be impossible to be made public by anyone. Because of this, Private Proofs of Innocence is a superior detection tool to previously existing methods, and is an advancement in both ZK and privacy technology. Legacy bad actor detection tools requires users to give up some personal data like identity documents to a centralized middleman or firm stored in a centralized data lake, exposing personal information to potential vulnerabilities. Private Proofs of Innocence achieves similar aims to a similar level of effectiveness whilst only using public on-chain data, all whilst requiring no personal information. Private Proofs of Innocence protects all RAILGUN users in the following ways: * Users can feel comfortable that they are not sharing a privacy system with known bad actors, which reduces risks for every single RAILGUN user. * Exchanges or other external participants can gain confidence on interactions that they receive from RAILGUN users, ensuring smoother processing and a reduction of wait times. * Users can be sure that private sends they receive from other RAILGUN users are safe and not from known suspicious activity. * Flexible input data which can be adjusted to the user’s risk profile and local jurisdiction, i.e., European users can pick lists relevant to the European Union or United States users can pick lists relevant to the USA etc. ### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#how-it-works) How it works ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FbquX783aE4MvMOjLK4d2%252Fimage.png%3Falt%3Dmedia%26token%3Db480e4b9-0786-4188-b7b4-7815e1336cd4&width=768&dpr=3&quality=100&sign=7aa82f7f&sv=2) Private Proofs of Innocence Architecture Private Proofs of Innocence checks begin when tokens enter the RAILGUN privacy system after a shield interaction. Broadly, the steps are as follows: 1. List Providers input public, non-personal, and on-chain data of bad transactions 2. User performs a shield interaction, and waits for the Unshield-Only Standby Period 3. A blinded proof is auto-generated stating that the tokens in the shield are not a part of the List Provider dataset 4. Private Proofs of Innocence checks are then carried forward for any subsequent interactions involving the checked tokens 5. If those tokens are sent to an external exchange, that exchange (or any independent party) can see the valid Private POI proof without seeing anything else about the user like their 0zk address, balances, or history. This helps external actors gain confidence on tokens they receive from a RAILGUN address without affecting user privacy in any way. #### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#unshield-only-standby-period) Unshield-Only Standby Period With Private Proofs of Innocence, there is an Unshield-Only Standby Period, during which the only available action will be an unshield interaction to return tokens back to the original wallet. This Unshield-Only Standby Period is to give List Providers enough time to update their data such that bad actors are unable to hop addresses quickly to outrun data updates. As always, during this Unshield-Only Standby Period, users retain full control and custody over their tokens and can be unshielded back to the shielding address if needed urgently. To begin with, in the wallet applications that support Private Proofs of Innocence, this Unshield-Only Standby Period will be 1 hour, meaning tokens in new shields will have to wait 1 hour before they can be used in further interactions other than reverting out without privacy back to the original address. #### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#transaction-level-checks) Transaction Level Checks Private Proofs of Innocence works at the balance and transaction level. Meaning, Private Proofs of Innocence proofs are generated after the initial shield transaction and apply to the tokens that are a part of that interaction. They are then carried forward for every following transaction within RAILGUN involving those tokens. For example: 1. Alice sends 100 USDC into a 0zk address and generates a Private POI proof which applies to that 100 USDC. In this example, she is using AliceWallet; one wallet option of many that features RAILGUN privacy options and Private POI. 2. She then sends that 100 USDC to Bob, who can use Alice’s existing Private POI proof to show that the funds he received from Alice are not a part of the list of illicit activity. 3. Bob then sends that 100 USDC to a 0x wallet owned by Carl. All Carl knows is that the 100 USDC he received has a valid Private POI proof. As it is a RAILGUN interaction, he does not know anything else about Alice and Bob’s on-chain activity other than what they choose to tell him personally. He would not even know that the tokens were from Bob’s 0zk address is not revealed unless Bob chooses to tell him. 4. Alice then sends an additional 50 USDC which generates another Private POI proof that applies to that shield of 50 USDC. #### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#list-providers) List Providers Private Proofs of Innocence starts with a List Provider, a dataset of transactions and addresses through an API (Application Programming Interface) of which to prove against (i.e., a list of bad actor activity for users to ZK prove that they are not a part of). Anyone can choose to publish their own lists and be a List Provider. Users and wallets are free to use whatever combination of List Providers they please, although some wallet providers will require a default List Provider. The ZK-cryptography generates an independent proof per Private Proofs of Innocence List Provider, which is verified and made available for further usage, without revealing any of the encrypted details of the interaction or the user. **Note: List Providers only look at publicly available data and gain no special insight into transactions. Private Proofs of Innocence does not affect privacy levels in the RAILGUN privacy system. All data relating to 0zk addresses (including balances, history, and addresses) are and always will be encrypted to everyone.** List Providers are a read-only data source. Wallets do not send any data from Private POI or proofs to List Providers, and they cannot log IP addresses. **Private Proofs of Innocence Nodes** Private Proofs of Innocence Nodes sync proof data and make it available for anyone interested in verifying Private Proofs of Innocence checks. To prevent spam from being submitted, proof data is synced in a manner similar to the Interplanetary File System (IPFS), a decentralized data storage network. Wallets create proofs with encrypted data and update a shared list through Private Proofs of Innocence Nodes. Only the sending and receiving parties can decrypt this data, so no other party gets any information about what interactions they are linked to or what interactions are proved, ensuring complete privacy. Since unshield interactions have a public recipient, anyone can check if an unshield interaction is proved (and thereby knowing that it has a series of private proofs to a shield that is not on the bad transaction list), but they cannot see into the transaction other than that it was validly proved to not be from a publicly known set of bad transactions. This enables RAILGUN-integrated wallets, centralized exchanges, or anyone needing to verify that a shield has a Private Proofs of Innocence. Again, there is no special insight for Private Proofs of Innocence nodes. Like IPFS, anyone can run a Private Proofs of Innocence node. This ensures decentralized verification of Private Proofs of Innocence data such that every participant in the system can check proof validity for themselves rather than relying on a centralized actor. #### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#broadcasters) Broadcasters As 0zk addresses cannot broadcast transactions or submit gas to Ethereum nodes they need a broadcasting wallet. Public Broadcasters broadcast interactions to the network and submit the necessary gas. They receive a RAILGUN private send at the same time to recover their costs, which is done in a private transaction. Before Broadcasters can do this with any given set of tokens, those tokens must have a completed Private Proofs of Innocence check. Broadcasters have Private Proofs of Innocence nodes which sync and verifies proof data. In cases where there is an incomplete Private Proofs of Innocence check for a series of tokens (such as during the Unshield-Only Standby Period), users can Self-Broadcast a transaction to return tokens back to the original shielder. **Full Transaction Private Proofs of Innocence Flow** The following is an example of how RAILGUN private transactions flow following completed Private Proofs of Innocence after an initial shield: 1. Bob's tokens begin with a Private POI, either from a shield or a 0zk-0zk transfer. This will be generated automatically by the sender's wallet, designating Bob's funds as "Spendable." In the case of a shield, the Private POI proof will be automatically generated by each List based on public on-chain data. 2. Bob proves a transaction to send DAI to Alice through a Broadcaster. As part of the proof, Bob generates a special Proof of Spendability, which verifies the Private Proofs of Innocence proof for the Broadcaster, and guarantees that the received premium will be verified and spendable. 3. Bob sends the transaction through the Broadcaster and waits for it to be forwarded and confirmed by the blockchain. 4. Once confirmed, Bob's wallet automatically generates a Private POI proof for a blinded hash of the UTXO commitment that he sent to Alice. The POI data is validated by POI nodes, which make the blinded data available publicly. 5. Alice's wallet inherits the Private Proof of Innocence, based on the blinded commitment that only her viewing key could decrypt. This automatically designates her tokens as Spendable, for transfers, unshields or swaps & DeFi dApps, without her needing to generate her own Privte POI proof. This ensures that the Private Proofs of Innocence system is efficient, as proofs need to only occur once within the RAILGUN system for each shield interaction, even if those tokens are then spent by the initial shielding user. The only case where an additional Private Proofs of Innocence proof is needed is if the tokens are sent out of a 0zk address and the user reuses them in RAILGUN. ### [hashtag](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence#zk-cryptography) ZK Cryptography Private Proofs of Innocence works with existing RAILGUN ZK cryptographic systems. Each RAILGUN 0zk balance is comprised of a set of encrypted [UTXOsarrow-up-right](https://docs.railgun.org/wiki/learn/using-shielded-tokens#utxos-and-nullifiers) organized via a private [Merkle Treearrow-up-right](https://docs.railgun.org/wiki/learn/shielding-tokens#private-pools-and-merkle-trees) . Every RAILGUN transaction, such as a Private Send, generates a ZK proof (through [cryptographic circuitsarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography#what-is-a-circuit) ) verifying that the sender has sufficient UTXOs in their balance to send the transaction. If the balance is enough for the transaction, then it is valid and the Merkle Tree updates with the new change in balance and state. This is how RAILGUN internal balances are maintained. As Private Proofs of Innocence sits alongside the RAILGUN smart contracts, it does not affect this Merkle Tree-based spending system in any way. Instead, it enables users to generate an additional recursive proof, which is a proof that the underlying proofs of a user’s balance are not a part of the bad transaction list. As RAILGUN allows for intermediate 0zk balance transfers between shield and unshield interactions and each of these interactions is itself a proof, Private Proofs of Innocence has a recursion mechanism to assert further statements about these existing proofs. Recursive SNARKs can prove the entire flow of funds from the initial shield interaction satisfies the conditions of the Merkle proof of non-inclusion. Private Proofs of Innocence will compute proofs for every leaf in the regular Merkle Tree that apply to a balance of UTXOs and account for intermediate interactions between shield and unshield interactions. This is done through recursive SNARKs which tie the whole proving system together. [PreviousHelpful Linkschevron-left](https://docs.railgun.org/wiki/learn/helpful-links) [NextRAILGUN Assurance Suitechevron-right](https://docs.railgun.org/wiki/assurance/railgun-assurance-suite) Last updated 12 days ago Was this helpful? --- # Integrating RAILGUN | Wiki RAILGUN’s largest advancement in privacy technology is the ability to interact with smart contracts native to chains where RAILGUN is deployed. Through ZK proofs and the cryptography described above, as well as additional smart contracts (called Adapt Modules), privacy can be added to any on-chain dApp. Adapt Modules form the core of the RAILGUN SDK. For developers, the fact that RAILGUN lives directly on-chain means that they do not have to refactor their existing code and deploy contracts on unproven networks with no liquidity. They can integrate RAILGUN with confidence that their dApps will be just as secure as before, as the system is as secure as the main blockchain, with no security tradeoffs. For developers, the theoretical maximum user base for integrating the RAILGUN SDK is all of their existing users plus any additional privacy-conscious users. Users do not have to wait for new dApps to be built or redeployed on an off-chain solution nor do they have to wait for liquidity to arrive as it already is present in the underlying dApp. RAILGUN and its SDK thus has the best product market fit out of any privacy solution. Adapt Modules are separate smart contracts to the main RAILGUN privacy smart contracts, this architecture has 2 key advantages: 1. Increased security and protection of privacy as the external integrations of RAILGUN cannot contaminate the main codebase. 2. Ease of implementation with existing smart contracts and dApps due to less unnecessary bloat. Adapt Modules form the core of the RAILGUN SDK which is the flexible and powerful toolkit that allows developers to bring privacy to their applications. For developers, the fact that RAILGUN lives directly on-chain means that they do not have to refactor their existing code and deploy contracts on unproven networks with no liquidity. They can integrate RAILGUN with confidence that their dApps will be just as secure as before as the system is as secure as the main blockchain with no security tradeoffs. [PreviousUnshielding Tokenschevron-left](https://docs.railgun.org/wiki/learn/unshielding-tokens) [NextRAILGUN SDKschevron-right](https://docs.railgun.org/wiki/learn/integrating-railgun/railgun-sdks) Last updated 6 months ago Was this helpful? --- # Gasless Interactions | Wiki Another major innovation deployed by the RAILGUN system is the ability to send interactions without needing to spend the underlying blockchain’s gas currency. Through the power of Broadcasters and complex ZK circuits, users can interact with RAILGUN entirely in their currency of choice. For example, a user would not need to hold a small balance of ETH to submit gas for interactions on the Ethereum network and could instead choose to only hold and spend a stablecoin like DAI, with all associated gas being submitted in DAI. This is achieved through something called a “Meta Transaction”, a special form of Ethereum/blockchain transaction that is nested within another transaction. The gas fee can be paid in whatever asset the user specifies with the Broadcaster and nested transaction performing any conversion frictionlessly for the user. Like any other spend transactions, a Meta Transaction in RAILGUN calls the transact() function. [PreviousUsing Private Tokenschevron-left](https://docs.railgun.org/wiki/learn/using-private-tokens) [NextUnshielding Tokenschevron-right](https://docs.railgun.org/wiki/learn/unshielding-tokens) Last updated 1 year ago Was this helpful? --- # RAILGUN SDKs | Wiki The RAILGUN SDKs are written in TypeScript and come in 2 forms depending on the needs of any integrating dApps: * [RAILGUN Cookbookarrow-up-right](https://docs.railgun.org/developer-guide/cookbook/cookbook-overview) - Easily integrate RAILGUN into any existing dApp to enable private features such as private lending, private trading, private minting, etc. * ​[Wallet SDKarrow-up-right](https://docs.railgun.org/developer-guide/wallet/wallet-overview) – Toolkit to integrate RAILGUN as a private mode for wallets. [RAILGUN Cookbookarrow-up-right](https://docs.railgun.org/developer-guide/cookbook/cookbook-overview) is suitable for most dApp developers integrating RAILGUN. It enables users to call your public smart contract from a private 0zk address. Calls can also be linked together in "Recipes" such that users can combine multiple DeFi actions together in a single transaction. For example, a user might be able to go from stablecoins in a 0zk address to providing liquidity in a DEX and depositing that liquidity into a yield optimizer such as Beefy Finance, all in the same Cookbook Recipe. With Wallet SDK, developers can quickly and simply add RAILGUN privacy to their wallets to perform the following RAILGUN actions: * Generate private keys and 0zk addresses * Generate deposits into private balances * Scan interaction history and sync balances * Generate ZK proofs for withdrawals, to send interactions, and to initiate cross-contract calls The `generateDeposit()` and `transact()` functions are contained within the Wallet SDK and are callable by dApps once integrated. **Links:** Developer Guide - [https://docs.railgun.org/developer-guidearrow-up-right](https://docs.railgun.org/developer-guide) RAILGUN Cookbook GitHub: [https://github.com/Railgun-Community/cookbookarrow-up-right](https://github.com/Railgun-Community/cookbook) Wallet SDK GitHub - [https://github.com/Railgun-Community/quickstartarrow-up-right](https://github.com/Railgun-Community/quickstart) [PreviousIntegrating RAILGUNchevron-left](https://docs.railgun.org/wiki/learn/integrating-railgun) [NextAdapt Moduleschevron-right](https://docs.railgun.org/wiki/learn/integrating-railgun/adapt-modules) Last updated 6 months ago Was this helpful? --- # Adapt Modules | Wiki Adapt Modules are smart contract extensions separate from the main RAILGUN privacy system. They allow for extended functionality without impacting the main privacy system’s code. Adapt Modules require 2 fields, a contract address, and parameters to execute the contract. The parameters in Adapt Modules are not validated by the core RAILGUN code, which allows for them to be implemented with any custom logic, and arbitrarily across any smart contract. Any relevant proofs are only submittable from the specified contract, and they are only valid if they pass both the RAILGUN core protocol rules and the Adapt Module’s validation rules. Execution parameters are bound into the SNARK proof itself, such that the interaction is only valid if the parameters are met. ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FbY728eKZ8dImEs9cA6Ee%252Fimage.png%3Falt%3Dmedia%26token%3D600b7c24-8e53-4a2d-8906-e9529da7b4c3&width=768&dpr=3&quality=100&sign=fa22d4f0&sv=2) [PreviousRAILGUN SDKschevron-left](https://docs.railgun.org/wiki/learn/integrating-railgun/railgun-sdks) [NextExample - DEX Swapschevron-right](https://docs.railgun.org/wiki/learn/integrating-railgun/example-dex-swaps) Last updated 1 year ago Was this helpful? --- # Example - DEX Swaps | Wiki Independent RAILGUN-integrated wallets, [Railway Walletarrow-up-right](https://www.railway.xyz/) , [Terminal Walletarrow-up-right](https://terminal-wallet.com/) , and others have a built-in swap integration with the [0x API arrow-up-right](https://www.0x.org/) (the same tech as Matcha.xyz) to enable private DEX trading. Once the best trade route is found, the wallet generates a proof to extract the token that is being sold from the user’s private balance, then swaps them using the 0x API, and shields the resulting tokens back into the private balance. A swap of DAI into WETH through a private swap takes the following steps: 1. User starts the swap interaction on the RAILGUN integrated wallet and specifies the amount of WETH to swap. 2. [Adapt Modulearrow-up-right](https://docs.railgun.org/wiki/learn/integrating-railgun/adapt-modules) performs a contract multicall which executes the following actions: * a) Calls `transact()` to unshield DAI from the private balance. As previously stated, the `transact()` will verify that the UTXO has not been nullified and that the user has sufficient funds to execute the swap. * b) Swap from DAI into WETH is executed using the 0x API and Adapt Module, calling the 0x smart contract address and passing parameters to the contract. * c) Calls `shield()`to shield the WETH back into the private balance. If the price of WETH has gone down since the start of the interaction, then both WETH and any DAI leftover will be shielded into the private balance. 3. The contract Merkle Tree is updated with the new notes from `shield()`. As swaps performed through the Railway DEX call the `transact()`and `shield()` functions, the swap transaction also updates the events emitted by the respective functions: * `Transact` * `Shield` * `Nullifiers` As with all other interaction types on RAILGUN, to an outside observer, the interaction appears to originate from a Broadcaster address. As Step 2b has an external touchpoint outside of the RAILGUN system, the number of tokens swapped and the token type will be visible but as it does not interact with the user’s 0x address in any way, the user remains private, and no interactions are linked. This process gives RAILGUN users full privacy and executes an immediate swap against their RAILGUN balance without a rollup delay. The encrypted 0x API call is also much harder to front-run as it’s passed as a cross-contract call to the RAILGUN Relay-Adapt contract. Whilst it is still possible to front-run Railway DEX interactions through simulating the contract, it is markedly more difficult than reading the data fields in a standard DEX interaction. [PreviousAdapt Moduleschevron-left](https://docs.railgun.org/wiki/learn/integrating-railgun/adapt-modules) [NextRAILGUN Deductionschevron-right](https://docs.railgun.org/wiki/learn/railgun-deductions) Last updated 6 months ago Was this helpful? --- # RAILGUN Deductions | Wiki **Protocol Deductions** The smart contracts take a 0.25% deduction per shield and unshield interaction which is then sent to the “treasury address”. Protocol deductions are distributed to RAILGUN decentralized governance participants over time to RAIL stakers in the form of [Active Governor Allocation](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) . **Broadcaster Premiums** To use RAILGUN, users can supply a [Broadcasterarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers) to facilitate their interactions (users can self-relay interactions if they want to save on gas). Broadcasters require a % premium of the overall gas price for the interaction, but not for the interaction amount. Thus, Broadcaster Premiums do not increase with interaction size. As RAILGUN interactions are [gaslessarrow-up-right](https://docs.railgun.org/wiki/learn/using-shielded-tokens/gasless-transactions) (users do not need ETH/MATIC/BNB to send interactions once assets are shielded), broadcaster premiums contain the underlying blockchain's gas converted to whichever token that users are transacting in. For example, if you are sending DAI on the Ethereum blockchain, then the Broadcaster Premium (which also contains the blockchain interaction gas) is sent entirely in DAI and you do not need to hold/spend ETH in your 0zk address. Therefore, Broadcaster Premiums vary depending on: * Which chain you are using RAILGUN on * Gas price at the time of the interaction * What % of the gas Broadcasters decide to require as an additional premium Premiums are broadcast across the [Waku P2P networkarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers) and are only needed if users decide to send the interaction and consider the premium & gas to be acceptable. Broadcaster Premiums are up to the individual Broadcasters themselves, but generally they are ~10% of the total gas. Broadcasters compete to provide the lowest premiums. [PreviousExample - DEX Swapschevron-left](https://docs.railgun.org/wiki/learn/integrating-railgun/example-dex-swaps) [NextHelpful Linkschevron-right](https://docs.railgun.org/wiki/learn/helpful-links) Last updated 22 days ago Was this helpful? --- # Unshielding Tokens | Wiki Unshielding is the process where funds are withdrawn from the RAILGUN privacy system to a public 0x address. Users can withdraw tokens out of RAILGUN by initiating an unshield interaction and inputting any 0x address. Under the hood, withdrawals are identical to a regular private send interaction in that they call the transact() function. The only difference is that the zk-SNARK circuit outputs for withdrawals are unencrypted, and they contain a check to establish whether the interaction is flagged as a withdrawal or not. The check is contained in the unshield parameter. If unshield is non-zero, the transaction is confirmed as an unshield interaction, and the smart contract will check whether the hashed note matches the transaction hash output. If all the inputs pass the ZK proof, the tokens are then sent to the unshield address, which is a public 0x address selected by the user. [PreviousGasless Interactionschevron-left](https://docs.railgun.org/wiki/learn/using-private-tokens/gasless-interactions) [NextIntegrating RAILGUNchevron-right](https://docs.railgun.org/wiki/learn/integrating-railgun) Last updated 6 months ago Was this helpful? --- # Helpful Links | Wiki **Website**: [https://railgun.org/arrow-up-right](https://railgun.org/) **Developer Guide**: [https://docs.railgun.org/developer-guide/wallet/wallet-overviewarrow-up-right](https://docs.railgun.org/developer-guide/wallet/wallet-overview) **Railway Wallet** (partner project): [https://www.railway.xyz/arrow-up-right](https://railway.xyz/) **Twitter**: [https://twitter.com/railgun\_projectarrow-up-right](https://twitter.com/railgun_project) **Medium**: [https://medium.com/@Railgun\_Projectarrow-up-right](https://medium.com/@Railgun_Project/) **Github**: [https://github.com/railgun-communityarrow-up-right](https://github.com/railgun-community) **Telegram Channels**: [https://t.me/railgun\_privacyarrow-up-right](https://t.me/railgun_privacy) , [https://t.me/railpricearrow-up-right](https://t.me/railprice) , [https://t.me/Railgunprojectarrow-up-right](https://t.me/Railgunproject) , [https://t.me/railwaywalletarrow-up-right](https://t.me/railwaywallet) **OTC Telegram Chats**: [https://t.me/railpolyarrow-up-right](https://t.me/railpoly) , [https://t.me/railbscarrow-up-right](https://t.me/railbsc) [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#privacy-system-contracts) Privacy System Contracts ------------------------------------------------------------------------------------------------------------------- #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#eth-deployment) **ETH Deployment**: [https://etherscan.io/address/0xfa7093cdd9ee6932b4eb2c9e1cde7ce00b1fa4b9arrow-up-right](https://etherscan.io/address/0xfa7093cdd9ee6932b4eb2c9e1cde7ce00b1fa4b9) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#polygon-deployment) **Polygon Deployment**: #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#https-polygonscan.com-address-0x19b620929f97b7b990801496c3b361ca5def8c71) [https://polygonscan.com/address/0x19b620929f97b7b990801496c3b361ca5def8c71arrow-up-right](https://polygonscan.com/address/0x19b620929f97b7b990801496c3b361ca5def8c71) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#bsc-deployment) **BSC Deployment**: [https://bscscan.com/address/0x590162bf4b50f6576a459b75309ee21d92178a10arrow-up-right](https://bscscan.com/address/0x590162bf4b50f6576a459b75309ee21d92178a10) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#arbitrum-deployment) **Arbitrum Deployment:** [https://arbiscan.io/address/0xFA7093CDD9EE6932B4eb2c9e1cde7CE00B1FA4b9arrow-up-right](https://arbiscan.io/address/0xFA7093CDD9EE6932B4eb2c9e1cde7CE00B1FA4b9) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#sepolia-testnet) Sepolia Testnet [https://sepolia.etherscan.io/address/0xecfcf3b4ec647c4ca6d49108b311b7a7c9543feaarrow-up-right](https://sepolia.etherscan.io/address/0xecfcf3b4ec647c4ca6d49108b311b7a7c9543fea) [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#treasury) Treasury ----------------------------------------------------------------------------------- #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#eth) **ETH**: [https://etherscan.io/address/0xE8A8B458BcD1Ececc6b6b58F80929b29cCecFF40arrow-up-right](https://etherscan.io/address/0xE8A8B458BcD1Ececc6b6b58F80929b29cCecFF40) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#polygon) **Polygon**: [https://polygonscan.com/address/0xdca05161ee5b5fa6df170191c88857e70ffb4094 arrow-up-right](https://polygonscan.com/address/0xdca05161ee5b5fa6df170191c88857e70ffb4094) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#bsc) **BSC**: [https://bscscan.com/address/0xdca05161eE5b5FA6DF170191c88857E70FFB4094arrow-up-right](https://bscscan.com/address/0xdca05161eE5b5FA6DF170191c88857E70FFB4094) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#arbitrum-treasury) **Arbitrum Treasury:** [https://arbiscan.io/address/0x3b374464a714525498e445ba050b91571937bfc8arrow-up-right](https://arbiscan.io/address/0x3b374464a714525498e445ba050b91571937bfc8) [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#governance) Governance --------------------------------------------------------------------------------------- #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#ethereum) Ethereum: [https://etherscan.io/address/0xc480f68a3dcc3edd82134fab45c14a0fcf1da3ccarrow-up-right](https://etherscan.io/address/0xc480f68a3dcc3edd82134fab45c14a0fcf1da3cc) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#polygon-1) Polygon: [https://polygonscan.com/address/0xc3f2c8f9d5f0705de706b1302b7a039e1e11ac88arrow-up-right](https://polygonscan.com/address/0xc3f2c8f9d5f0705de706b1302b7a039e1e11ac88) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#bsc-1) BSC: [https://bscscan.com/address/0xc3f2c8f9d5f0705de706b1302b7a039e1e11ac88arrow-up-right](https://bscscan.com/address/0xc3f2c8f9d5f0705de706b1302b7a039e1e11ac88) [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#rewards) Rewards --------------------------------------------------------------------------------- #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#ethereum-1) Ethereum: [https://etherscan.io/address/0xa02782ce1bf85f56f8cc7c0e66e61299ac75c86farrow-up-right](https://etherscan.io/address/0xa02782ce1bf85f56f8cc7c0e66e61299ac75c86f) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#polygon-2) Polygon: [https://polygonscan.com/address/0x25f795A8eC8aF7904aa403fF2Cc7205ce683BF52arrow-up-right](https://polygonscan.com/address/0x25f795A8eC8aF7904aa403fF2Cc7205ce683BF52) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#bsc-2) BSC: [https://bscscan.com/address/0xa7A9582C2563a1b923dbff6a8A2fa625ee2FB1f8arrow-up-right](https://bscscan.com/address/0xa7A9582C2563a1b923dbff6a8A2fa625ee2FB1f8) [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#staking) Staking --------------------------------------------------------------------------------- #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#ethereum-2) Ethereum: [https://etherscan.io/address/0xee6a649aa3766bd117e12c161726b693a1b2ee20arrow-up-right](https://etherscan.io/address/0xee6a649aa3766bd117e12c161726b693a1b2ee20) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#polygon-3) Polygon: [https://polygonscan.com/address/0x9AC2bA4bf7FaCB0bbB33447e5fF8f8D63B71dDC1arrow-up-right](https://polygonscan.com/address/0x9AC2bA4bf7FaCB0bbB33447e5fF8f8D63B71dDC1) #### [hashtag](https://docs.railgun.org/wiki/learn/helpful-links#bsc-3) BSC: [https://bscscan.com/address/0x753f0f9ba003dda95eb9284533cf5b0f19e441dcarrow-up-right](https://bscscan.com/address/0x753f0f9ba003dda95eb9284533cf5b0f19e441dc) [PreviousRAILGUN Deductionschevron-left](https://docs.railgun.org/wiki/learn/railgun-deductions) [NextPrivate Proofs of Innocencechevron-right](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence) Last updated 5 months ago Was this helpful? --- # RAILGUN Assurance Suite | Wiki RAILGUN has 3 main tools for auditability and assurance: * [Viewing Keys](https://docs.railgun.org/wiki/learn/wallets-and-keys#viewing-keys) : Shareable read-only private key for auditability or investigatory purposes * [Private proofs of Innocence (PPOI)](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence) : a Zero-Knowledge assurance tool that checks that tokens moving through RAILGUN do not originate from a known list of malicious activity. This is achieved via the use of cryptographic proofs, which keeps RAILGUN users’ data private. * [Koinly Tax Exports](https://docs.railgun.org/wiki/assurance/koinly-tax-exports) : Easy file exports for use in the Koinly tax software [PreviousPrivate Proofs of Innocencechevron-left](https://docs.railgun.org/wiki/assurance/private-proofs-of-innocence) [NextKoinly Tax Exportschevron-right](https://docs.railgun.org/wiki/assurance/koinly-tax-exports) Last updated 10 months ago Was this helpful? --- # Koinly Tax Exports | Wiki RAILGUN users can also easily export their interaction history for use in the [Koinlyarrow-up-right](https://koinly.io/) tax software. This optional tool might be useful if users want to calculate their tax obligations of their private interactions using Koinly. Koinly also supports multiple tax jurisdictions. Partner project Railway Wallet have produced a [quick guidearrow-up-right](https://help.railway.xyz/customize/koinly-tax-reports) on how to access Koinly tax reports on their wallet. [PreviousRAILGUN Assurance Suitechevron-left](https://docs.railgun.org/wiki/assurance/railgun-assurance-suite) [NextRAIL Token Overviewchevron-right](https://docs.railgun.org/wiki/rail-token/rail-token-overview) Last updated 1 year ago Was this helpful? --- # RAIL Token Overview | Wiki RAIL is RAILGUN’s governance token. Holding RAIL is not necessary to use the privacy system nor is RAIL a privacy token. RAIL is a standard ERC-20 token deployed to Ethereum. RAIL liquidity can be found on Sushiswap and Uniswap, with aggregated routing available through [Matcha.arrow-up-right](https://matcha.xyz/) ​ ​[Stake RAILarrow-up-right](https://governance.railgun.org/) to vote on governance proposals. RAILGUN on Polygon and BSC have their own independent governance systems & tokens which are separate from the system on Ethereum. There is currently very little liquidity for RAILPOLY and RAILBSC. RAILGUN on Arbitrum is governed by the system on Ethereum and thus voting power accrues to the Ethereum RAIL token. ### [hashtag](https://docs.railgun.org/wiki/rail-token/rail-token-overview#contract-addresses) Contract Addresses **Ethereum - RAIL**: 0xe76c6c83af64e4c60245d8c7de953df673a7a33d **BNB Smart Chain - RAILBSC:** 0x3F847b01d4d498a293e3197B186356039eCd737F **Polygon - RAILPOLY:** 0x92A9C92C215092720C731c96D4Ff508c831a714f [PreviousKoinly Tax Exportschevron-left](https://docs.railgun.org/wiki/assurance/koinly-tax-exports) [NextRAIL Active Governor Allocationchevron-right](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) Last updated 6 months ago Was this helpful? --- # RAIL Active Governor Allocation | Wiki RAIL stakers can become Active Governors. To be an Active Governor, stakers must: 1. Have RAIL fully locked (at least some portion that is not going through the unlock period). 2. View the Governance Portal at least once and check for any ongoing proposals. 3. Submit gas to claim allocation. 4. Not delegate their vote to a different address. If votes are delegated, the address that is delegated to will receive the allocation. Active Governors receive a portion of protocol [deductionsarrow-up-right](https://docs.railgun.org/wiki/learn/railgun-fees) as an incentive for participation in governance. This is because anyone can propose any code changes to the protocol at any time, and widespread participation in governance protects the integrity of the protocol. **2% of the treasury tokens are allocated to the claiming mechanism every 2 weeks. This means that every year, ~52% of the treasury tokens are allocated to Active Governors.** Tokens are allocated in WETH (or WBNB/WMATIC for other chains), RAIL, and DAI. Active Governors can claim their tokens (a transaction which requires gas) on whichever chain their RAIL is locked. Further, Active Governors can only claim tokens from chains where they have RAIL locked. RAILGUN Active Governors receive an allocation proportionate to the amount of RAIL they have locked in the governance contract. For example, if a user's locked share of RAIL is 1% of all staked RAIL, then the user can collect 1% of the 2% biweekly allocation. [PreviousRAIL Token Overviewchevron-left](https://docs.railgun.org/wiki/rail-token/rail-token-overview) [NextRAIL Tokenomicschevron-right](https://docs.railgun.org/wiki/rail-token/rail-tokenomics) Last updated 6 months ago Was this helpful? --- # RAIL Tokenomics | Wiki **Maximum Supply** * 100,000,000 (RAIL on Ethereum) * 44,546,789 (RAILBSC on BNB Smart Chain) * 55,000,000 (RAILPOLY on Polygon) **RAILPOLY & RAILBSC** RAILGUN on Polygon and BSC have their own separate governance systems and therefore have their own chain-specific tokens. RAIL (on Ethereum), RAILPOLY and RAILBSC are different to each other as they govern the RAILGUN deployment on their respective chains. RAILPOLY and RAILBSC were distributed via airdrops to RAIL stakers and RAIL liquidity providers. * [RAILPOLY Airdrop Detailsarrow-up-right](https://medium.com/@Railgun_Project/railpoly-launch-and-token-airdrop-fded511a0ce2) * [RAILBSC Airdrop Detailsarrow-up-right](https://medium.com/@Railgun_Project/snapshots-and-airdrops-6b87572a957e) [PreviousRAIL Active Governor Allocationchevron-left](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) [NextHow to Lock RAILchevron-right](https://docs.railgun.org/wiki/rail-token/how-to-stake-rail-tokens) Last updated 6 months ago Was this helpful? --- # How to Lock RAIL | Wiki Lock RAIL in the governance contract to collect Active Governors Allocations, vote on proposals, or delegate your voting power. Once locked, there is a 30 day unlock period, during which there is no voting power, nor will the ability to collect Allocations. This constitutes a proof of commitment mechanism. Steps to lock RAIL: 1. Purchase/hold RAIL in a self-custodial EVM/Ethereum wallet 2. Head to the locking portal: [governance.railgun.orgarrow-up-right](https://governance.railgun.org/) 3. Connect your wallet 4. Enter the amount you wish to lock and press "Stake" 5. Once locked, you can visit [governance.railgun.org/proposalsarrow-up-right](https://governance.railgun.org/proposals) to vote on active proposals, or press the "Delegate" button to delegate your voting power to another wallet. [PreviousRAIL Tokenomicschevron-left](https://docs.railgun.org/wiki/rail-token/rail-tokenomics) [NextDecentralized Governancechevron-right](https://docs.railgun.org/wiki/rail-token/protocol-governance) Last updated 6 months ago Was this helpful? --- # Decentralized Governance | Wiki ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FgDnIGje0G8GDiXF2srcv%252Fimage.png%3Falt%3Dmedia%26token%3Dac850db4-429f-4c43-9251-c8c84c275c6a&width=768&dpr=3&quality=100&sign=5ecc1887&sv=2) [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#id-1c2c) **How does governance work?** ------------------------------------------------------------------------------------------------------------------ RAILGUN governance is decentralized, any wallet that locks RAIL can vote on and submit proposals to vote. For all governance stages, 1 RAIL locked is equal to 1 vote, snapshots of voting power are taken at each governance stage. Votes can also be delegated to another wallet, however the associated [Active Governor Allocations](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) will be accrued by the wallet to which votes are delegated. Proposals come in the form of code changes to the smart contracts and anyone with enough technical expertise can write and submit code. Decision making rests with the community of Active Governors who vote on whether or not to accept proposed changes. Once approved, proposals are executed on chain. Any change to the smart contracts (including the governance, treasury, and voting contracts) requires the passing of an on-chain proposal. The decentralized governance system is the only way in which upgrades to the RAILGUN protocol can be made. [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#ed33) **Potential Governance Topics** ----------------------------------------------------------------------------------------------------------------- There are no subject matter limitations on the decentralized governance system and every Active Governor is entitled to submit a proposal on any code changes. For example: * Protocol upgrades to the smart contracts * Deploying RAILGUN on additional blockchains that allow for smart contracts * Protocol deductions * Distributing treasury tokens [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#a48e) **Governance stages** ------------------------------------------------------------------------------------------------------- ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#proposal-initiation) **Proposal Initiation** Governance begins with a proposal being written up containing: * Title * Document * Description * Code actions to execute The proposer must pay a small gas fee to submit a proposal in order to prevent spam. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#sponsorship) **Sponsorship** After submission, a 30-day Sponsorship Period begins where the proposal must reach 500,000 sponsorship votes to go to vote. Sponsoring a proposal does not reduce the amount of RAIL voting power. Votes are counted on a daily snapshot basis. To prevent proposal spam, stakers can only sponsor 1 proposal every 7 days. If a proposal does not reach the required 500,000 sponsorship votes within the 30-day window, it has failed. Sponsorship is a period that enables the decentralised community to properly analyse any proposal’s value, feasibility and solidity, by engaging the full spirit of open-source, whilst filtering out unusual or unpopular proposals without needing a full quorum. This period and its structure also ensure that proposals that pass result in the best outcomes. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#call-to-vote) **Call to Vote** If a proposal reaches 500,000 sponsorship votes, then a community member must call it to vote by executing an interaction on-chain. This must be done within 30-days of the proposal going live or the proposal will become stale and unable to be executed. Any wallet can call a vote, even one without staked RAIL. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#review) **Review** Sponsored proposals called to vote are held for 2 days to give the community more than enough time to review and discuss before voting commences. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#vote) **Vote** At this stage, voting is open and Active Governors can vote "Yes" or "No" for 3 days. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#veto) **Veto** After 3 days, there is a 1 day veto period where the only voting option is "No". This is an additional filter to ensure that the community as a whole is aligned in enacting the changes. A minimum of 2 million votes must be cast to achieve quorum. "No" votes do not count to quorum. If quorum is reached and there are more "Yes" votes than "No", the proposal is passed. ### [hashtag](https://docs.railgun.org/wiki/rail-token/protocol-governance#execution) **Execution** 1 day after the voting period ends, a week-long Execution Window opens. For the proposal to take effect, any wallet can call the execution. This must be done within 7-days from the end of the veto period or the proposal will become stale and unable to be executed. This can only be done without revealing their identity. Executing a proposal initiates the smart contract functions from the proposal. If there are errors in the code, then no changes will occur, and the proposal will need to be rewritten and resubmitted. [PreviousHow to Lock RAILchevron-left](https://docs.railgun.org/wiki/rail-token/how-to-stake-rail-tokens) Last updated 6 months ago Was this helpful? --- # Overview | Wiki ![Page cover](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FNjmkxKYP9z0w2ZC17mYq%252FWiki%2520banner%2520%283%29.png%3Falt%3Dmedia%26token%3D8d652614-1ac7-430d-ad34-944c24ada28b&width=1248&dpr=3&quality=100&sign=92827e9e&sv=2) [hashtag](https://docs.railgun.org/wiki/learn#what-is-railgun) What is RAILGUN? ------------------------------------------------------------------------------------ RAILGUN is code that exists on every Ethereum node. It's a privacy system built directly on-chain for Ethereum, BSC, Polygon, and Arbitrum. It uses Zero-Knowledge (ZK) cryptography to enable private use of smart contracts and DeFi, all without leaving the security of the user’s preferred chain. The RAILGUN code has no owner. Interactions on your chain of choice are made private. The RAIL token is purely a governance token and is not a privacy coin. Holding RAIL is not necessary to use the protocol and it does not confer any rights to holders. You can read more about governance [here](https://docs.railgun.org/wiki/rail-token/protocol-governance) . RAILGUN users have access to a special 0zk address that are confidential on Etherscan, Arbiscan, or any similar resource. Independent wallet providers can use the RAILGUN protocol, head [herearrow-up-right](https://railgun.org/wallets) to select from a list of wallet providers. RAILGUN is 100% non-custodial. The user experience is similar to using a public wallet to interact with Ethereum/EVM chains, just with the added ability to interact privately. As RAILGUN is simply on-chain smart contract code, privacy is achieved without the need to move to a separate chain. This provides 2 main advantages: 1. **Security & Decentralization** - No centralized control, no extra validators, and no trusted bridges. 2. **Full Ecosystem** - Rather than an isolated ecosystem on a standalone privacy chain, RAILGUN users have full access to all the economic activity and functions that the chain provides, and benefit from the rich history of existing dApps and builders. RAILGUN has 2 main components: 1. **RAILGUN-Integrated Wallets** - EVM wallets built by separate independent community developers through which users can use the RAILGUN protocol. A list can be found [herearrow-up-right](https://railgun.org/wallets) . 2. **Developer Tools** – includes TypeScript SDKs for building RAILGUN privacy into existing/new wallets or a privacy enabled dApp. Head to the [developer guidearrow-up-right](https://docs.railgun.org/developer-guide) to start building with RAILGUN. RAILGUN’s code is verified and publicly viewable, and its repository can be found [here.arrow-up-right](https://github.com/Railgun-Community) [hashtag](https://docs.railgun.org/wiki/learn#benefits-and-use-cases-of-railgun) Benefits and use cases of RAILGUN ----------------------------------------------------------------------------------------------------------------------- ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252Ft7FMVUqCN90NdQTskJuf%252Frailgun_flowchart_-02.png%3Falt%3Dmedia%26token%3D521dfa7b-0746-4d5c-a9ef-b32ef1d690b0&width=768&dpr=3&quality=100&sign=ffff7492&sv=2) As the diagram shows, looking from the outside in, when tokens are moved into RAILGUN’s smart contract, tokens and wallets become indistinguishable from one another without mixing one user's funds with another. Because of this, all transferring, swapping, lending, borrowing, and dApp calls create more noise and improve privacy for every other user. These DeFi interactions allow RAILGUN to function more privately than other protocols with a similar amount of tokens and users. Read [this articlearrow-up-right](https://medium.com/@Railgun_Project/what-is-crypto-privacy-how-railgun-can-help-7-privacy-tips-for-dank-degens-cce294c6fc70) for more on how privacy works in the RAILGUN protocol. Due to the availability of DeFi transactions, more rigorous privacy is achieved with RAILGUN with less liquidity and in a shorter timeframe than with other privacy systems. Arbitrary dApp interactions within RAILGUN’s privacy system also incentivizes users to hold their tokens for longer in RAILGUN as there is less reason to move tokens out of RAILGUN. Potential use cases: 1. **Alpha Protection:** Traders who want to keep their alpha confidential can trade freely and maintain their informational advantages. RAILGUN’s privacy system enables users to trade with reduced risk of hard-fought trading strategies and patterns being discovered and ripped off by freeloading actors, who can obtain such data on-chain by tracing interactions, then running them through analysis software to reverse engineer said strategies, without doing any of the actual work. 2. **Compliance with Law:** Businesses and professionals must use privacy tools, such as RAILGUN, to make sure that financial data is not leaked when interacting with clients. Lawyers, doctors, and psychologists, for example, are not allowed to reveal that their clients have paid for advice. They must protect the identity of the person engaging their services, as set out in common law, professional rules of conduct, European and British GDPR, the USA’s HIPAA, and other data protection legislation. Other businesses and professionals also have strict laws that apply to them to protect the financial information of their customers & staff. RAILGUN is used to comply with these laws. 3. **Private Payroll:** The privacy features of RAILGUN are needed for payroll services, when companies pay in cryptocurrency. 4. **Donation Privacy:** RAILGUN users can donate to charitable causes using cryptocurrency without needing to publicly reveal their link to these causes. 5. **Personal Protection:** RAILGUN users are not exposed on services like Nansen or Etherscan, where notable wallets are labelled or known. Any cryptocurrency user who wishes to protect their personal privacy can do so using RAILGUN. RAILGUN is a revolutionary toolkit and is objectively the most uncompromising privacy solution for DeFi. Private DeFi will enable new business possibilities for the cryptocurrency industry that are not possible on public blockchains. All other privacy solutions have some trade-offs, such as requiring users to trust custodial bridges or trade with fragmented/non-existent liquidity. ### [hashtag](https://docs.railgun.org/wiki/learn#developer-guide) Developer Guide If you're a developer looking for the SDK documentation. [You can find it herearrow-up-right](https://docs.railgun.org/developer-guide) . [NextGetting Startedchevron-right](https://docs.railgun.org/wiki/learn/getting-started) Last updated 12 days ago Was this helpful? --- # Private Proofs of Innocence | Wiki ### [hashtag](https://docs.railgun.org/wiki/assurance#overview) Overview Private Proofs of Innocence is a decentralized bad transaction prevention system built by zero-knowledge (ZK) cryptography researchers. It is an independent partner project to the RAILGUN Project. Anyone can see Private POI in action at [ppoi.infoarrow-up-right](https://ppoi.info/) by entering a RAILGUN transaction hash. Private Proofs of Innocence List Providers: * [Ellipticarrow-up-right](https://www.elliptic.co/) * [ScamSnifferarrow-up-right](https://www.scamsniffer.io/) * [PureFiarrow-up-right](https://purefi.io/) * [SlowMistarrow-up-right](https://www.slowmist.com/) * [Chainalysis Sanctions Oraclearrow-up-right](https://go.chainalysis.com/chainalysis-oracle-docs.html) Private Proofs of Innocence is a tool that monitors tokens entering the RAILGUN smart contract to verify that they are not from a known list of transactions or actors deemed to be illegitimate. Upon a shield, a ZK proof is automatically created that proves that the tokens are not a part of a pre-set list of interactions and wallets. This process is end-to-end encrypted and enables decentralized and private assurance of tokens, without compromising user privacy. Private Proofs of Innocence sits alongside (but is separate from) the RAILGUN smart contracts, and is also open-source infrastructure that can be used by other protocols. Private Proofs of Innocence uses only publicly available data and does not reveal anything else about RAILGUN users or their balances and activity, nor does it give any third party any access into the RAILGUN privacy system. It also does not erode the privacy of using RAILGUN nor does it change how the underlying smart contracts’ spending system works; all interactions from 0zk addresses are and always will be impossible to be made public by anyone. Because of this, Private Proofs of Innocence is a superior detection tool to previously existing methods, and is an advancement in both ZK and privacy technology. Legacy bad actor detection tools requires users to give up some personal data like identity documents to a centralized middleman or firm stored in a centralized data lake, exposing personal information to potential vulnerabilities. Private Proofs of Innocence achieves similar aims to a similar level of effectiveness whilst only using public on-chain data, all whilst requiring no personal information. Private Proofs of Innocence protects all RAILGUN users in the following ways: * Users can feel comfortable that they are not sharing a privacy system with known bad actors, which reduces risks for every single RAILGUN user. * Exchanges or other external participants can gain confidence on interactions that they receive from RAILGUN users, ensuring smoother processing and a reduction of wait times. * Users can be sure that private sends they receive from other RAILGUN users are safe and not from known suspicious activity. * Flexible input data which can be adjusted to the user’s risk profile and local jurisdiction, i.e., European users can pick lists relevant to the European Union or United States users can pick lists relevant to the USA etc. ### [hashtag](https://docs.railgun.org/wiki/assurance#how-it-works) How it works ![](https://docs.railgun.org/wiki/~gitbook/image?url=https%3A%2F%2F4189133001-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MgpI5FGDnzf3cR6tzx7%252Fuploads%252FbquX783aE4MvMOjLK4d2%252Fimage.png%3Falt%3Dmedia%26token%3Db480e4b9-0786-4188-b7b4-7815e1336cd4&width=768&dpr=3&quality=100&sign=7aa82f7f&sv=2) Private Proofs of Innocence Architecture Private Proofs of Innocence checks begin when tokens enter the RAILGUN privacy system after a shield interaction. Broadly, the steps are as follows: 1. List Providers input public, non-personal, and on-chain data of bad transactions 2. User performs a shield interaction, and waits for the Unshield-Only Standby Period 3. A blinded proof is auto-generated stating that the tokens in the shield are not a part of the List Provider dataset 4. Private Proofs of Innocence checks are then carried forward for any subsequent interactions involving the checked tokens 5. If those tokens are sent to an external exchange, that exchange (or any independent party) can see the valid Private POI proof without seeing anything else about the user like their 0zk address, balances, or history. This helps external actors gain confidence on tokens they receive from a RAILGUN address without affecting user privacy in any way. #### [hashtag](https://docs.railgun.org/wiki/assurance#unshield-only-standby-period) Unshield-Only Standby Period With Private Proofs of Innocence, there is an Unshield-Only Standby Period, during which the only available action will be an unshield interaction to return tokens back to the original wallet. This Unshield-Only Standby Period is to give List Providers enough time to update their data such that bad actors are unable to hop addresses quickly to outrun data updates. As always, during this Unshield-Only Standby Period, users retain full control and custody over their tokens and can be unshielded back to the shielding address if needed urgently. To begin with, in the wallet applications that support Private Proofs of Innocence, this Unshield-Only Standby Period will be 1 hour, meaning tokens in new shields will have to wait 1 hour before they can be used in further interactions other than reverting out without privacy back to the original address. #### [hashtag](https://docs.railgun.org/wiki/assurance#transaction-level-checks) Transaction Level Checks Private Proofs of Innocence works at the balance and transaction level. Meaning, Private Proofs of Innocence proofs are generated after the initial shield transaction and apply to the tokens that are a part of that interaction. They are then carried forward for every following transaction within RAILGUN involving those tokens. For example: 1. Alice sends 100 USDC into a 0zk address and generates a Private POI proof which applies to that 100 USDC. In this example, she is using AliceWallet; one wallet option of many that features RAILGUN privacy options and Private POI. 2. She then sends that 100 USDC to Bob, who can use Alice’s existing Private POI proof to show that the funds he received from Alice are not a part of the list of illicit activity. 3. Bob then sends that 100 USDC to a 0x wallet owned by Carl. All Carl knows is that the 100 USDC he received has a valid Private POI proof. As it is a RAILGUN interaction, he does not know anything else about Alice and Bob’s on-chain activity other than what they choose to tell him personally. He would not even know that the tokens were from Bob’s 0zk address is not revealed unless Bob chooses to tell him. 4. Alice then sends an additional 50 USDC which generates another Private POI proof that applies to that shield of 50 USDC. #### [hashtag](https://docs.railgun.org/wiki/assurance#list-providers) List Providers Private Proofs of Innocence starts with a List Provider, a dataset of transactions and addresses through an API (Application Programming Interface) of which to prove against (i.e., a list of bad actor activity for users to ZK prove that they are not a part of). Anyone can choose to publish their own lists and be a List Provider. Users and wallets are free to use whatever combination of List Providers they please, although some wallet providers will require a default List Provider. The ZK-cryptography generates an independent proof per Private Proofs of Innocence List Provider, which is verified and made available for further usage, without revealing any of the encrypted details of the interaction or the user. **Note: List Providers only look at publicly available data and gain no special insight into transactions. Private Proofs of Innocence does not affect privacy levels in the RAILGUN privacy system. All data relating to 0zk addresses (including balances, history, and addresses) are and always will be encrypted to everyone.** List Providers are a read-only data source. Wallets do not send any data from Private POI or proofs to List Providers, and they cannot log IP addresses. **Private Proofs of Innocence Nodes** Private Proofs of Innocence Nodes sync proof data and make it available for anyone interested in verifying Private Proofs of Innocence checks. To prevent spam from being submitted, proof data is synced in a manner similar to the Interplanetary File System (IPFS), a decentralized data storage network. Wallets create proofs with encrypted data and update a shared list through Private Proofs of Innocence Nodes. Only the sending and receiving parties can decrypt this data, so no other party gets any information about what interactions they are linked to or what interactions are proved, ensuring complete privacy. Since unshield interactions have a public recipient, anyone can check if an unshield interaction is proved (and thereby knowing that it has a series of private proofs to a shield that is not on the bad transaction list), but they cannot see into the transaction other than that it was validly proved to not be from a publicly known set of bad transactions. This enables RAILGUN-integrated wallets, centralized exchanges, or anyone needing to verify that a shield has a Private Proofs of Innocence. Again, there is no special insight for Private Proofs of Innocence nodes. Like IPFS, anyone can run a Private Proofs of Innocence node. This ensures decentralized verification of Private Proofs of Innocence data such that every participant in the system can check proof validity for themselves rather than relying on a centralized actor. #### [hashtag](https://docs.railgun.org/wiki/assurance#broadcasters) Broadcasters As 0zk addresses cannot broadcast transactions or submit gas to Ethereum nodes they need a broadcasting wallet. Public Broadcasters broadcast interactions to the network and submit the necessary gas. They receive a RAILGUN private send at the same time to recover their costs, which is done in a private transaction. Before Broadcasters can do this with any given set of tokens, those tokens must have a completed Private Proofs of Innocence check. Broadcasters have Private Proofs of Innocence nodes which sync and verifies proof data. In cases where there is an incomplete Private Proofs of Innocence check for a series of tokens (such as during the Unshield-Only Standby Period), users can Self-Broadcast a transaction to return tokens back to the original shielder. **Full Transaction Private Proofs of Innocence Flow** The following is an example of how RAILGUN private transactions flow following completed Private Proofs of Innocence after an initial shield: 1. Bob's tokens begin with a Private POI, either from a shield or a 0zk-0zk transfer. This will be generated automatically by the sender's wallet, designating Bob's funds as "Spendable." In the case of a shield, the Private POI proof will be automatically generated by each List based on public on-chain data. 2. Bob proves a transaction to send DAI to Alice through a Broadcaster. As part of the proof, Bob generates a special Proof of Spendability, which verifies the Private Proofs of Innocence proof for the Broadcaster, and guarantees that the received premium will be verified and spendable. 3. Bob sends the transaction through the Broadcaster and waits for it to be forwarded and confirmed by the blockchain. 4. Once confirmed, Bob's wallet automatically generates a Private POI proof for a blinded hash of the UTXO commitment that he sent to Alice. The POI data is validated by POI nodes, which make the blinded data available publicly. 5. Alice's wallet inherits the Private Proof of Innocence, based on the blinded commitment that only her viewing key could decrypt. This automatically designates her tokens as Spendable, for transfers, unshields or swaps & DeFi dApps, without her needing to generate her own Privte POI proof. This ensures that the Private Proofs of Innocence system is efficient, as proofs need to only occur once within the RAILGUN system for each shield interaction, even if those tokens are then spent by the initial shielding user. The only case where an additional Private Proofs of Innocence proof is needed is if the tokens are sent out of a 0zk address and the user reuses them in RAILGUN. ### [hashtag](https://docs.railgun.org/wiki/assurance#zk-cryptography) ZK Cryptography Private Proofs of Innocence works with existing RAILGUN ZK cryptographic systems. Each RAILGUN 0zk balance is comprised of a set of encrypted [UTXOsarrow-up-right](https://docs.railgun.org/wiki/learn/using-shielded-tokens#utxos-and-nullifiers) organized via a private [Merkle Treearrow-up-right](https://docs.railgun.org/wiki/learn/shielding-tokens#private-pools-and-merkle-trees) . Every RAILGUN transaction, such as a Private Send, generates a ZK proof (through [cryptographic circuitsarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/zero-knowledge-cryptography#what-is-a-circuit) ) verifying that the sender has sufficient UTXOs in their balance to send the transaction. If the balance is enough for the transaction, then it is valid and the Merkle Tree updates with the new change in balance and state. This is how RAILGUN internal balances are maintained. As Private Proofs of Innocence sits alongside the RAILGUN smart contracts, it does not affect this Merkle Tree-based spending system in any way. Instead, it enables users to generate an additional recursive proof, which is a proof that the underlying proofs of a user’s balance are not a part of the bad transaction list. As RAILGUN allows for intermediate 0zk balance transfers between shield and unshield interactions and each of these interactions is itself a proof, Private Proofs of Innocence has a recursion mechanism to assert further statements about these existing proofs. Recursive SNARKs can prove the entire flow of funds from the initial shield interaction satisfies the conditions of the Merkle proof of non-inclusion. Private Proofs of Innocence will compute proofs for every leaf in the regular Merkle Tree that apply to a balance of UTXOs and account for intermediate interactions between shield and unshield interactions. This is done through recursive SNARKs which tie the whole proving system together. [PreviousHelpful Linkschevron-left](https://docs.railgun.org/wiki/learn/helpful-links) [NextRAILGUN Assurance Suitechevron-right](https://docs.railgun.org/wiki/assurance/railgun-assurance-suite) Last updated 12 days ago Was this helpful? --- # RAIL Token Overview | Wiki RAIL is RAILGUN’s governance token. Holding RAIL is not necessary to use the privacy system nor is RAIL a privacy token. RAIL is a standard ERC-20 token deployed to Ethereum. RAIL liquidity can be found on Sushiswap and Uniswap, with aggregated routing available through [Matcha.arrow-up-right](https://matcha.xyz/) ​ ​[Stake RAILarrow-up-right](https://governance.railgun.org/) to vote on governance proposals. RAILGUN on Polygon and BSC have their own independent governance systems & tokens which are separate from the system on Ethereum. There is currently very little liquidity for RAILPOLY and RAILBSC. RAILGUN on Arbitrum is governed by the system on Ethereum and thus voting power accrues to the Ethereum RAIL token. ### [hashtag](https://docs.railgun.org/wiki/rail-token#contract-addresses) Contract Addresses **Ethereum - RAIL**: 0xe76c6c83af64e4c60245d8c7de953df673a7a33d **BNB Smart Chain - RAILBSC:** 0x3F847b01d4d498a293e3197B186356039eCd737F **Polygon - RAILPOLY:** 0x92A9C92C215092720C731c96D4Ff508c831a714f [PreviousKoinly Tax Exportschevron-left](https://docs.railgun.org/wiki/assurance/koinly-tax-exports) [NextRAIL Active Governor Allocationchevron-right](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) Last updated 6 months ago Was this helpful? --- # Gasless Interactions | Wiki Another major innovation deployed by the RAILGUN system is the ability to send interactions without needing to spend the underlying blockchain’s gas currency. Through the power of Broadcasters and complex ZK circuits, users can interact with RAILGUN entirely in their currency of choice. For example, a user would not need to hold a small balance of ETH to submit gas for interactions on the Ethereum network and could instead choose to only hold and spend a stablecoin like DAI, with all associated gas being submitted in DAI. This is achieved through something called a “Meta Transaction”, a special form of Ethereum/blockchain transaction that is nested within another transaction. The gas fee can be paid in whatever asset the user specifies with the Broadcaster and nested transaction performing any conversion frictionlessly for the user. Like any other spend transactions, a Meta Transaction in RAILGUN calls the transact() function. [PreviousUsing Private Tokenschevron-left](https://docs.railgun.org/wiki/learn/using-private-tokens) [NextUnshielding Tokenschevron-right](https://docs.railgun.org/wiki/learn/unshielding-tokens) Last updated 1 year ago Was this helpful? --- # RAILGUN Deductions | Wiki **Protocol Deductions** The smart contracts take a 0.25% deduction per shield and unshield interaction which is then sent to the “treasury address”. Protocol deductions are distributed to RAILGUN decentralized governance participants over time to RAIL stakers in the form of [Active Governor Allocation](https://docs.railgun.org/wiki/rail-token/rail-active-governor-allocation) . **Broadcaster Premiums** To use RAILGUN, users can supply a [Broadcasterarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers) to facilitate their interactions (users can self-relay interactions if they want to save on gas). Broadcasters require a % premium of the overall gas price for the interaction, but not for the interaction amount. Thus, Broadcaster Premiums do not increase with interaction size. As RAILGUN interactions are [gaslessarrow-up-right](https://docs.railgun.org/wiki/learn/using-shielded-tokens/gasless-transactions) (users do not need ETH/MATIC/BNB to send interactions once assets are shielded), broadcaster premiums contain the underlying blockchain's gas converted to whichever token that users are transacting in. For example, if you are sending DAI on the Ethereum blockchain, then the Broadcaster Premium (which also contains the blockchain interaction gas) is sent entirely in DAI and you do not need to hold/spend ETH in your 0zk address. Therefore, Broadcaster Premiums vary depending on: * Which chain you are using RAILGUN on * Gas price at the time of the interaction * What % of the gas Broadcasters decide to require as an additional premium Premiums are broadcast across the [Waku P2P networkarrow-up-right](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers) and are only needed if users decide to send the interaction and consider the premium & gas to be acceptable. Broadcaster Premiums are up to the individual Broadcasters themselves, but generally they are ~10% of the total gas. Broadcasters compete to provide the lowest premiums. [PreviousExample - DEX Swapschevron-left](https://docs.railgun.org/wiki/learn/integrating-railgun/example-dex-swaps) [NextHelpful Linkschevron-right](https://docs.railgun.org/wiki/learn/helpful-links) Last updated 22 days ago Was this helpful? --- # Community Broadcasters | Wiki Community Broadcasters are public 0x wallets that submit gas to the underlying blockchain on RAILGUN privacy users’ behalf. Actions coming from 0zk addresses appear to originate from Broadcaster addresses. As they are simply a 0x address, anyone can theoretically be a Broadcaster. Broadcasters run a micro Node.Js that broadcasts gas to Broadcaster Clients (i.e. wallets equipped with RAILGUN). Broadcasters also automatically process interactions when received. When users send an interaction in RAILGUN, they select an appropriate Broadcaster, typically based on low gas and availability. The interaction is encrypted in transit, and its contents cannot be read by the Broadcaster, except for an amount of gas which is packaged to allocate to the Broadcaster’s services. Upon receipt of a interaction, the selected Broadcaster will validate its packaged supply and submit the interaction to the underlying blockchain network. Through submitting the interaction, the Broadcaster obscures the sender, amount, receiver, and token details. This makes interactions confidential so they cannot be associated with the sender’s 0x public address. NOTE: At no point do Broadcasters custodially hold users’ tokens nor do they confirm interactions themselves, they merely transfer encrypted information for confirmation by the underlying blockchain infrastructure. Broadcasters are also unable to decrypt details about the interactions, nor can they change the details of an interaction as changing any information would lead to an invalid hash and be rejected by the system as an incorrect cryptographic proof. The Broadcaster network is robust from a game theory perspective. If a user’s chosen Broadcaster refuses to pass on an interaction for whatever reason, then they can send it to another cooperative Broadcaster. All that it takes is for at least 1 cooperative Broadcaster to submit the data on-chain for the underlying blockchain’s ledger to update. ### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers#waku-network) Waku Network Broadcasters communicate with users through the [Waku arrow-up-right](https://waku.org/) peer-to-peer private communication network. Waku is a decentralized messaging protocol with strong privacy preservation such as sender confidentiality, metadata protection, and secure personally identifiable information. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers#how-does-railgun-use-waku) How Does RAILGUN use Waku? Waku connects Broadcasters with users to broadcast gas supplies and inform Broadcasters that they wish to have an interaction broadcasted. **Transaction Broadcasts** All interactions that require a Broadcaster generate an additional note addressed to the selected Broadcaster using the Broadcaster's public key. Transaction data is then encrypted and broadcast to the Broadcaster network through the `transact()` function. The user's client then encrypts their transaction data with a shared key derived from the Broadcaster's public key and a randomly generated private key. Broadcasters then attempt to decrypt every message on the chain's where they are listening for messages. Any messages that can be decrypted by a Broadcaster are thus addressed to them. If such a note is found and can be decrypted by the Broadcaster, they verify that the value and token of the note match a previously advertised rate \* the estimated gas of the transaction. Once an acceptable gas submission is included in the transaction, the Broadcaster signs and submits the transaction for consensus by the underlying blockchain. #### [hashtag](https://docs.railgun.org/wiki/learn/privacy-system/community-relayers#interaction-response) Interaction Response The Broadcaster then broadcasts the success/failure status of the transaction in an encrypted message over Waku through the `transact-response.json` file. This status message is encrypted using the shared key derived in the earlier transaction broadcast stage. The client listens to the `transact-response.json` content topic for any message they can decrypt using the previously randomly generated private key. In the event of failure, the transaction sender can retry with the same Broadcaster or select a new Broadcaster. [PreviousTrusted Setup Ceremonychevron-left](https://docs.railgun.org/wiki/learn/privacy-system/trusted-setup-ceremony) [NextPrivacy Overviewchevron-right](https://docs.railgun.org/wiki/learn/privacy-system/privacy-overview) Last updated 6 months ago Was this helpful? ---