first pass network structure

documentation/new_docs/pages/network/_meta.json

@@ -0,0 +1,9 @@
+{
+  "index": "Introduction",
+  "concepts": "Core Concepts",
+  "architecture": "Architecture",
+  "traffic": "Traffic Flow",
+  "cryptography": "Crypto",
+  "rewards": "Rewards",
+  "licensing": "Licencing"
+}

documentation/new_docs/pages/network/architecture/network-overview.md

@@ -0,0 +1,49 @@
+# Network Overview
+
+Nym is a privacy platform. It provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous access control using blinded, re-randomizable, decentralized credentials. Our goal is to allow developers to build new applications, or upgrade existing apps, with privacy features unavailable in other systems.
+
+The Nym platform knits together several privacy technologies, integrating them into a system of cooperating networked nodes.
+
+At a high level, our technologies include:
+
+* a **mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the **Loopix** design.
+* a privacy enhancing signature scheme called **Coconut**. Coconut allows a shift in thinking about resource access control, from an identity-based paradigm based on _who you are_ to a privacy-preserving paradigm based on _right to use_.
+* **Sphinx**, a way of transmitting armoured, layer-encrypted information packets which are indistinguishable from each other at a binary level.
+* the **Nyx** blockchain, a general-purpose CosmWasm-enabled smart contract platform, and the home of the smart contracts which keep track of the mixnet.
+
+The most important thing to note is that these technologies ensure privacy at two different levels of the stack: **network data transmission**, and **transactions**.
+
+Here's an overview diagram of the different types of nodes making up the network:
+
+![Nym Platform](../images/nym-platform-dark.png)
+
+Developers can think of the network as being comprised of **infrastructure nodes** and **clients** for interacting with this infrastructure via **P**rivacy-**e**nhanced **app**lications (PEApps).
+
+## Mixnet Infrastructure
+The mixnet - the different pieces of software that your traffic will pass through when using an privacy-enhanced app (PEApp) - is made up of several different types of nodes:
+
+* **Mix Nodes** provide network security for network content _and_ metadata, making it impossible to see who is communicating with who, by performing packet-mixing on traffic travelling through the network.
+
+* **Gateways** act as message storage for clients which may go offline and come back online again, and defend against denial of service attacks. The default gateway implementation included in the Nym platform code holds packets for later retrieval. For many applications (such as simple chat), this is usable out of the box, as it provides a place that potentially offline clients can retrieve packets from. The access token allows clients to pull messages from the gateway node.
+
+* **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the network requester binary.
+
+* **Nyx Blockchain Validators** secure the network with proof-of-stake Sybil defenses, determine which nodes are included within the network, and work together to create Coconut threshold credentials which provide anonymous access to data and resources. They also produce blocks and secure the Nyx Blockchain. Initially, this chain was used only to house the CosmWasm smart contracts keeping track of Nym's network topology, token vesting contracts, and the `NYM` token itself. In recent months, we've decided to expand the role of Nyx and instead expand its role by making it an open smart contract platform for anyone to upload CosmWasm smart contracts to. Validators also provide privacy-enhanced credentials based on the testimony of a set of decentralized, blockchain-based issuing authorities. Nym validators use the [Coconut](https://arxiv.org/abs/1802.07344) [signature scheme](https://en.wikipedia.org/wiki/Digital_signature) to issue credentials. This allows privacy apps to generate anonymous resource claims through decentralised authorities, then use them with Service Providers.
+
+## Privacy-enhanced applications (PEApps)
+PEApps use a Nym client to connect to the network in order to get the available Network Topology for traffic routing, and send/receive packets to other users and services. Clients, in order to send traffic through the mixnet, connect to gateways. Since applications may go online and offline, a client's gateway provides a sort of mailbox where apps can receive their messages.
+
+Nym clients connect to gateways. Messages are automatically piped to connected clients and deleted from the gateway's disk storage. If a client is offline when a message arrives, it will be stored for later retrieval. When the client connects, all messages will be delivered, and deleted from the gateway's disk.
+
+When it starts up, a client registers itself with a gateway, and the gateway returns an access token. The access token plus the gateway's IP can then be used as a form of addressing for delivering packets.
+
+There are two basic kinds of privacy enhanced applications:
+
+* **Client apps** running on mobile or desktop devices. These will typically expose a user interface (UI) to a human user. These might be existing apps such as crypto wallets that communicate with Nym via our SOCKS5 proxy, or entirely new apps.
+* **Service Providers**, which will usually run on a server, and take actions on behalf of users without knowing who they are.
+
+Service Providers (SPs) may interact with external systems on behalf of a user. For example, an SP might submit a Bitcoin, Ethereum or Cosmos transaction, proxy a network request, talk to a chat server, or provide anonymous access to a medical system such as a [privacy-friendly coronavirus tracker](https://constructiveproof.com/posts/2020-04-24-coronavirus-tracking-app-privacy/).
+
+There is also a special category of Service Provider, namely SPs that do not visibly interact with any external systems. You might think of these as crypto-utopiapps: they're doing something, but it's not possible from outside to say with any certainty what their function is, or who is interacting with them.
+
+All apps talk with gateways using Sphinx packets and a small set of simple control messages. These messages are sent to gateways over websockets. Each app client has a long-lived relationship with its gateway; Nym defines messages for clients registering and authenticating with gateways, as well as sending encrypted Sphinx packets.

documentation/new_docs/pages/network/architecture/network-rewards.md

@@ -0,0 +1,45 @@
+# Network Rewards
+
+Node operator and delegator rewards are determined according to the principles laid out in the section 6 of [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf). 
+
+Below is a TLDR of the variables and formulas involved in calculating these rewards per epoch. The initial reward pool contains 250 million NYM, leaving a circulating supply of 750 million NYM.
+
+|Symbol|Definition|
+|---|---|
+|<img src="https://render.githubusercontent.com/render/math?math=R"></img>|global share of rewards available, starts at 2% of the reward pool. 
+|<img src="https://render.githubusercontent.com/render/math?math=R_{i}"></img>|node reward for mixnode `i`.
+|<img src="https://render.githubusercontent.com/render/math?math=\sigma_{i}"></img>|ratio of total node stake (node bond + all delegations) to the token circulating supply.
+|<img src="https://render.githubusercontent.com/render/math?math=\lambda_{i}"></img>|ratio of stake operator has pledged to their node to the token circulating supply.
+|<img src="https://render.githubusercontent.com/render/math?math=\omega_{i}"></img>|fraction of total effort undertaken by node `i`.
+|<img src="https://render.githubusercontent.com/render/math?math=k"></img>|number of nodes stakeholders are incentivised to create, set by the validators, a matter of governance. Currently determined by the reward set size.
+|<img src="https://render.githubusercontent.com/render/math?math=\alpha"></img>|Sybil attack resistance parameter - the higher this parameter is set the stronger the reduction in competitivness gets for a Sybil attacker.
+|<img src="https://render.githubusercontent.com/render/math?math=PM_{i}"></img>|declared profit margin of operator `i`.
+|<img src="https://render.githubusercontent.com/render/math?math=PF_{i}"></img>|uptime of node `i`, scaled to 0 - 1, for the rewarding epoch
+|<img src="https://render.githubusercontent.com/render/math?math=PP_{i}"></img>|cost of operating node `i` for the duration of the rewarding eopoch.
+
+Node reward for node `i` is determined as:
+
+<img src="https://render.githubusercontent.com/render/math?math=R_{i}=PF_{i} \cdot R \cdot (\sigma^'_{i} \cdot \omega_{i} \cdot k %2b \alpha \cdot \lambda^'_{i} \cdot \sigma^'_{i} \cdot k)/(1 %2b \alpha)"></img>
+
+
+where:
+
+<img src="https://render.githubusercontent.com/render/math?math=\sigma^'_{i} = min\{\sigma_{i}, 1/k\}"></img>
+
+
+and
+
+<img src="https://render.githubusercontent.com/render/math?math=\lambda^'_{i} = min\{\lambda_{i}, 1/k\}"></img>
+
+
+Operator of node `i` is credited with the following amount:
+
+<img src="https://render.githubusercontent.com/render/math?math=min\{PP_{i},R_{i}\} %2b max\{0, (PM_{i} %2b (1 - PM_{i}) \cdot \lambda_{i}/\delta_{i}) \cdot (R_{i} - PP_{i})\}"></img>
+
+
+Delegate with stake `s` recieves:
+
+<img src="https://render.githubusercontent.com/render/math?math=max\{0, (1-PM_{i}) \cdot (s^'/\sigma_{i}) \cdot (R_{i} - PP_{i})\}"></img>
+
+
+where `s'` is stake `s` scaled over total token circulating supply.

documentation/new_docs/pages/network/architecture/nodes/gateway.md

@@ -0,0 +1,11 @@
+# Gateways
+
+> The gateway setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/gateway-setup.html).
+
+Gateways are key to both the usability of the mixnet, and the operation of the mixnet's tokenomics. They serve two main functions: 
+* In the future (when the mixnet is no longer running in 'free to use' mode), to check for zkNym credentials (previously referred to as [Coconut Credentials](../bandwidth-credentials.md)) with which users can anonymously prove they have paid to send traffic through the mixnet. A % of the worth of these credentials will be distributed to the operator of the gateway periodically as payment for providing their service. The more credentials user clients 'spend' with them, the higher the rewards for the gateway operator and their delegators will be. The rest of this value will be sent to the Mixmining Pool, a pool of tokens from which `NYM` rewards are distributed to mix node operators. 
+* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page](../architecture/traffic-flow.md) and the [addressing scheme](../architecture/addressing-system.md) for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online. 
+
+## Further Reading 
+* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2 
+* [Nym Blog: Gateways to Privacy](https://blog.nymtech.net/gateways-to-privacy-51196005bf5)

documentation/new_docs/pages/network/architecture/nodes/mixnode.md

@@ -0,0 +1,17 @@
+# Mix Nodes
+
+> The mix node setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/mix-node-setup.html).
+
+Mix nodes are the backbone of the mixnet. These are the nodes that perform 'mix mining', otherwise known simply as 'mixing'. 
+
+Mix nodes, after receiving a packet, decrypt its outer 'layer' and hold it for a variable amount of time before passing it to its next destination - either another mix node, or a gateway. In doing so, they 'mix' packets by sending them to their next destination in a different order than they were received. 
+
+Mix nodes are rewarded according to their quality of service, and the probability of their inclusion in the active set (i.e. the nodes that mix traffic for the next epoch) is also affected by this (as well as their delegation-based reputation - see the [Mix node deepdive](#further-reading) below for more on this). 
+
+## (Coming soon) Mixing: a Step-by-Step Breakdown
+
+## Further reading
+* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4 
+* [Nym Blog: Mix node deepdive](https://blog.nymtech.net/nym-mixnodes-deep-dive-d2b91917f097)
+* [Mixnet Traffic Flow overview](../architecture/traffic-flow.md)
+* [Reward Sharing for Mixnets](https://nymtech.net/nym-cryptoecon-paper.pdf)

documentation/new_docs/pages/network/architecture/nodes/network-requester.md

@@ -0,0 +1,22 @@
+# Network Requester
+
+> The network requester setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/network-requester-setup.html).
+
+Network requesters are the first instance of the catch-all term 'service', or 'service providers'. In essence, think of services as being the part of the mixnet infrastructure that let you _do_ something, such as access emails, messaging service backends, or blockchains via the mixnet. 
+
+## Domain filtering
+Network requesters, in essence, act as a form of proxy (somewhat analagous to a Tor exit node). If you have access to a server, you can run the network requester, which allows Nym users to send outbound requests from their local machine through the mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers.
+
+By default the network requester is **not** an open proxy (although it can be used as one). It uses a whitelist for outbound requests.
+
+Any request to a URL which is not on this local list (modified by the node operator) or [Nym's default list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) will be blocked.
+
+This default whitelist is useful for knowing that the majority of Network requesters are able to support certain apps 'out of the box', and the local whitelist allows operators to include their own whitelisted domains. 
+
+> Substantial changes are on the horizon concerning how Network Requesters manage incoming requests - if you are an operator and have experience running software such as Tor exit nodes or p2p nodes get in touch via our [Matrix server](https://matrix.to/#/#dev:nymtech.chat). 
+
+## (Coming soon) Consuming credentials for anonymous service payment 
+
+## Further reading
+* [Nym Blog: Network Requester deepdive](https://blog.nymtech.net/tech-deepdive-network-requesters-e5359a6cc31c)
+* [Nym Blog: Choose Your Character](https://blog.nymtech.net/choose-your-character-an-overview-of-nym-network-actors-19e6a9808540)

documentation/new_docs/pages/network/architecture/nodes/overview.md

@@ -0,0 +1,7 @@
+# Node Types
+
+```admonish info
+We are working on a detailed description of how each component of Nym Mixnet and Nyx blockchain functions, as well as references to any literature and technical specs.
+
+Meanwhile please refer to our [**Operators Guide**](https://nymtech.net/operators) book.
+```

documentation/new_docs/pages/network/architecture/nodes/validator.md

@@ -0,0 +1,12 @@
+# Validators
+
+> The validator setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/validator-setup.html).
+
+Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain. 
+
+The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](../nyx/mixnet-contract.md) and [Vesting](../nyx/vesting-contract.md) smart contracts are deployed. 
+
+## Further Reading 
+* Detailed info on Nyx Validators and token flow can be found in [Nym Reward Sharing for Mixnets document](https://nymtech.net/nym-cryptoecon-paper.pdf) in section 2.3 and 2.4.
+* Our [quarterly update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023.
+* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 3.1 

documentation/new_docs/pages/network/architecture/nym-vs-others.md

@@ -0,0 +1,40 @@
+# Nym vs Other Systems
+
+### Why use Nym: Understanding the Significance of Nym
+
+Nym is the first system we're aware of which provides integrated protection on both the network and transaction level at once. This seamless approach gives the best possible privacy protections, ensuring that nothing falls through the cracks between systems.
+
+The diagram and brief explainer texts below give a high level overview of the difference between Nym and other comparable systems.
+
+> If you want to dig more deeply into the way traffic is packetised and moved through the mixnet, check out the [Mixnet Traffic Flow](https://nymtech.net/docs/architecture/traffic-flow.html) page of the docs.
+<!-- IMG DOES NOT EXIST
+![](../images/nym-vs-animation.gif)
+-->
+
+### Nym vs VPNs
+
+The most popular network-level privacy solution currently is the VPN (virtual private network), which provides network-level protection via an encrypted tunnel between a user’s computer and one run by a VPN provider. VPNs are often misconfigured, however, and even when configured correctly, don’t offer real privacy or adequate resistance to censorship.
+
+VPN providers can also fully observe all network traffic between users and the public internet, knowing exactly what services its users are accessing at a given time. The user must trust that the VPN provider is not using their information in a malicious manner or keeping logs.
+
+The Nym mixnet is an anonymous overlay network that provides strong network-level anonymity, even in the face of powerful systems capable of passively monitoring the entire network. The mixnet is decentralized, with no trusted third parties, and so does not require a trusted provider like a VPN. More importantly, Nym provides superior privacy to VPNs and can support high-quality of service and low latency through incentives.
+
+### Nym vs Tor
+
+Tor is the best-known anonymous overlay network today. Unlike VPNs, Tor provides a ‘circuit’ of three hops that provides better privacy than single-node VPNs, so any single node in Tor can’t deanonymize traffic. Tor’s onion-routing encrypts traffic between each hop so that only the final hop, the Tor ‘exit node’, can decrypt the package.
+
+However, Tor’s anonymity properties can be defeated by an entity that is capable of monitoring the entire network’s ‘entry’ and ‘exit’ nodes, because while onion-routing encrypts traffic, Tor does not add timing obfuscation or use decoy traffic to obfuscate the traffic patterns which can be used to deanonymize users. Although these kinds of attacks were thought to be unrealistic when Tor was invented, in the era of powerful government agencies and private companies, these kinds of attacks are a real threat. Tor’s design is also based on a centralized directory authority for routing.
+
+While Tor may be the best existing solution for general-purpose web-browsing that accesses the entire internet, it is inarguable that mixnets are better than Tor for message-passing systems such as cryptocurrency transactions and secure messaging, and we believe well designed incentives can also enable the use of Nym as a general purpose decentralized VPN. The Nym mixnet provides superior privacy by making packets indistinguishable from each other, adding cover traffic, and providing timing obfuscation. Unlike both previous mixnet designs and Tor, the Nym mixnet decentralizes its shared operations using blockchain technology and uses incentives to both scale and provide censorship-resistance.
+
+### Nym vs I2P
+
+I2P (‘Invisible Internet Project’) replaces Tor’s directory authority with a distributed hash table for routing. How to design a secure and private distributed hash table is still an open research question, and I2P is open to a number of attacks that isolate, misdirect, or deanonymize users. Like Tor, I2P is based on ‘security by obscurity’, where it is assumed that no adversary can watch the entire network. While security by obscurity may have been cutting-edge at the turn of the millennium, such an approach is rapidly showing its age.
+
+Nym’s cutting-edge mixnet design guarantees network anonymity and resistance to surveillance even in the face of powerful deanonymizing attacks. Unlike I2P, Nym adds decoy traffic and timing obfuscation. Rather than a centralized directory authority or distributed hash table, Nym uses blockchain technology and economic incentives to decentralize its network.The Nym mixnet can anonymize metadata even against government agencies or private companies who can monitor network links and observe the incoming and outgoing traffic of all clients and servers.
+
+### Nym vs Facebook Connect
+
+The Nym credential system decentralizes the functions of systems like Facebook Connect while adding privacy. Personal data has become a toxic asset, even to companies who base their entire business around it, as evidenced by the hack of Facebook’s OAuth identity system in 2018 and the subsequent release of the data of 50 million users.
+
+Unlike Facebook Connect and similar OAuth-based services like Sign in with Google, traditional usernames and passwords, or even public/private key pairs, Nym credentials allow users to authenticate and authorize data sharing without unwillingly revealing any information to a third party. There is no central third party in charge of the credentials, and users remain totally in control of their own data, disclosing it only to those who they want to. A user can store their data wherever they want (including on their own devices), and unlike alternatives like W3C’s DIDs, a user does not store anything on the blockchain, offering better privacy.

documentation/new_docs/pages/network/architecture/nyx/interacting-with-chain.md

@@ -0,0 +1,17 @@
+# Interacting with Nyx Chain and Smart Contracts
+
+There are two options for interacting with the blockchain to send tokens or interact with deployed smart contracts: 
+* [`Nym-CLI`](../tools/nym-cli.md) tool 
+* `nyxd` binary
+
+## Nym-CLI tool (recommended in most cases) 
+The `nym-cli` tool is a binary offering a simple interface for interacting with deployed smart contract (for instance, bonding and unbonding a mix node from the CLI), as well as creating and managing accounts and keypairs, sending tokens, and querying the blockchain. 
+
+Instructions on how to do so can be found on the [`nym-cli` docs page](../tools/nym-cli.md), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html).
+
+## Nyxd binary 
+The `nyxd` binary, although more complex to compile and use, offers the full range of commands availiable to users of CosmosSDK chains. Use this if you are (e.g.) wanting to perform more granular queries about transactions from the CLI. 
+
+You can use the instructions on how to do this on from the [`gaiad` docs page](https://hub.cosmos.network/main/delegators/delegator-guide-cli.html#querying-the-state), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html).
+
+

documentation/new_docs/pages/network/architecture/nyx/ledger-live.md

@@ -0,0 +1,79 @@
+# Ledger Live Support
+
+Use the following instructions to interact with the Nyx blockchain - either with deployed smart contracts, or just to send tokens - using your Ledger device to sign transactions. 
+
+## Prerequisites 
+* Download and install [Ledger Live](https://www.ledger.com/ledger-live). 
+* Compile the `nyxd` binary as per the instructions [here](https://nymtech.net/operators/nodes/validator-setup.html#building-the-nym-validator). Stop after you can successfully run `nyxd` and get the helptext in your console output. 
+
+## Prepare your Ledger App 
+* Plug in your Ledger device                                                    
+* Install the `Cosmos (ATOM)` app by following the instructions [here](https://hub.cosmos.network/main/resources/ledger.html). This app allows you to interact with **any** Cosmos SDK chain - you can manage your ATOM, OSMOSIS, NYM tokens, etc.                                              
+* On the device, navigate to the Cosmos app and open it    
+
+## Create a keypair 
+Add a reference to the ledger device on your local machine by running the following command in the same directory as your `nyxd` binary: 
+
+```
+nyxd keys add ledger_account --ledger 
+```  
+
+## Command help with `nyxd`
+More information about each command is available by consulting the help section (`--help`) at each layer of `nyxd`'s commands:
+
+```
+# logging top level command help
+nyxd --help
+
+# logging top level command help for transaction commands 
+nyxd tx --help
+
+# logging top level command help for transaction commands utilising the 'bank' module
+nyxd tx bank --help
+```
+
+## Sending tokens between addresses
+Perform a transaction from the CLI with `nyxd`, appending the `--ledger` option to the command. 
+
+As an example, the below command will send 1 `NYM` from the ledger account to the `$DESTINATION_ACCOUNT`:
+
+```
+nyxd tx bank send ledger_account $DESTINATION_ACCOOUNT 1000000unym --ledger --node https://rpc.dev.nymte.ch:443
+```
+
+> When a command is run, the transaction will appear on the Ledger device and will require physical confirmation from the device before being signed.
+
+## Nym-specific transactions
+Nym-specific commands and queries, like bonding a mix node or delegating unvested tokens, are available in the `wasm` module, and follow the following pattern: 
+
+```
+# Executing commands
+nyxd tx wasm execute $CONTRACT_ADDRESS $JSON_MSG
+
+# Querying the state of a smart contract 
+nyxd query wasm contract-state smart $CONTRACT_ADDRESS $JSON_MSG
+```
+
+You can find the value of `$CONTRACT_ADDRESS` in the [`network defaults`](https://github.com/nymtech/nym/blob/release/v1.1.7/common/network-defaults/src/mainnet.rs) file. 
+
+The value of `$JSON_MSG` will be a blog of `json` formatted as defined for each command and query. You can find these definitions for the mixnet smart contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/mixnet-contract/src/msg.rs) and for the vesting contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/vesting-contract/src/messages.rs) under `ExecuteMsg` and `QueryMsg`. 
+
+### Example command execution: 
+#### Delegate to a mix node
+You can delegate to a mix node from the CLI using `nyxd` and signing the transaction with your ledger by filling in the values of this example: 
+```
+CONTRACT_ADDRESS=mixnet_contract_address
+
+./nyxd tx wasm execute $CONTRACT_ADDRESS '{"delegate_to_mixnode":{"mix_identity":"MIX_NODE_IDENTITY","amount":{"amount":"100000000000","denom":"unym"}}}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --gas-prices 0.025unymt --gas auto -b block
+```
+
+> By replacing the value of `CONTRACT_ADDRESS` with the address of the vesting contract, you could use the above command to use tokens held in the vesting contract. 
+
+#### Query a vesting schedule 
+You can query for (e.g.) seeing the current vesting period of an address by filling in the values of the following: 
+```
+CONTRACT_ADDRESS=vesting_contract_address
+
+nyxd query wasm contract-state smart $CONTRACT_ADDRESS '{"get_current_vesting_period"}:{"address": "address_to_query_for"}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --chain-id qa-net --gas-prices 0.025unymt --gas auto -b block  
+```
+

documentation/new_docs/pages/network/architecture/nyx/mixnet-contract.md

@@ -0,0 +1,13 @@
+# Mixnet Contract
+
+The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet).
+
+### Functionality 
+The Mixnet contract has multiple functions: 
+* storing bonded mix node and gateway information (and removing this on unbonding).
+* providing the network-topology to the (cached) validator API endpoint used by clients on startup for routing information. 
+* storing delegation and bond amounts.
+* storing reward amounts. 
+
+The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
+

documentation/new_docs/pages/network/architecture/nyx/rpc-node.md

@@ -0,0 +1,9 @@
+# RPC Nodes
+
+RPC Nodes (which might otherwise be referred to as 'Lite Nodes' or just 'Full Nodes') differ from Validators in that they hold a copy of the Nyx blockchain, but do **not** participate in consensus / block-production. 
+
+You may want to set up an RPC Node for querying the blockchain, or in order to have an endpoint that your app can use to send transactions. 
+
+In order to set up an RPC Node, simply follow the instructions to set up a [Validator](https://nymtech.net/operators/nodes/validator-setup.html), but **exclude the `nyxd tx staking create-validator` command**. 
+
+If you want to fast-sync your node, check out the Polkachu snapshot and their other [resources](https://polkachu.com/seeds/nym).

documentation/new_docs/pages/network/architecture/nyx/smart-contracts.md

@@ -0,0 +1,9 @@
+# Smart Contracts
+
+The Nyx blockchain is based on [CosmWasm](https://cosmwasm.com/). It allows users to code smart contracts in a safe subset of the Rust programming language, easily export them to WebAssembly, and upload them to the blockchain. Information about the chain can be found on the [Nyx blockchain explorer](https://nym.explorers.guru/). 
+
+There are currently two smart contracts on the Nyx chain: 
+* the [Mixnet contract](./mixnet-contract.md) which manages the network topology of the mixnet, tracking delegations and rewarding. 
+* the [Vesting contract](./vesting-contract.md) which manages `NYM` token vesting functionality.  
+
+> Users will soon be able to create and upload their own CosmWasm smart contracts to Nyx and take advantage of applications such as the Coconut Credential Scheme - more to be announced regarding this very soon.

documentation/new_docs/pages/network/architecture/nyx/vesting-contract.md

@@ -0,0 +1,11 @@
+# Vesting Contract
+
+The vesting contract allows for the creation of vesting accounts, allowing `NYM` tokens to vest over time, and for users to minimally interact with the Mixnet using their unvested tokens. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/vesting). 
+
+### Functionality 
+The Vesting contract has multiple functions:
+* Creating and storing vesting `NYM` token vesting accounts.
+* Interacting with the Mixnet using vesting (i.e. non-transferable) tokens, allowing users to delegate their unvested tokens. 
+
+The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values.
+

documentation/new_docs/pages/network/cryptography/bandwidth-credentials.md

@@ -0,0 +1,80 @@
+# Bandwidth Credentials
+
+You can now try using Nym Bandwidth Credentials in our [Sandbox testnet environment](https://sandbox-explorer.nymtech.net).
+
+Create a `sandbox.env` file with the following details: 
+
+```
+CONFIGURED=true
+
+NETWORK_NAME=sandbox
+
+RUST_LOG=info
+RUST_BACKTRACE=1
+
+BECH32_PREFIX=nymt
+MIX_DENOM=unymt
+MIX_DENOM_DISPLAY=nymt
+STAKE_DENOM=unyxt
+STAKE_DENOM_DISPLAY=nyxt
+DENOMS_EXPONENT=6
+
+REWARDING_VALIDATOR_ADDRESS="nymt1mxuweurc066kprnngtm8zmvam7m2nw26yatpmv"
+MIXNET_CONTRACT_ADDRESS="nymt1dlsvvgey26ernlj0sq2afjluh3qd4ap0k9eerekfkw5algqrwqksaf2qf7"
+VESTING_CONTRACT_ADDRESS="nymt19g9xuqrvz2frv905v3fc7puryfypluhg383q9zwsmedrlqekfgys62ykm4"
+MULTISIG_CONTRACT_ADDRESS="nymt142dkm8xe9f0ytyarp7ww4kvclva65705jphxsk9exn3nqdsm8jkqnp06ac"
+COCONUT_BANDWIDTH_CONTRACT_ADDRESS="nymt1ty0frysegskh6ndm3v96z5xdq66qzcu0aw7xcxlgp54jg0mjwlgqplc6v0"
+COCONUT_DKG_CONTRACT_ADDRESS="nymt1gwk6muhmzeuxje7df7rjvqwl2vex0kj4t2hwuzmyx5k62kfusu5qk4k5z4"
+GROUP_CONTRACT_ADDRESS="nymt14ry36mwauycz08v8ndcujghxz4hmua5epxcn0mamlr3suqe0l2qsqx5ya2"
+
+STATISTICS_SERVICE_DOMAIN_ADDRESS="http://0.0.0.0"
+NYXD="https://rpc.sandbox.nymtech.net"
+NYM_API="https://sandbox-validator1-api.nymtech.net/api"
+```
+
+Create an account on Sandbox using the nym-cli: 
+
+```./nym-cli --config-env-file <path-to>sandbox.env account create```
+
+You will need `nymt` funds sent to this account. Get in touch via Nym [Telegram](https://t.me/nymchan) or [Discord](https://nymtech.net/go/discord) and we can send them to you. 
+
+Next, you init the nym-client with the enabled credentials mode set to true:  
+
+```./nym-client --config-env-file <path-to>sandbox.env init --id <ID> --enabled-credentials-mode true```
+
+Using the new credentials binary, purchase some credentials for the client. The recovery directory is a directory where the credentials will be temporarily stored in case the request fails.  
+
+```./credential --config-env-file <path-to>sandbox.env run --client-home-directory <path-to-the-client-config> --nyxd-url https://rpc.sandbox.nymtech.net --mnemonic "<mnemonic of the account created above>" --amount 50 --recovery-dir <a-path> ```
+
+You can redeem this now by running the nym-client, in enabled credentials mode:
+
+```./nym-client --config-env-file <path-to>sandbox.env run --id <ID> --enabled-credentials-mode true```
+
+Run the network requester which can be downloaded [here](https://github.com/nymtech/nym/releases/download/nym-binaries-v1.1.9/nym-network-requester)
+
+ `./nym-network-requester run`
+
+> You need to run this version for now, as the `nym-client` functionality was recently integrated into the `network-requester` binary but for the moment cannot support coconut credentials natively.
+
+Now time to init the socks5 client: 
+
+`./nym-socks5-client --config-env-file <path-to>sandbox.env init --id <ID> --provider <insert provider address which was returned when init-ing the nym-client> --enabled-credentials-mode true`
+
+Purchase credentials for this now too: 
+
+`./credential --config-env-file <path-to>sandbox.env run --client-home-directory <path-to-socks5-config> --nyxd-url https://rpc.sandbox.nymtech.net --mnemonic "<any valid sandbox mnemonic>" --amount 100 --recovery-dir <a-path>`
+
+Run the socks5 client:
+
+`./nym-socks5-client --config-env-file <path-to>sandbox.env run --id <ID> --enabled-credentials-mode true`
+
+NOTE 
+
+You can check to see if credentials have been correctly purchased by installing sqlite, and proceeding to do the following:
+
+```
+sqlite3 ~/.nym/socks5-clients/<ID>/data/credentials_database.db  
+select * from coconut_credentials;
+```
+
+Keep in mind 1GB = 1NYM 

documentation/new_docs/pages/network/cryptography/coconut.md

@@ -0,0 +1,60 @@
+# Coconut
+
+> Coconut is in active development - stay tuned for code and integration examples
+
+Coconut is a cryptographic signature scheme that produces privacy-enhanced credentials. It lets application programmers who are concerned with resource access control to think and code in a new way.
+
+Most of the time, when we build system security, we think of _who_ questions:
+
+- Has Alice identified herself (authentication)?
+- Is Alice allowed to take a specific action (authorisation)?
+
+Coconut fundamentally changes these questions. Rather than asking _who_ a user is, it allows application designers to ask different questions, mostly centered around questions of _rights_:
+
+- Does the entity taking this action have a right to do X?
+
+This allows a different kind of security. Many of the computer systems we talk to every day don't need to know _who we are_, they only need to know if we have a _right to use_ the system. Coconut allows signing authorities and validators to work together to determine whether a given private key holder has a right to take an action. The credentials are generated cooperatively by decentralised, trustless systems.
+
+Once the credentials are generated, they can be _re-randomized:_ entirely new credentials, which no one has ever seen before, can be presented to service providers, and magically validated without being linkable back to the credential originally given out by validators.
+
+These properties allow Coconut credentials to act as something like a decentralized and fully private version of OAuth credentials, or like cryptographic bearer tokens generated by decentralised systems. The tokens can be mutated so that they are not traceable, but still verified with the original permissions intact.
+
+Users present cryptographic claims encoded inside the credentials to get secure access to resources despite the systems verifying credential usage not being able to know who they are.
+
+### Re-randomisation vs pseudonymity
+
+We stand on the shoulders of giants. Ten years ago, Bitcoin showed the way forward by allowing people to control resource access without recourse to _who_ questions. Rather, in Bitcoin and succeeding blockchains, a private key proves a _right to use_.
+
+But as we can now see, private keys in blockchain systems act only as a minor barrier to finding out _who_ is accessing resources. A Bitcoin or Ethereum private key is effectively a long-lived pseudonym which is easily traceable through successive transactions.
+
+Coconut allows us to build truly private systems rather than pseudonymous ones.
+
+### How does Coconut work?
+
+Just like normal credentials, Nym's Coconut credentials can be signed with a secret key and later verified by anybody with the correct public key. But Nym credentials have additional superpowers when compared to "normal" signature schemes like RSA or DSA.
+
+Specifically, Coconut is a blinded, re-randomizable, selective disclosure threshold credential signature scheme. That's quite a mouthful, so let's break it down into its component parts.
+
+Let's say you have a `message` with the content `This credential controls X` in hand. In addition to the normal `sign(message, secretKey)` and `verify(message, publicKey)` functions present in other signature schemes, Coconut adds the following:
+
+1. _[Blind signatures](https://en.wikipedia.org/wiki/Blind_signature)_ - disguises message content so that the signer can't see what they're signing. This defends users against signers: the entity that signed can't identify the user who created a given credential, since they've never seen the message they're signing before it's been _blinded_ (turned into gobbledygook). Coconut uses zero-knowledge proofs so that the signer can sign confidently without seeing the unblinded content of the message.
+
+2. _Re-randomizable signatures_ - take a signature, and generate a brand new signature that is valid for the same underlying message `This credential controls X`. The new bitstring in the re-randomized signature is equivalent to the original signature but not linkable to it. So a user can "show" a credential multiple times, and each time it appears to be a new credential, which is unlinkable to any previous "show". But the underlying content of the re-randomized credential is the same (including for things like double-spend protection). This once again protects the user against the signer, because the signer can't trace the signed message that they gave back to the user when it is presented. It also protects the user against the relying party that accepts the signed credential. The user can show re-randomized credentials repeatedly, and although the underlying message is the same in all cases, there's no way of tracking them by watching the user present the same credential multiple times.
+
+3. _Selective disclosure of attributes_ - allows someone with the public key to verify some, but not all, parts of a message. So you could for instance selectively reveal parts of a signed message to some people, but not to others. This is a very powerful property of Coconut, potentially leading to diverse applications: voting systems, selective revelation of medical data, privacy-friendly KYC systems, etc.
+
+4. _[Threshold issuance](https://en.wikipedia.org/wiki/Threshold_cryptosystem)_ - allows signature generation to be split up across multiple nodes and decentralized, so that either all signers need to sign (_n of n_ where _n_ is the number of signers) or only a threshold number of signers need to sign a message (_t of n_ where _t_ is the threshold value).
+
+Taken together, these properties provide privacy for applications when it comes to generating and using signatures for cryptographic claims. If you compare it to existing tech, you might think of it as a sort of supercharged decentralized privacy-friendly [JWT](https://jwt.io/).
+
+A slightly expanded view of Coconut is available [in this blog post](https://medium.com/nymtech/nyms-coconut-credentials-an-overview-4aa4e922cd51).
+
+### Using Coconut for blockchain transaction privacy
+
+In the context of a blockchain currency system, Coconut allows us to create a privacy-enhanced Coconut credential which provably represents an amount under control of a given entity. The credential can then be "spent" anonymously, as if it were the original value. Double-spending protections apply to the credential, so it can only be spent once. Nyx Validators can then unlock the value so it can be redeemed by the party holding the credential.
+
+Although there's still work to be done to integrate it against various blockchains, in principle Coconut can anonymise blockchain transactions in any system which provides multi-sig. We're working on [Cosmos](https://cosmos.network) integration at the moment. Bitcoin and Ethereum are also obvious targets here.
+
+Coconut is simple and flexible, and can ensure privacy for more than coin transfers; it can provide privacy for more complex smart contracts as well.
+
+Finally, it should be mentioned that Coconut can be applied to both blockchain and non-blockchain systems - it's a general purpose technology.

documentation/new_docs/pages/network/images/nym-logo.svg

@@ -0,0 +1,3 @@
+<svg width="199" height="48" viewBox="0 0 199 48" fill="none" xmlns="http://www.w3.org/2000/svg">
+<path d="M61.91 47.09H48.27L11.05 10.4V47.09H0V0H13.97L51.19 36.68V0H61.91V47.09ZM184.35 0L167.37 16.74L150.39 0H136.42V47.09H147.47V10.4L164.94 27.63C166.29 28.96 168.46 28.96 169.81 27.63L187.28 10.4V47.09H198.33V0H184.35ZM93.81 24.58V47.09H104.86V24.58L130.29 0H116.32L99.33 16.74L82.35 0H68.38L93.81 24.58Z" fill="white"/>
+</svg>

documentation/new_docs/pages/network/index.md

@@ -0,0 +1,3 @@
+# Introduction
+
+Nym's network documentation covering network architecture, crypto systems, etc.

documentation/new_docs/pages/network/licensing.md

@@ -0,0 +1,11 @@
+# Licensing
+
+As a general approach, licensing is as follows this pattern:
+
+* <p xmlns:cc="http://creativecommons.org/ns#" xmlns:dct="http://purl.org/dc/terms/"><a property="dct:title" rel="cc:attributionURL" href="https://nymtech.net/docs">Nym Documentation</a> by <a rel="cc:attributionURL dct:creator" property="cc:attributionName" href="https://nymtech.net">Nym Technologies</a> is licensed under <a href="http://creativecommons.org/licenses/by-nc-sa/4.0/?ref=chooser-v1" target="_blank" rel="license noopener noreferrer" style="display:inline-block;">CC BY-NC-SA 4.0<img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/cc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/by.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/nc.svg?ref=chooser-v1"><img style="height:22px!important;margin-left:3px;vertical-align:text-bottom;" src="https://mirrors.creativecommons.org/presskit/icons/sa.svg?ref=chooser-v1"></a></p>
+
+* Nym applications and binaries are [GPL-3.0-only](https://www.gnu.org/licenses/)
+
+* Used libraries and different components are [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html) or [MIT](https://mit-license.org/)
+
+For accurate information, please check individual files.

documentation/new_docs/pages/network/rewards.mdx

@@ -0,0 +1 @@
+TODO maybe make dir

documentation/new_docs/pages/network/traffic/addressing-system.md

@@ -0,0 +1,17 @@
+# Addressing System
+
+When a Nym client is initalised, it generates and stores its own public/private keypair locally. When the client starts, it automatically connects to the Nym network and finds out what Nym infrastructure exists. It then chooses and connects to a specific Gateway node via websocket.
+
+All apps in the Nym network therefore have an address, in the format:
+
+```
+user-identity-key.user-encryption-key@gateway-identity-key
+``` 
+
+Which in practice, looks something like this: 
+
+```
+DguTcdkWWtDyUFLvQxRdcA8qZhardhE1ZXy1YCC7Zfmq.Dxreouj5RhQqMb3ZaAxgXFdGkmfbDKwk457FdeHGKmQQ@4kjgWmFU1tcGAZYRZR57yFuVAexjLbJ5M7jvo3X5Hkcf
+```
+
+This is obviously not very user-friendly and the moment, and will be developed on in the coming months. 

documentation/new_docs/pages/network/traffic/traffic-flow.md

@@ -0,0 +1,104 @@
+# Mixnet Traffic Flow
+
+## Technical Motivations 
+When you send data across the internet, it can be recorded by a wide range of observers: your ISP, internet infrastructure providers, large tech companies, and governments.
+
+Even if the content of a network request is encrypted, observers can still see that data was transmitted, its size, frequency of transmission, and gather metadata from unencrypted parts of the data (such as IP routing information). Adversaries may then combine all the leaked information to probabilistically de-anonymize users.
+
+The Nym mixnet provides very strong security guarantees against this sort of surveillance. It _packetises_ and _mixes_ together IP traffic from many users inside the _mixnet_. 
+
+> If you're into comparisons, the Nym mixnet is conceptually similar to other systems such as Tor, but provides improved protections against end-to-end timing attacks which can de-anonymize users. When Tor was first fielded, in 2002, those kinds of attacks were regarded as science fiction. But the future is now here.
+
+## Mixnet Traffic Flow
+The Nym mixnet re-orders encrypted, indistinguishable [Sphinx](https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf) packets as they travel through the gateways and mix nodes. 
+
+Traffic to send through the mixnet is broken up into uniformly-sized packets, encrypted in the Sphinx packet format according to the route the packet will take, and sent through the mixnet to be mixed among other real traffic and fake - but identical - 'dummy traffic'. 
+
+At each 'hop' (i.e. as a packet is forwarded from one node in the sequence to another) a layer of decryption is removed from the Sphinx packet, revealing the address of the next hop, and another Sphinx packet. The packet is then held by the node for a variable amount of time, before being forwarded on to the next node in the route. 
+
+Traffic always travels through the nodes of the mixnet like such:
+
+```
+                                                                               
+       +----------+              +----------+             +----------+                 
+       | Mix Node |<-----------> | Mix Node |<----------->| Mix Node |                 
+       | Layer 1  |              | Layer 2  |             | Layer 3  |                 
+       +----------+              +----------+             +----------+                 
+            ^                                                   ^                      
+            |                                                   |                      
+            |                                                   |                      
+            v                                                   v                      
+    +--------------+                                   +-----------------+        
+    | Your gateway |                                   | Service gateway |        
+    +--------------+                                   +-----------------+        
+            ^                                                    ^                     
+            |                                                    |                     
+            |                                                    |                     
+            v                                                    v                     
+  +-------------------+                                +-------------------+           
+  | +---------------+ |                                | +---------------+ |           
+  | |  Nym client   | |                                | |  Nym Client   | |           
+  | +---------------+ |                                | +---------------+ |           
+  |         ^         |                                |         ^         |           
+  |         |         |                                |         |         |           
+  |         |         |                                |         |         |           
+  |         v         |                                |         v         |           
+  | +---------------+ |                                | +---------------+ |           
+  | | Your app code | |                                | | Service Code  | |           
+  | +---------------+ |                                | +---------------+ |           
+  +-------------------+                                +-------------------+           
+   Your Local Machine**                               Service Provider Machine**        
+
+
+** note that depending on the technical setup, the Nym client running on these machines may
+be either a seperate process or embedded in the same process as the app code via one of our SDKs. 
+
+```
+
+
+From your Nym client, your encrypted traffic is sent to:
+* the gateway your client has registered with,  
+* a mix node on layer 1 of the Mixnet, 
+* a mix node on layer 2 of the Mixnet,
+* a mix node on layer 3 of the Mixnet, 
+* the recipient's gateway, which forwards it finally to...
+* the recipient's Nym client, which communicates with an application.  
+
+> If the recipient's Nym client is offline at the time then the packets will be held by the Gateway their Nym client has registered with until they come online.
+
+Whatever is on the 'other side' of the mixnet from your client, all traffic will travel this way through the mixnet. If you are sending traffic to a service external to Nym (such as a chat application's servers) then your traffic will be sent from the recieving Nym client to an application that will proxy it 'out' of the mixnet to these servers, shielding your metadata from them. P2P (peer-to-peer) applications, unlike the majority of apps, might want to keep all of their traffic entirely 'within' the mixnet, as they don't have to necessarily make outbound network requests to application servers. They would simply have their local application code communicate with their Nym clients, and not forward traffic anywhere 'outside' of the mixnet. 
+
+## Acks & Package Retransmission
+Whenever a hop is completed, the receiving node will send back an acknowledgement ('ack') so that the sending node knows that the packet was received. If it does not receive an ack after sending, it will resend the packet, as it assumes that the packet was dropped for some reason. This is done under the hood by the binaries themselves, and is never something that developers and node operators have to worry about dealing with themselves. 
+
+Packet retransmission means that if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received. All nodes in the mixnet support packet retransmission. 
+
+```                                                                                                                                                                    
+                                                                                                               
+  +-------------------+                  +-------------------+                                                
+  | +---------------+ |                  |                   | Packet lost in transmission - no ack recieved! 
+  | |  Nym client   | |                  |                   |-----------------?                              
+  | +-------^-------+ |Send 100 packets  |                   |                                                     
+  |         |         |----------------->|   Gateway your    |  Resend packet    +------------------+     etc...  
+  |         |         |                  |   client is       |------------------>|                  |------------------> 
+  |         |         |                  |   connected to    |                   | Mix node layer 1 |          
+  |         v         | Send 100 acks    |                   |<------------------|                  |         
+  | +---------------+ |<-----------------|                   |   Send ack        +------------------+        
+  | | Your app code | |                  |                   |                                              
+  | +---------------+ |                  |                   |                                             
+  +-------------------+                  +-------------------+                                            
+   Your Local Machine                                                                                    
+
+```                                                                                                                                                                    
+
+## Private Replies using SURBs
+SURBs ('Single Use Reply Blocks') allow apps to reply to other apps anonymously.
+
+It will often be the case that a client app wants to interact with a service of some kind, or a P2P application on someone else's machine. It sort of defeats the purpose of the whole system if your client app needs to reveal its own gateway public key and client public key in order to get a response from the service/app. 
+
+Luckily, SURBs allow for anonymous replies. A SURB is a layer encrypted set of Sphinx headers detailing a reply path ending in the original app's address. SURBs are encrypted by the client, so the recieving service/app can attach its response and send back the resulting Sphinx packet, but it **never has sight of who it is replying to**.
+
+MultiSURBs were implemented in `v1.1.4`. Clients, when sending a message to another client, attach a bundle of SURBs which can be used by the receiver to construct large anonymous replies, such as files. If a reply is too large still (i.e. it would use more SURBs than sent with the original message), the receiver will use a SURB to ask the sender for more SURBs. 
+
+What this means in practice is that files can now be sent via anonymous replies!  
+