Everyone,
Nym, along with Zingo Wallet and Nighthawk, has applied for a grant to integrate a network-level anonymous channel - the Nym mixnet - into ZCash. Nym background here: https://nymtech.net
We submitted a months ago and have just hired the mobile devs needed to help see this through.
Applicant background:
Nym Technologies is a company based in Neuchatel in Switzerland specializing in developing Privacy Technologies. The company was founded in 2018 and has raised multiple rounds of capital, most recently 30m of public funding in February 2022. The company has 40+ employees across the globe and has launched its mixnet infrastructure in Summer 2022.
The Nym team includes a number of expert researchers in the domain of privacy-enhancing technologies and network-level privacy, including Claudia Diaz and Ania Piotrowska. Claudia Diaz has done seminal work on network-level privacy from mixnets to fingerprinting attacks. Ania Piotrowska designed Loopix, the most advanced mixnet design to date, which Nym is based on. Harry Halpin worked with both of them to start Nym after meeting in PANORAMIX, the five-year European Commission project to build a mixnet that would be able to withstand attacks by a global passive adversary after the Snowden revelations showed that such an adversary was realistic, and it is outside Torâs threat model. The Nym development team is formed from expert programmers such as Mark Sinclair, who leads a team of core Rust and Go cryptographic engineers along with front-end developers and integration developers.
Members of the Nym team have been active in the Zcash community forums, attended events such as Zcon, have worked with members of Bootstrap (Electric Coin Company) to run nodes, done the first extensive user study of Zcash wallet usage, and discussed this proposal extensively with members of Zcash founding team such as Madars Virza and Eran Tomer. Zcashâs underlying codebase does not support SOCKS5 and thus development effort is needed for Zcash integration, this is work that the Nym team is very comfortable with.
Nighthawk and ZingoLabs are two of the most used wallets in the ZCash eco-system, so integrating the Nym mixnet against them will help make sure network-level privacy is available to ZCash users.
Description of Problem or Opportunity:
We will provide Zcash users with state-of-the-art network-level privacy, without compromising the reliability or usability of the Zcash network, by using the Nym Mixnet. Although shielded Zcash is state-of-the-art for defending user privacy against attackers with access to a copy of the blockchain, shielded Zcash is not enough to defend against attacks at the network level, i.e. the stream of TCP/IP packets used to submit transactions (for full-nodes) and read the Zcash blockchain (for light wallets). These attacks are not unrealistic: ISPs can easily snoop on network traffic to passively record Zcash activity, and adversaries such as Chainalysis have the ability to do both passive surveillance of the large portion of p2p traffic in a network (as it was revealed it had done to the much larger Bitcoin p2p network) and active attacks. The importance of network-level privacy is explicitly called out even in the original Zerocash paper (Section 6.4). Therefore, in order to have holistic privacy for their usage of shielded Zcash, Zcash needs to support network-level privacy.
We present a quick summary of the network-level privacy topics below:
-
Without network-level privacy protection, the node to which a wallet transaction is submitted would know the time and the IP address of the wallet user. This in itself is undesirable, opening the user to targeted attacks.
-
Similarly, network-level adversaries such as system administrators, ISPs, and other entities with access to intermediate parts of the infrastructure can obtain network-level information about the Zcash user.
-
If the timing data from the full node is combined with the blockchain data, statistical disclosure attacks [Danezis03] may compromise a frequent Zcash user (i.e. link the userâs IP address to the transactions.
What are the options that Zcash has to offer network-level privacy to users?
-
Encourage users to use a VPN. The benefits of this are clear: while the userâs IP address is hidden from the blockchain node, this option a) requires full trust of the VPN proxy and b) does very little against network-level adversaries.
-
The Tor network is widely deployed and has been functioning for a number of years (the first research prototype was built as far back as 1996!); it has a large user base, and is highly suitable for web-browsing use cases. Although a user submitting a Zcash transaction using Tor (or a VPN for that matter), would prevent their IP address from being disclosed to the blockchain node, it offers weak protection against network-level adversaries which can mount a correlation attack. More specifically, the fact that Torâs design is circuit-based, enables end-to-end correlation based on circuit start/end timings and any traffic patterns in the flow. A network adversary can exploit these features to correlate the two ends of a circuit, defeating the anonymity provided by the re-routing of data. An adversary can likely distinguish a âZcash circuitâ from a âwebsite browsing circuitâ based on traffic fingerprint features). Stolon, a proposed variant of Dandelion that relays new transactions over Tor connections, inherits the weaker threat model of Tor and does not defend against an adversary that is watching both nodes involved in the âsteamâ phase of Dandelion. In p2p networks like Zcash this is a realistic threat.
-
Nym is per-packet and is hence optimized for provisioning maximum network-level privacy for applications like cryptocurrency transactions. Furthermore, the cover traffic introduced by a nym client not only disguises the timing of the transaction but also mixes it with the traffic on the nym network generated by other applications, hence providing a significant amount of protection, even against statistical disclosure attacks for frequent Zcash users.
In May 2022 a new major release of Zcash has introduced the auto-shielding feature Halo Arc for Zcash proposed for release later this year - Electric Coin Company. Unless this is accompanied by a strong network-level privacy layer, it would permit adversaries to fingerprint Zcash users. That is, an adversary would obtain the userâs t-address (or extract it from the unified address), send a transaction to it, and observe the userâs wallet broadcasting the t2z auto-shielding transaction. Note that the adversary can easily repeat this process and thus obtain finer granularity IP measurements and track those over time.
The usage of Nym should not compromise the reliability of the Zcash network or degrade user experience. To address such issues, the Nym network incentivizes the network participants (i.e. those running mix nodes, gateways, etc.) to behave reliably and efficiently handle traffic. This is a unique feature of Nym, allowing the network to scale with demand.
Similarly, usage of the Nym network should be affordable and sustainable for Zcash users, hence this grant includes a provision for Nym to provide bandwidth to Zcash users worth over 100k NYM [Nym is flexible on this point]; if it runs out we envisage a per-transaction fee model where a flat fee (i.e. independent of the value of the transaction) is paid to the Nym network for providing network-level privacy.
Proposed Solution: Describe the solution at a high level.
The Nym mixnet is a real-world deployed mixnet that offers stronger privacy protection for message-based transactions (such as cryptocurrency) than Tor, Dandelion, or I2P. In particular, Nym defends against both a global passive adversary that can observe the entire network, as well as provide increased privacy against fingerprinting of Zcash usage by local adversaries. It has extensive documentation available here: Introduction - Nym Docs
Nym distinguishes itself by considering a strong, and in our mind, very realistic, threat model: it aims to protect users who have repeated interactions (sending z2z transactions to or receiving z2z payments from) with an active adversary with network-level visibility. This threat model, for example, covers the Fleshlight attack (Ian Miers 2018, https://www.youtube.com/watch?v=9s3EbSKDA3o) which seeks to deanonymize merchants who accept electronic payments.
In essence, mixnets de-link senders (as well as receivers) from the transaction (just like, say, the zk-SNARK Spend proofs unlink the senderâs identity) via 1) multiple hops, 2) mixing traffic on a per-packet basis, and 3) adding dummy traffic. Both Tor and Nym use three hops (or more, in Nymâs case). Unlike Tor circuits that focus on effectively obfuscating an IP address, mix-nets are packet-based and so have much higher entropy and privacy than Tor as Nym also obscures the timing and volume of network traffic flow. Unlike Tor where all packets are delivered in a FIFO order, mix-nets âmixâ packets (like shuffling a deck of cards) for an amount of time and so packet order is obfuscated. Even if there are fewer users than Tor, mixnets can provide higher privacy in terms of entropy against global passive adversaries via mixing dummy traffic. Note that unlike the undeployed Meson mixnet (a fork of the Katzenpost mixnet), Nym allows the optimization of dummy traffic based on existing traffic flows to prevent statistical disclosure attacks. We believe dummy traffic and the use of the Sphinx packet format by Nym (also used in Lightning) also allow packets to be more resistant to ISP fingerprinting than Tor. Lastly, Nym is source-routed and so the amount of mixing and delays can be set by the client software to optimize the latency vs. privacy tradeoff on a per-application basis. Like Tor, Nym supports a wide variety of applications via âplug and playâ proxies like SOCKS5, and so is already being used by Bitcoin wallets (e.g. Electrum). Latency delays can be set for milliseconds, seconds, or even minutes, and hence even relatively small numbers of users with infrequent usage can still obtain reasonable entropy (based on our simulations).
We also note that mixnet privacy has a guarantee â a single point of success â similar to Zcashâs setup ceremony guarantee: it is sufficient for at least one mixnet node to provide strong uncorrelated entropy for the output to be statistically indistinguishable. Currently, alternatives like Tor and I2P cannot make guarantees of network-level anonymity in terms of entropy. Although some Tor co-founders have argued that entropy is not the best measurement and resistance to only local (and possibly mobile) adversaries is the current more realistic threat model, (https://mail.freehaven.net/anonbib/cache/entropist.pdf), we think that protection against the global passive adversary gives additional comfort.
The Nym network is fully operational. All the features to ensure the privacy guarantees required by Zcash are already live. Further efficiency and security improvements are in active development. Other integrations with applications such as Keybase and Electrum already exist, and there are discussions with multiple other cryptocurrencies and browsers such as Brave. Our research team is also planning to study the real-world effects of mixing by measuring the aggregate input and output traffic.
Solution Format: What is the exact form of the final deliverable youâre creating?
There will be integration with Nym into at least two, and possibly three, Zcash-enabled wallets. The first two wallets to support Nym would be Nighthawk Wallet and Zingo! Labs. New infrastructure for Nym would work by providing infrastructure such as service providers and gateways for these wallets, and the Nym team would work to parameterize the Zcash traffic correctly so that it has a reasonable amount of privacy traded off for latency. There would be native integrations, which would require possibly adaptions in the Nym codebase and SDK. The integration will enable Nym by default, although the user may be free to toggle Nym support off and on and may also have the option to use Tor. Two wallets would work as sub-contractors, namely Zingo! Labs and Nighthawk Apps. Another would be a separate unfunded integration, i.e. the upcoming wallet from ECC.
Technical Approach: Dive into the how of your project. Describe your approaches, components, workflows, methodology, etc. Bullet points and diagrams are appreciated!
The Nym mixnet is a real-world deployed mixnet that offers stronger privacy protection for message-based transactions (such as cryptocurrency) than Tor, Dandelion, or I2P. In particular, Nym defends against both a global passive adversary that can observe the entire network, as well as provide increased privacy against fingerprinting of Zcash usage by local adversaries.
Nym distinguishes itself by considering a strong, and in our mind, very realistic, threat model: it aims to protect users who have repeated interactions (sending z2z transactions to or receiving z2z payments from) with an active adversary with network-level visibility. This threat model, for example, covers the Fleshlight attack (Ian Miers 2018, https://www.youtube.com/watch?v=9s3EbSKDA3o) which seeks to deanonymize merchants who accept electronic payments.
In essence, mixnets de-link senders (as well as receivers) from the transaction (just like, say, the zk-SNARK Spend proofs unlink the senderâs identity) via 1) multiple hops, 2) mixing traffic on a per-packet basis, and 3) adding dummy traffic. Both Tor and Nym use three hops. Unlike Tor circuits that focus on effectively obfuscating an IP address, mix-nets are packet-based and so have much higher entropy and privacy than Tor as Nym also obscures the timing and volume of network traffic flow. Unlike Tor where all packets are delivered in a FIFO order, mix-nets âmixâ packets (like shuffling a deck of cards) for an amount of time and so packet order is obfuscated. Even if there are fewer users than Tor, mixnets can provide higher privacy in terms of entropy against global passive adversaries via mixing dummy traffic. Note that, unlike other mixnets, Nym allows the optimization of dummy traffic based on existing traffic flows to prevent statistical disclosure attacks. We believe dummy traffic and the use of the Sphinx packet format by Nym also allow packets to be more resistant to ISP fingerprinting than Tor. Lastly, Nym is source-routed and so the amount of mixing and delays can be set by the client software to optimize the latency vs. privacy tradeoff on a per-application basis. Like Tor, Nym supports a wide variety of applications via âplug and playâ proxies like SOCKS5, and so can already be used by Bitcoin wallets (e.g. Electrum and Blockstream Green). Latency delays can be set for milliseconds, seconds, or even minutes, and hence even relatively small numbers of users with infrequent usage can still obtain reasonable entropy (based on our simulations).
We also note that mixnet privacy has a guarantee â a single point of success â similar to Zcashâs setup ceremony guarantee: it is sufficient for at least one mixnet node to provide strong uncorrelated entropy for the output to be statistically indistinguishable. Currently, alternatives like Tor and I2P cannot make guarantees of network-level anonymity in terms of entropy. Although some Tor co-founders have argued that entropy is not the best measurement and resistance to only local (and possibly mobile) adversaries is the current more realistic threat model, (https://mail.freehaven.net/anonbib/cache/entropist.pdf), we think that protection against the global passive adversary gives additional comfort.
The Nym network is live and fully operational, yet is in active development with further efficiency and security improvements in the pipeline. Yet all the features to ensure the privacy guarantees required by ZCash are already live. Other integrations with applications such as Keybase and Electrum already exist, and there are discussions with multiple other cryptocurrencies. Our research team is also planning to carefully study the real-world effects of mixing by measuring the aggregate input and output traffic.
Dependencies: What external entities is your project dependent on? What involvement is required from ZF, ECC, and/or other external organizations? Who would have to incorporate your work in order for it to be usable?
We would be dependent on Nighthawk Wallet developers and Zingo! Labs wallet developers, and to a lesser extent ECC. However, Nighthawk Apps nd Zingo! Labs have already agreed to incorporate the Nym mixnet and have an estimated budget for developers. ECC cannot receive funding. There is a dependency on Zcash Foundation if there is an attempt to add zebrad support.
Execution risks: What obstacles do you expect? What is most likely to go wrong? Which unknown factors could jeopardize success? Who would have to incorporate your work in order for it to be usable?
The primary risk the Nym team runs is the lack of acceptance of pull requests by the Zcash wallet developers of ECC, Nighthawk Apps, and Zingo!, as well as zcashd. We view this risk as low, and it would be mitigated by agreeing on the design of the Nym integration jointly with the Zcash core developers and Zingo!Labs Viridian. Similarly, it would be beneficial to agree on the UX experience of using Nym (though we envisage the UX to be very simple), with wallet developers upfront. Our general belief is that users should be given options for network-level privacy, although it would also be attractive to make these as invisible as possible and to enable âprivacy by default.â However, for the scope of this grant we would want it to be an opt-in/opt-out feature (up to app developers) with an easy âoff-onâ switch users can toggle. In terms of zcashd, we could integrate with z_sendmany RPC call to send transactions over the Nym mixnet when suitably configured. As zebrad matures, we could also eventually in a later extension of this project integrate against zebrad in addition to zcashd, and zebrasâs modular design should make this easier. As Nymâs software is in Rust, integration should be straightforward.
A secondary risk would be the maturity of the Nym network itself. As detailed in the blog post by the Zcash Foundation, https://www.zfnd.org/blog/mixnet-production-readiness/, there have been concerns that the Nym network itself would not be able to support shielded Zcash usage. However, Nym has several hundred mix nodes (around likely the same as Zcash full nodes) and can actively handle 1000s of tx per second, therefore we can easily handle current and future amounts of the shielded Zcash transactions.
A third risk is that there is a fundamental underlying incompatibility between our approach and Zcashâs design or implementation that prevents network-level privacy, such as issues in terms of wallet communication or the inability of Nym to work with core third-party libraries that Zcash relies on (such as gRPC for light wallet clients). However, we believe all these issues are solvable and our team is already in good communication wit the Nighthawk Apps team and ZingoLabs Viridian.
Unintended Consequences: What are the negative ramifications if your project is successful? Consider usability, stability, privacy, integrity, availability, decentralization, interoperability, maintainability, technical debt, requisite education, etc.
Note as Nym would be an optional feature (although we would envisage it to be on by default), the negative effects would be very limited, i.e. in the worst case scenario, Zcash wallet / full node users could simply turn it off (and indeed, in an event some kind of failure is detected, this would be done automatically).
Nevertheless, with the Nym network fully operational, we would see users experiencing higher bandwidth usage (due to cover traffic) and a very small amount of added complexity in the UI. Although the grant would cover the costs of the Nym infrastructure for the foreseeable future, later the users would be exposed to small transaction fees to Nym (or this could again be covered by Zcash).
However, the benefits of a) Strong network level privacy b) Education of Zcash users about network privacy, and c) Decreased reliance on existing solutions such as Tor in our view far outweigh the potential downsides.
Evaluation plan: What metrics for success will you share with the community once youâre done? In addition to quantitative metrics, what qualitative metrics will you commit to report?
The project will be successful if a) The Nym network integration is included in as many wallets as possible b) turned on by default c) is utilized by many users and d) the network continues to be reliable and supports a growing volume of traffic.
All of the above are easy to monitor â a) and b) are self-explanatory; to gauge c) we could simply add a transaction counter to the network requestor (releasing aggregated stats only over a significant time period, e.g. monthly/weekly) and d) comes from standard Nym network monitoring.
To be very concrete, we would consider this project a full success if the wallets as well as full node developers agree to turn the Nym integration on by default and hence we see >30% of the Zcash shielded wallet transactions on the wallet benefitting from Nym-grade network privacy if offered as an optional feature. If it was a default feature then we would prefer to see >80% shielded wallet transactions from the wallet using Nym mixnet.
Hardware/Software total budget:
$0.00 USD
Please provide justification for the total hardware/software budget:
Note that wallets already run their own full nodes so there is no need for additional funding.
Services total budget (cloud, hosting, etc.):
$0.00 USD
Please provide justification for the total services budget:
N/A
Compensation total budget:
$670000.00 USD
Please provide justification for the total compensation budget:
Total Compensation Budget
We consider Zcash integration as one of the core use cases for network privacy and hence would like to run this project on a standalone basis, separately from the rest of the Nym roadmap (module management oversight). This would ensure that business prioritization of Nym (including integration demands from other projects) has no impact on the Zcash integration project. We are able to do this because the Nym mixnet is already mature enough to a) provide the necessary privacy properties and b) handle the volume of traffic, so the risks to the project are low. We see the project as being made up of the following stages:
-
POC. We anticipate that building a proof of concept component with the aim of submitting test transactions would be relatively straightforward to build. Around 1 month of setup, integration, development, and testing should be sufficient. Cost order of 20k USD. (83 USD per dev, per day)
-
Designing and agreeing to designs with wallet and infrastructure developers can be time-consuming and costly; we anticipate this taking between 1 and 3 months depending on the number of wallets. We are happy to commit to 2 wallet integrations as part of this project, depending on the responsiveness of the wallet developers. We budget 25k USD for this portion with 30k budgeted for Nighthawk Apps with their lightwalletd deployment experience, 30k for this part of the project as a subcontract to ZingoLabs Viridian. (177 USD per dev, per day)
-
3-6 are development phases; We plan to allocate 1 developer for 6m; cost of approx 75k USD for Nym. Nighthawk Wallet will allocate two developers, one each for iOS and Android for a period of 3-4 months with a cost of 80k for development and integrating Nym APIs. On Zingo!âs side, it will 80k for 8 developer months. (245 USD per dev, per day)
-
Testing and user acceptance: This necessitates both technical testing and attention from the project management team as well as the research team to determine ideal latencies/privacy for users given constraints; 2 people: 30k USD for Nym. Nighthawk User Acceptance Testing will cost 20k. Zingo! User Acceptance Testing will cost 20k. (172 USD per dev, per day)
-
Beta testing + Releases + any contingency/slippage costs. We plan to limit the costs to 25k; any additional costs would be taken by the Nym team. If the project is fully on schedule and contingency costs are lower, the remaining amount will be added to the next item. Nighthawk Wallet with its native Android and iOS integrations will cost 30k for integration testing, review, and release support. On Zingo!âs side, this will be 30k. (266 USD per dev, per day)
-
Following discussions with stakeholders in the Zcash ecosystem, in this application we are also including costs of provision of Nym privacy service from the start of the testing phase till at least the end of 2025 or longer, as budget allows. We request 100k USD converted into $NYM for this purpose and commit to reporting regularly on the usage of the mixnetâs impact on these funds. (266 USD per dev, per day)
-
Security Audit costs. We believe that the mixnet itself and the integration with any Zcash-facing software should have a security audit. Therefore, there should be an additional 75k in aunym dit costs as the audit will cover both Nym and the wallet integrations.
ZingoLabs specific Compensation:
Our preliminary analysis is that nym integration will require significant up front effort from our team.
This assessment hinges on two points:
- necessary work tracked by the grant that is prerequisite to integration:
e.g. a secure connection to the client
- necessary work that is not tracked by the grant:
e.g. reliable access to the testnet
Given our belief that there are significant unknown unknowns (testnet was not out of the box trivial to run), we plan to allocate a full time developer to nym integration and support for the next year. Additionally we will allocate more resources during feature development (the actual integration).
This amounts to slightly more than 1 developer full time for the duration of the grant.
So, we are proposing that the community will get approximately 1.25 developers for 1 year that are focused (one full time, and one during intensive phases).
It is our assumption that our team will lead on implementing the necessary Rust APIs that other wallets can then use. This is consistent with our work providing upstream libraries with necessary functionality, like the orchard transaction builder that we provided for librustzcash:
Additionally, itâs our assumption that our team will provide test infrastructure that protects the community from bugs like the BOBA bug that affected the most widely used mobile platforms in developing nations.
Because nym support will necessitate the production of more community-protecting test infrastructure, we have factored that effort into the (already initiated and ongoing) work that we anticipate for this grant.
We guess based on the effort we have expended on BOBA simulation and prevention, that this will amount to roughly .75 engineers for the duration.
In sum: 2-years of engineering effort for 160k
Nighthawk Apps specific Compensation:
In order to effectively execute the proposed project and achieve the desired outcomes, we request the following team compensation for the designated time frame:
- Designing and formalizing API designs with wallet and infrastructure developers: 2 months
- Compensation: $30,000
- Developing and integrating Nym APIs with gRPC client on mobile: Native iOS: 4 months & Native Android: 4 months
- Compensation: $80,000
- Testing and User Acceptance: Nym+lightwatted backend network diagnostics 1 month, Native clients: 1 month each
- Compensation: $20,000
- Beta testing, Public Releases, and contingency/slippage timeframe: Native clients: 1 month each
- Compensation: $30,000
Total targeted effort: 15 months time frame
- Total Compensation: $160,000
The integration of the Nym network into Nighthawk Wallet 2.0 is a crucial step towards achieving network-level privacy and enhancing our productâs functionality. With our extensive experience in running the lightwalletd infrastructure and testnet setup, we are well-equipped to collaborate effectively with Nym network engineers and facilitate cross-functional teamwork with our dedicated native app developers.
We kindly request your support in providing the above-mentioned team compensation, which aligns with the Nighthawk Apps Roadmap and our shared goals for the projectâs success. Thank you for considering our grant application, and we look forward to the opportunity to contribute to the growth and advancement of the Nym network.
Do you require startup funding?
No
Milestone 1 - estimated completion date:
02/08/2024
Milestone 1 - USD value of payout upon completion of deliverables:
$20000.00
Deliverable 1.1
Ramp-up, resource allocation, and information gathering. Create the improved threat model and design document.
Deliverable 1.2
Add Nym Service Provider and test by submitting test transactions through the Mixnet.
Milestone 2 - estimated completion date:
03/08/2024
Milestone 2 - USD value of payout upon completion of deliverables:
$85000.00
Deliverable 2.1
Produce specifications for wallet integrations and reach a consensus with wallet developers.
Milestone 3 - USD value of payout upon completion of deliverables:
$235000.00
Milestone 3 - estimated completion date:
12/08/2024
Deliverable 3.1
For full nodes â do tx submission over Nym using str4dâs code. [rpc] -txsend config option for sending transactions via an external command by str4d ¡ Pull Request #4522 ¡ zcash/zcash ¡ GitHub This is private as the transaction never enters the mempool but we need to build a logic around retrying (currently, a malicious node could drop transactions to DoS).
Deliverable 3.2
Z_sendmany configure local node in non-broadcast node, then grab not from the broadcast.
Deliverable 3.3
Integrate Light Wallets (Zingo and Nighthawk)g as per specifications in 2) with the production of HTTPS Proxy
Milestone 4 - USD value of payout upon completion of deliverables:
$255000.00
Milestone 4 - estimated completion date:
11/07/2025
Deliverable 4.1
Testing and user acceptance with the developer community, the release of a report on ideal mixing latencies for privacy.
Deliverable 4.2
Beta Release and testing; Contingency and Allowance for slippage
Deliverable 4.3
Following discussions with members of the ZCash team, in this application we are also including costs of provision of Nym privacy service from the start of the testing phase till at least the end of 2025 or longer, as budget allows. We ask for 100k USD converted into $NYM for this purpose and commit to reporting regularly on the usage of the mixnetâs impact on these funds.
Milestone 5 - estimated completion date:
12/12/2025
Milestone 5 - USD value of payout upon completion of deliverables:
$75000.00
Deliverable 5.1
Security audit of integrations
Total proposed USD value of grant:
$670000.00 USD
How was the project timeline determined?
The timeline was developed based on our previous experience in integrating Nym against wallets and full nodes. In particular, we have tried to be realistic and so budgeted a large amount of time for the light wallet integration (6 months) as well as 2 months of slippage. The timeline was also discussed with Nighthawk Apps and Zingo!Labs to see if they think itâs realistic. Of course, there may be delays in both the Nighthawk Wallet and Zingo! Wallet release, which could cause delays in the integration.
