| 
| 
| 
| 
| 
|
-| :-: | :-: | :-: | :-: | :-: | :-: |
-| [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [Web 3.0 Reddit](https://www.reddit.com/r/web3) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) |
+We have a Matrix channel for grant-related questions and activities. Head over there to ask grants-related questions, share your experience with other applications and grantees, or simply hang out:
-### Real-time conversation
+- [W3F Grants Community](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org)
-We have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation.
+We also have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation!
- [Web3 Foundation Chat](https://matrix.to/#/#w3f:matrix.org)
- [Polkadot Space](https://matrix.to/#/#polkadot:web3.foundation)
- [Kusama Space](https://matrix.to/#/#kusama:web3.foundation)
-Besides, we also have a **community room for all grant recipients**. Head over to that room to share your experience with other grantees, ask grants-related questions or simply hang out:
-
-- [W3F Grants Community](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org)
-
### Office Hours
Web3 Foundation Grants Office Hours are a chance to ask the grants team questions regarding a specific (potential) grant application. It offers
@@ -261,6 +254,16 @@ Apply for Office Hours if you
It is **not** a chance to pitch your project, especially since only a small subset of the committee will participate in the call. To apply, please fill out the [Office Hours :alarm_clock: form](https://forms.gle/54xkiqU37WwdN9UR6). Be as specific as possible, so we can help you more quickly. We will get back to you with follow-up questions or a link for booking a timeslot.
+### Additional Information
+
+
| 
| 
| 
| 
|
+| :-: | :-: | :-: | :-: | :-: |
+| [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) |
+
+
| 
+
+**Solution on Static Project Pages**
+
+On Awesome Polka, project owners can manage their project pages, which include several modules such as:
+
+- Project Description
+- Token Stats
+- GitHub Stats
+- Team Info
+- Latest Articles
+- Frequently Asked Questions
+- Job Postings
+
+The number of these modules will be increased and further developed.
+
+Project owners can update their project page using these modules. In the future, additional modules can be added based on the needs of the ecosystem.
+
+In summary, project pages on Awesome Polka are highly customizable, allowing project owners to showcase their projects using a variety of modules. By providing these modules, Awesome Polka enables project owners to provide up-to-date information about their projects and engage with the ecosystem more effectively.
+
+**Improvement on Educational Materials & Articles**
+
+Awesome Polka offers a platform for project owners to publish educational materials and articles to inform and engage with the ecosystem. With the built-in editor, project owners can create compelling content that keeps their audience up-to-date on the latest developments in their projects. By providing these tools, Awesome Polka helps to create a more informed and engaged community.
+
+**Improvement on Ecosystem Partner Rights**
+
+Ecosystem partners play a crucial role in ensuring the sustainability of the Awesome Polka platform. By giving them admin rights, they can help manage the platform and ensure that it meets the needs of the community. The committee responsible for this role will be selected based on their ability to review and manage projects effectively.
+
+#### Technology Stack
+
+- AWS App Sync (GraphQL)
+- AWS Amplify
+- Next.js
+- Additional Tools & Frameworks
+ - Redux
+ - Tailwind CSS
+ - Magic (Web3 Auth & Wallet)
+ - Algolia (Search Infrastructure)
+
+#### Documentation
+
+Once all project milestones have been accomplished, we will create and publish comprehensive technical documentation that provides all the necessary information for end users to fully understand the system and its capabilities.
+
+#### PoC/MVP or other relevant prior work or research on the topic
+
+**Awesome Polka MVP Link:** https://dev.awesomepolka.org
+
+### Ecosystem Fit
+
+- **Where and how does your project fit into the ecosystem?**
+
+ Polkadot's [User Interface section](https://wiki.polkadot.network/docs/build-open-source#user-interface) is the ideal place to start for the Awesome Polka project, offering the best opportunity for success.
+
+- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?**
+
+ Awesome Polka targets a diverse range of audiences, including individuals who are interested in learning about Polkadot projects and their latest updates. This includes investors, enthusiasts, and other stakeholders who want to stay up-to-date with the developments in the Polkadot ecosystem.
+
+ In addition to individuals, Awesome Polka also targets both early-stage and live projects on the Polkadot ecosystem. By providing a comprehensive platform that supports projects of all sizes, Awesome Polka aims to support the growth and development of the entire Polkadot ecosystem.
+
+ Furthermore, Awesome Polka also targets ecosystem partners such as DAOs who can help to make the platform more sustainable and aligned with their vision. By engaging with the community and involving ecosystem partners in the management of the platform, Awesome Polka aims to create a more collaborative and impactful platform that benefits everyone involved in the Polkadot ecosystem.
+
+- **What need(s) does your project meet?**
+
+ Awesome Polka meets the needs I mentioned in the solution section above, but if I have to write it as a summary, it covers the following:
+
+ - **Sustainable project management:** The project ensures sustainable project management by providing a comprehensive and structured approach to project management. This approach includes planning, execution, monitoring, and control of project activities, which helps to achieve project goals while minimizing risks and resource wastage.
+
+ - **Strong SEO optimization:** The project meets the need for strong SEO optimization by implementing best practices for on-page and off-page SEO. This includes optimizing content for keywords, ensuring site speed and mobile responsiveness, and building high-quality backlinks to improve search engine rankings and visibility.
+
+ - **Fresh and easy-to-use UI:** The project meets the need for a fresh and easy-to-use UI by providing a user-friendly interface that is intuitive and easy to navigate. This helps to enhance the user experience and encourages users to engage with the project more frequently.
+
+ - **Efficient and lightning-fast search infrastructure:** The project meets the need for efficient and lightning-fast search infrastructure by implementing a robust search system that enables users to find the information they need quickly and easily. This ensures that users can access the project's content and resources without delays, which improves overall usability and satisfaction.
+
+ - **Detailed project modules:** The project meets the need for detailed project modules by providing comprehensive information on various project aspects such as token stats, GitHub activity, job postings, and so on. This helps users to stay informed about project updates and developments, which enhances transparency and trust in the project.
+
+- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?**
+ - **If so, how is your project different?**
+ - Yes, I found a similar project called Polka Project, there may be other projects, but let me tell you about the differentiating aspects of Awesome Polka.
+ - Detailed filtering and search options for easier and efficient project discovery
+ - Ability for projects to use modules for article sharing and job postings and so on
+ - Display of GitHub repository information and statistics
+ - Display of token information, including market capitalization, total volume, and price
+ - A learning section with resources for the Polkadot ecosystem
+ - Sharing of project team information.
+ - Dashboard for Projects Owners and Admins to manage platform sustainable.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Tolga Yaycı
+
+### Contact
+
+- **Contact Name:** Tolga Yaycı
+- **Contact Email:** [tolgayayci@protonmail.com](mailto:tolgayayci@protonmail.com)
+- **Website:** [LinkedIn](https://www.linkedin.com/in/tolgayayci/)
+
+### Legal Structure
+
+- **Registered Address:** -
+- **Registered Legal Entity:** -
+
+### Team's experience
+
+As a full-stack developer with 2 years of experience, I have honed my skills in software development, with a focus on dApp development in the past year. I have a deep interest in the Web3 and NFT space and have put my skills to the test by creating a number of relevant applications. In addition to my experience, I have developed detailed React and Next.js projects, further enhancing my ability to build robust and scalable web applications.
+
+In addition to my technical skills, I have also been actively involved in the wider tech community. I have served as a Chainlink Community Advocate, Aave Turkey Community Manager, and Founding Chair of Gazi University ACM Student Chapter. My previous role as a Microsoft Learn Student Ambassador has also given me the opportunity to share my knowledge and experience with others. I have set of experiences and skills and particularly in the areas of full stack software development and community management.
+
+### Team Code Repos
+
+- https://github.com/tolgayayci/awesome-polka/tree/dev
+- https://github.com/tolgayayci
+
+### Team LinkedIn Profiles
+
+- https://www.linkedin.com/in/tolgayayci
+
+
+## Development Status :open_book:
+
+The user interface and search infrastructure of this project are largely complete and ready for discovery. To get a glimpse of the minimum viable product (MVP), you can either take a look at the repository or visit the website.
+
+
+
+## Development Roadmap :nut_and_bolt:
+
+This project is planned as 1 milestone, it will be completed in one months.
+
+- **Total Estimated Duration:** ~1 month
+- **Full-Time Equivalent (FTE):** 1
+- **Total Costs:** 10,000 USD
+
+### Milestone 1
+
+- **Estimated duration:** 1 month
+- **FTE:** 1
+- **Costs:** 10,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | Unlicense |
+| **0b.** | Documentation | I will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. |
+| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. |
+| **0d.** | Docker | I will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
+| **0e.** | Article | I will publish an **article**/workshop that explains what was done/achieved as part of the grant. |
+| **1.** | UI & UX Development | **Home Page:** Visually appealing and user-friendly homepage which includes latest articles, popular categories and many more 
+
+The raw keys (e.g. `0x26aa394eea5630e0...f1dbd372bbe532b1f8702b2a7e`) and values (e.g. `0x01ab50050...000000000000`) are decoded using the chains type spec into
+
+```
+Key: [ "12xtAYsRUrmbniiWQqJtECiBQrMn8AypQcXhnQAc6RB6XkLW" ]
+Value: {
+ "nonce": 348331,
+ "consumers": 2,
+ "providers": 1,
+ "sufficients": 0,
+ "data": ⊖{
+ "free": "0x000000000000000005785a9c9f9ad21b",
+ "reserved": 0,
+ "miscFrozen": "0x00000000000000000058d15e17628000",
+ "feeFrozen": "0x00000000000000000058d15e17628000"
+ }
+}
+```
+
+and loaded into BigQuery as part of a publicly available [substrate-etl](https://console.cloud.google.com/bigquery/analytics-hub/exchanges/projects/974572213039/locations/us/dataExchanges/substrate_18804f88005), recently added to Google BigQuery's Public Datasets in May 2023.
+
+
+
+In Milestone 1, we will provide a 3 tier solution to deep account analytics on Account References. Here is how the 3 tiers:
+
+* Tier 1 requires *raw indexing* of traces. Traces are critical to Colorful Notion's [XCM Indexing](https://polkaholic.io/xcmtransfers?xcmType=xcmtransfer) and are important for parachain engineers to understand how the execution of a block, and are critical to the model producers, consumers and sufficients. As raw traces form a very large dataset, to keep storage costs low, the indexer filters out pallets section/method that and exposes them in `crypto_polkadot.traces0` ([see schema](https://github.com/colorfulnotion/polkaholic/blob/main/substrate/schema/substrateetl/traces.json)). In particular, given how central accounts and native and non-native tokens are to blockchain usage, the indexer further decodes accounts and asset state into many additional columns like free, reserved and frozen.
+
+* Tier 2 requires *deep indexing* of the above trace data, to analyze how certain attributes changed in [System:Account](https://docs.google.com/spreadsheets/d/1jywN--pONmJqmbuASWDLNdBvsB86OuizJnQ72ijAXSU/edit#gid=704412439) holding account reference counters, account balance reserved provenance (see: https://docs.substrate.io/reference/account-data-structures/). We have some preliminary work on this (see [this sheet](https://docs.google.com/spreadsheets/d/1gZZOvH4BYk2QYlhzz9AvRxiR6mcYtgRz9VZluz1lwuU/edit#gid=1313769699)) and proved that, yes, it is indeed possible to uniquely identify the extrinsic id (but not call id) for every trace, and that the changes can be identified to build a new dataset every day.
+
+* Tier 3 requires situating the above dataset into an Account Analysis Dashboard of [Apache Superset](https://analytics.polkaholic.io/dashboard/list/). Here we have a WASM Contract Explorer prototype:
+
+
+
+We envision Milestone 1 focussed on Account References and then extended in Milestone 2 to Democracy+Staking deep analysis. This will result in an Account Analysis Dashboard, with 3 or more account tabs exploring:
+
+* "Account References" concerning deep indexing developed in Milestone 1
+
+* "Democracy" concerning deep indexing about [Democracy:VotingOf](https://docs.google.com/spreadsheets/d/1hdvW5Kw3gwBnXqFskALX1_szdTf4pYL-SlbOqJ8tlO0/edit#gid=1803912396) developed in Milestone 2
+
+```
+{"direct":{"delegations":{"capital":0,"votes":0},"prior":[0,0],"votes":[[113,{"standard":{"vote":"0x81","balance":10000000000}}],[119,{"standard":{"vote":"0x82","balance":50000000000}}]]}}
+```
+
+OR
+
+```
+{"delegating":{"balance":15000000000,"conviction":"Locked4x","delegations":{"capital":0,"votes":0},"prior":[0,0],"target":"15ZvLonEseaWZNy8LDkXXj3Y8bmAjxCjwvpy4pXWSL4nGSBs"}}
+```
+
+* "Staking" concerning deep indexing about Staking and Nomination Pools, with the added complexity of stashing controller/accounts, developed in Milestone 2.
+
+It is straightforward to link these dashboards directly to polkaholic.io based the key (accountID/extrinsicID/...) and add filtering on any column present in the table with Apache Superset.
+
+Any UI can then link to this dashboard with the account ID, and the dashboard can link back to a block explorer.
+
+Once the dataset is made available, end users can build charts and dashboards with the same ease as they do in Excel or Google Sheets.
+
+The community dashboard can be used in the same way as Dune Analytics dashboards serves the EVM community.
+
+
+### Ecosystem Fit
+
+While this proposal does not explicitly require collaboration on any of the 3 tiers, our intention is to:
+1. set up a foundation where the Web3 Foundation could ask other teams to contribute datasets (Tier 2) and build dashboards (Tier 3) in the same way.
+2. set up a repeatable model between Web3 Foundation and a Polkadot Data Alliance support data-oriented research (W3F) and ongoing maintenance ([Polkadot Data Bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#)) with child bounties
+
+## Team :busts_in_silhouette:
+
+### Team members / Contact
+
+- **Contact Name:** Sourabh Niyogi / Michael Chung
+- **Contact Email:** sourabh@colorfulnotion.com / michael@colorfulnotion.com
+- **Website:** https://colorfulnotion.com
+
+### Legal Structure
+
+- **Registered Address:** 55 E 3rd Ave, San Mateo, CA 94401, USA
+- **Registered Legal Entity:** Colorful Notion, Inc.
+
+### Team's experience
+
+* Key engineers Sourabh Niyogi and Michael Chung have developed Polkaholic.io since Fall 2021 and substrate-etl since December 2022.
+
+* Prior to building Polkaholic.io, Sourabh and Michael worked in decentralized social networking protocol development + privacy-preserving contact tracing (Wolk),
+mobile advertising real-time bidding algorithm design and analytics (CrossChannel/MdotM).
+
+* Sourabh spent time doing computational cognitive science and machine vision research at MIT, including
+in [Bayesian learning of verb meaning and causal laws](https://scholar.google.com/citations?user=HHmGYdEAAAAJ&hl=en].
+
+* Michael hails from UC Berkeley with a degree in statistics and economics and leads deep indexing at Colorful Notion.
+
+### Team Code Repos
+
+- [substrate-etl](https://github.com/colorfulnotion/substrate-etl)
+- [Polkaholic.io](https://github.com/colorfulnotion/polkaholic)
+- [XCM Global Asset Registry](https://github.com/colorfulnotion/xcm-global-registry)
+- [Sourabh Niyogi](https://github.com/sourabhniyogi) | [Michael Chung](https://github.com/mkchungs)
+
+## Development Status :open_book:
+
+* Summer 2022: Released Polkaholic.io, a fully working Substrate-first multichain block explorer.
+* Fall 2022: Increased XCM Transfers Coverage, Improved UI + API based on feedback from users. Added EVM/WASM support.
+* Winter/Spring 2023: Developed substrate-etl and XCM Global Asset Registry.
+* May 2023: Google included Polkadot + Kusama in [Google Public Datasets](https://cloud.google.com/bigquery/public-data).
+
+## Development Roadmap :nut_and_bolt:
+
+This proposal aims to deliver on the three-tier architecture outlined in two milestones:
+
+* Milestone 1 will develop `System:Account` deep analytics.
+* Milestone 2 will develop `Democracy`, `Staking` and `NominationPools` deep analytics.
+
+For each Milestone, there are 3 kinds of deliverables corresponding to the 3 tiers:
+- 1. Raw indexes, in the form of BigQuery datasets which are delivered
+- 2. Deep indexes, in the form of BigQuery dataset
+- 3. Dashboard publication, in the form of Apache Superset Dashboard
+
+All raw and deep indexing code will be made open source within the polkaholic and substrate-etl repo.
+
+### Overview
+
+- **Total Estimated Duration:** 4 months
+- **Full-Time Equivalent (FTE):** 300 FTE hours [100 USD/hr]
+- **Total Costs:** 30,000 USD
+
+### Milestone 1 — Three Tier Deep Account Analytics on Account References
+
+- **Estimated duration:** 8 weeks (ending 8/31/23)
+- **FTE:** 150 FTE hours [100 USD/hr]
+- **Costs:** 15,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | GNUv3 - polkaholic + substrate-etl repo |
+| 0b. | Documentation | Provide README on construction of 1+2+3 |
+| 0c. | Manual Testing Guide | Manual testing guide with steps for using the application, with examples including expected inputs and outputs |
+| 1. | Raw Indexing | substrate-etl:crypto_polkadot.traces0 for 7/1/23 - 8/31/23 |
+| 2. | Deep Indexing | substrate-etl:substrate.accountreference0 and supporting datasets |
+| 3. | Dashboard Publication | Superset dashboard tab: "Account Reference" |
+
+We will take this opportunity to deliver raw indexes on traces, deep indexes on account references and a dashboard on Account References hosted at https://analytics.polkaholic.io.
+
+Indexing + Dashboard Publication must be able to support deep analysis of **Account References**:
+* Which transactions/accounts were responsible for the reserved balance in an account?
+* What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references?
+* What are the pallets responsible for reserves/holds and locks/freezes on an account?
+
+
+### Milestone 2 — Three Tier Deep Account Analysis of Democracy+Staking+Nomination Pools
+
+- **Estimated duration:** 8 weeks (ending 10/31/23)
+- **FTE:** 150 FTE hours [100 USD/hr]
+- **Costs:** 15,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | GNUv3 - polkaholic + substrate-etl repo |
+| 0b. | Documentation | Document substrate-etl README on 1+2+3 |
+| 0c. | Manual Testing Guide | Manual testing guide with steps for using the application, with examples including expected inputs and outputs |
+| 1. | Raw Indexing | BigQuery Index substrate-etl.crypto_polkadot.traces0 9/1/2023-10/31/23 -- stashing accounts |
+| 2. | Deep Indexing | BigQuery substrate-etl:substrate.democracy_* substrate-etl:substrate.staking_* substrate-etl:substrate.nomination_pools_* |
+| 3. | Dashboard Publication | Superset dashboard tabs: "Democracy", "Staking", "Nomination Pools" |
+
+We will take this opportunity to address the complexity of stashing accounts by:
+* Deep Indexing. Using the above tables in the views referencing `storage_staking_*, storage_nominationpools_*` tables
+* Dashboard Publication. Using the above, we can develop dashboards for Democracy+Staking+Nomination Pools
+
+Indexing + Dashboard Publication must be able to support deep analysis of Democracy and Staking/Nomination Pools pallets:
+* Democracy: Which accounts have delegated OpenGov votes to an account or to which accounts the account in question has delegated their votes to for each track?
+* Staking/Nomination Pools: Who are all the nominators that nominated Validator X? (an inverse mapping basically of staking.nominators from validator -> nominators) Who are the top 10 nominators with the highest APR, and which validators do they have in common?
+
+## Future Plans
+
+Broadly, this proposal sets up a path for the Web3 Foundation to have Polkadot Data Alliance contributors deliver results for the Web3 Foundation itself and the community in the following ways:
+
+1. within the three-tier architecture, Polkadot Data Alliance contibutors can collaborate with Web3 Foundation and others in the Substrate community using raw indexes, published deep indexes, or building and extending dashboards. Our technical choice for collaboration is BigQuery and Apache Superset but other choices may be equally viable or appropriate, by other teams.
+
+2. with the [Polkadot Data Alliance Bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#) and the [Web3 Foundation Maintance Grants](https://github.com/w3f/Grants-Program#hammer_and_wrench-maintenance-grants), there is a clear path to support both software maintainence _and_ hosting / data indexing infrastructure
+
+In followup work, we would expect to address the 3 tiers:
+* raw indexing: cover traces on a regular basis defined in child bounties
+* deep indexing: support the dataset deliverables on a regular basis
+* dashboards: maintain published dashboards developed, and host the Apache Superset
+
+We would welcome the challenge of doing followon high impact work, but hope that others in the Polkadot Data Alliance can follow this model as well.
+
+We propose a child bounty to host Apache Superset instance at https://analytics.polkadot.network or transfer this responsibility to a parent bounty curator.
+
+## Additional Information :heavy_plus_sign:
+
+We request suitable Web3 Foundation members be identified as parent
+and child bounty curator candidates, and that the charter for the
+Polkadot Data Alliance be developed in a collaboration with Parity.
+The Polkadot Data Alliance charter is [here](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#).
+
+We do not believe our participation (or anyone else's participation)
+in a Polkadot Data Alliance in providing deliverables at any of the
+three tiers eliminates the possibility of doing further data
+processing for other sources of additional revenue. Our goal is to be
+self-sufficient and not dependent on W3F Grants or Treasury funding,
+but we hope our value and commitment to sharing and collaboration is
+recognized by the community so we can be productive high impact
+contributors.
+
+
+
diff --git a/applications/Diffy_chat.md b/applications/Diffy_chat.md
new file mode 100644
index 00000000000..2999e71e599
--- /dev/null
+++ b/applications/Diffy_chat.md
@@ -0,0 +1,135 @@
+# Diffy messenger
+
+- **Team Name:** BelSoft
+- **Payment Address:** Polkadot (Statemint): 14nQH1ZTDkRxLWdCWbSZjRGrBJpXgj4m2RRZDtQZExPP73K (USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+This application complies with a potentially interesting project “Private instant messenger that uses on-chain identity” mentioned in [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) page in the “Social Networking” section.
+
+## Project Overview :page_facing_up:
+
+A lot of sensitive data is meant to be transferred between parties in a secure way, but most of the centralized messengers and mail agents, even secured ones, have a common point of vulnerability - a centralized database/backend that stores all the data and manages connections. Meanwhile, some entities or even industries as a whole have demand for secured private channels for exchanging messages, e.g. medical institutions, that exchange sensitive data with patients or with other market players.
+
+The aim of this project is to develop a secured decentralized messenger that doesn’t store data on a centralized backend and uses personal Polkadot wallet credentials for chatting initiation and messaging.
+
+### Project Details
+
+P2p channels between users will be set using WebRTC. We will develop a Substrate pallet for exchanging [SDP offers](https://datatracker.ietf.org/doc/html/rfc2327). For address discovery of NAT users we will use any public [STUN server](https://datatracker.ietf.org/doc/html/rfc8445).
+All messages between users will be encrypted with user’s public keys, so only receiving user could decrypt his messages using his private key of his Polkadot wallet.
+Also, the pallet will include a “contacts” feature: a user will be able to tie names to wallet addresses and organize his contacts in a common way.
+
+
+
+### Ecosystem Fit
+
+The Diffy chat dapp is very in demand in areas where it is crucial to protect personal and other critical data from unauthorized access during interaction or communication between counterparties. The target audience is very wide: from medical institutions providing telemedicine services to remote financial services and corporate channels for transmitting sensitive information between remote divisions.
+
+In the [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) we see the [Uke Protocol Pallet](https://github.com/Uke-Messaging/uke-pallet) project, that provides functionality to perform basic messaging and identity assignment to users on a given Substrate chain. Unlike Uke Protocol, Diffy chat dapp won’t use a blockchain for sending and storing entire messages as in case of mass use this feature will dramatically clog the blockchain with unnecessary information like "hello" messages. Our dapp will use a blockchain just for authorization purposes, p2p connection initiation and for personal encryption keys. History backup feature can be available on later stages of the project by storing files locally or in IPFS with putting just a hash sum in a blockchain.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Max Remov, managing partner at BelSoft Dev d.o.o
+- Alexey Vexin, CEO at BelSoft Dev d.o.o
+- Dmitrii Shevchenko, CTO at BelSoft Dev d.o.o
+- Nikita Orlov, Teamlead at BelSoft Dev d.o.o
+- Alexander Plekhanov, Middle full stack developer at BelSoft Dev d.o.o
+- Valeriy Tetevin, Senior full stack developer at BelSoft Dev d.o.o
+
+### Contact
+
+- **Contact Name:** Alexey Vexin
+- **Contact Email:** vexin@belsoft.rs
+- **Website:** https://www.belsoft.rs
+
+### Legal Structure
+
+- **Registered Address:** Kneza Mihaila 33, sprat 2 , Stari Grad , 11000 Beograd , Srbija
+- **Registered Legal Entity:** Belsoft Dev DOO Beograd
+
+### Team's experience
+
+Max Remov is a business and personality transformation expert, executive and visionary, innovation instigator across telecom, retail, chemistry, pharma. Participates in several crypto initiatives.
+
+Alexey Vexin is product owner and project manager with 10+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led dozens of federal scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation.
+
+Dmitrii Shevchenko is a TechLead engineer with 10+ years of experience in developing and integrating IT, networking, security and blockchain solutions. Involved in implementation of highly reliable industrial solutions and development of FinTech and DeFi applications.
+
+Nikita Orlov, ETH Waterloo 2019 hackathon prize-winner, is a TechLead engineer with over 8 years of experience in development and integration of fault-tolerant high-loaded SaaS IT solutions including relevant experience in blockchain solutions.
+
+Alexander Plekhanov is a full stack software developer with over 5 years of experience including blockchain-based projects, enterprise solutions for fintech, call-centers, government services. Recent time mostly focused on smart-contracts development.
+
+Valeriy Tetevin is a programming engineer with over 8 years of experience in cloud-native applications. He also has strong knowledge of microservices architecture and back-end development for high-loaded applications.
+
+### Team Code Repos
+
+- https://github.com/1db1
+- https://github.com/StringNick
+- https://github.com/SealTV
+
+### Team LinkedIn Profiles (if available)
+
+- [Max Remov](https://www.linkedin.com/in/remov)
+- [Alexey Vexin](https://www.linkedin.com/in/alexey-vexin-800a4068/)
+- [Nikita Orlov](https://www.linkedin.com/in/nikita-orlov-aa6910186/)
+- [Alexander Plekhanov](https://www.linkedin.com/in/alexander-plekhanov/)
+- [Valeriy Tetevin](https://www.linkedin.com/in/sealtv/)
+
+## Development Roadmap :nut_and_bolt:
+
+We plan to execute 3 deliverables in two milestones:
+- a Substrate pallet for chat initiation;
+- a DOTRTC library for p2p transport implementation with test html pages for message passing;
+- a web-messenger dapp MVP with polkadot wallets authorisation.
+
+The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA.
+
+### Overview
+
+- **Total Estimated Duration:** 3 months
+- **Full-Time Equivalent (FTE):** 3,5 FTE
+- **Total Costs:** 30,000 USDT
+
+### Milestone 1 — Design and development of a pallet and a DOTRTC library
+
+- **Estimated duration:** 1,5 months
+- **FTE:** 2
+- **Costs:** 16,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how the developed features work. |
+| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure new functionality and robustness. In the guide, we will describe how to run these tests. |
+| 1. | Diffy chat pallet | We will develop a pallet (using Rust) which will include event handling to send and approve WebRTC offers for chat initiation. |
+| 2. | DOTRTC library | We will develop a DOTRTC library (with JS) for p2p transport implementation using a parachain with Diffy chat pallet. This library will include an API for organizing p2p communication, methods for splitting packets into chunks (and reassemble on the receiver’s end). For secure messaging between two participants a e2e encryption using the rs25519 algorithm will be implemented in the DOTRTC library (a sender will encrypt outgoing messages with recipient’s public key so only the recipient could decrypt them with his private key). |
+| 3. | HTML test page | We will deliver an HTML test page for DOTRTC library testing (setting a p2p channel between 2 users using the DOTRTC library). |
+
+### Milestone 2 — A web messenger MVP development
+
+- **Estimated duration:** 1,5 months
+- **FTE:** 1,5
+- **Costs:** 14,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how the new dapp works. |
+| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. |
+| 0d. | Article | We will publish an **article** that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system |
+| 1. | Contacts list feature | We will develop a contact list feature allowing users to tie real names to contact’s wallet addresses and store them encrypted in a blockchain. Encryption and decryption will be carried out on the frontend. |
+| 2. | Web messenger dapp MVP | A web messenger dapp (written on JS) with authorization via Polkadot.js keys, p2p messaging using developed DOTRTC library and contacts list: a user will be able to start a conversation with someone on his contacts list. A web dapp MVP mockup is shouwn below and the basic user logic is as follows. To establish a chat User A sends a short 1st message to User B (limited to 50 symbols as it is written into the blockchain). This message is sent with the connection request. When User B is on-line he receives this message with connection request and accepts it: automatically for users on his contact list and manually for requests from unknown users (connection request can be declined as well).|
+
+
+
+## Future Plans
+
+In the next stages of the project we plan to implement new fundamental features like:
+- offline messaging;
+- group chats (p2mp);
+- sending/receiving files;
+- chats backup feature.
+
+These should be developed under later stages of the project.
diff --git a/applications/Dotflow.md b/applications/Dotflow.md
new file mode 100644
index 00000000000..8875dbc10d1
--- /dev/null
+++ b/applications/Dotflow.md
@@ -0,0 +1,201 @@
+# Dotflow
+
+- **Team Name:** Sergej Sakac & Oliver Lim
+- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+#### Problem
+We can most certainly agree that the future is multi-chain. As such, it is not uncommon for users to hold multiple accounts across various chains for reasons such as distinct address formats and security benefits. However, this practice presents a challenge in managing multiple addresses. Adding to the complexity is the need to verify the address of the intended recipient, as it may have changed over time.
+
+In summary, there are two key challenges to address: the management of multiple addresses and making sure the addresses of the recepients did not change in the meantime.
+
+To mitigate these challenges, we aim to simplify the user experience by abstracting away the complexity of address management.
+
+### Project Details
+
+Our project will comprise two smart contracts coded in ink!, and a React.js-based user interface.
+
+One of the ink! contracts will store the user's address-related data in an entity called `Identity`. Each user will have their own `Identity`, containing their addresses across different chains. The Identity creators will be responsible for updating their addresses if any changes occur. Every Identity will be assigned a unique `IdentityNo`, which will serve a crucial purpose in the address book contract and UI.
+
+Additionally, this contract will feature a function that, based on input arguments, will return the appropriate destination address for token transfers. This function will mainly be used by the user interface.
+
+The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with. Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. Each address book will be attached to a wallet so that when a user logs in with his wallet the UI and provides the `IdentityKey` the frontend will automatically be able to display the address book to the user.
+
+The UI will serve the purpose of interacting with both smart contracts. Users will be able to create an identity and customize the addresses of their identity. Using the UI users will also be able to create their address book and customize it. The most important functionality the UI will provide will be the routing.
+When a user wants to transfer some tokens to an identity the user will only have to worry about the token, origin and destination chain, and the identity they want to send the tokens to. Based on all of this the UI will query the identity contract and based on that create a transaction that will route the tokens to the proper address.
+
+In case the origin and destination chain are not the same, the UI will create an XCM message that will route the tokens to the proper blockchain. For the XCM transaction to work there has to be an existing XCM channel between the two blockchains.
+
+### Privacy
+Most of us don't want to share all of our addresses with the rest of the world. For that reason, we are including some privacy features that will keep all our addresses private.
+All of the addresses in the identity smart contract will be encrypted with a secret key.
+
+Users will have multiple addresses each attached to a certain blockchain. AES 128-bit ciphers will be generated by the UI per each blockchain. These ciphers will only change if the user changes them when updating an address, otherwise, they will always be the same for the associated blockchain.
+Ciphers will be created when creating an identity or when adding a new blockchain address to the identity. These ciphers will be stored in a structured format so that the frontend code can associate each cipher with a blockchain. Ciphers will be stored locally in the following format:
+```
+-- We will call this data the 'Identity Key' --
+blockchain_name_1:cipher_1;blockchain_name_2:cipher_2;...and so on
+```
+Each address will be encrypted with the associated cipher before it gets stored in the identity contract. This will ensure that no one has access to an identity's addresses simply by reading the contract's state.
+
+To share an identity with someone the `Identity Key` will also be needed to be sent together with the `IdentityNo`. In case an identity doesn't want to expose all of their addresses to someone else, but only some of them, it is possible to send part of the `Identity Key` that contains the ciphers for the blockchain addresses he wants to share.
+Of course, the user won't need to do this task manually, the UI will make this task very simple. The following section will show how this will work from the user's perspective.
+
+In case we update some of our addresses but we want to restrict access to the users that previously were granted access to that address there will be an option to regenerate the cipher. This way everyone that had access to the old address won't have access to the new one.
+
+### UI Design
+The UI will consist of three main parts:
+
+- My Identity page
+- Transfer page
+- Address book page
+
+#### My Identity page
+[](https://postimg.cc/dh42rHhS)
+
+The user will be able to create his own identity and provide the addresses he owns on to his identity.
+
+
+
+In case some of the addresses the user owns change over time he will be able to edit them.
+Also, we can select the option to regenerate the cipher so that people that had access to the old address won't be able to access the new one.
+
+[](https://postimg.cc/jW9gtWQ0)
+
+When sharing their identity users will also be able to select which addresses will be available for the person they are sending their identity to. The user will have to copy his `identityNo` but also the `identityKey` which specifies which addresses are accessible for the user that receives this key.
+
+[](https://postimg.cc/fV9scj4D)
+
+#### Transfer page
+[](https://postimg.cc/75MYwz6w)
+
+Ther user will be able to transfer tokens to an identity by specifying the origin chain, destionation chain, and the receiver's `identityNo`.
+
+#### Address Book page
+
+
+The user will be able to add identities to his own address book. The identities will be added by providing the `identityNo` and some nickname for the identity.
+ Also by clicking on the transfer icon on one of the identities the user will be redirected to the transfer page where the `identityNo` will be automatically filled out.
+
+[](https://postimg.cc/PPLbMNSd)
+
+When adding an Identity to an address book the user will also be required to provide the Identity Key which will be used for decrypting the identity's addresses when sending tokens.
+
+### Ecosystem Fit
+
+This project fits perfectly with the Polkadot ecosystem because it has everything we need to make it work. Polkadot is a multi-chain network, so a lot of users have different addresses on different chains for the same reasons we mentioned earlier. That's why the problems we talked about are important in this ecosystem.
+
+XCM is going to be a core component of our project since it'll help us transfer tokens between the parachains and the relay chain.
+
+#### Target Audience
+Our target audience is people who deal with sending assets frequently over the Polkadot network.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Sergej Sakac [Szegoo](https://github.com/Szegoo)
+- Oliver Lim [cuteolaf](https://github.com/cuteolaf)
+
+### Contact
+
+- **Contact Name:** Sergej Sakac
+- **Contact Email:** sakacszergej@gmail.com
+- **Website:** https://github.com/Szegoo
+
+### Legal Structure
+- **Registered Address:** Kanalska 7 Novi Sad Serbia
+- **Registered Legal Entity:** MASTER UNION LLC.
+
+### Team's experience
+
+#### [Sergej Sakac](https://github.com/Szegoo)
+- More than three years of programming experience
+- Active contributor to [Substrate](https://github.com/paritytech/substrate/pulls?q=is%3Apr+author%3ASzegoo)
+- Member of the [fellowship](https://github.com/polkadot-fellows/seeding/pull/36)
+- Contributor to [rmrk-pallets](https://github.com/rmrk-team/rmrk-substrate/pulls?q=is%3Apr+is%3Aclosed+author%3ASzegoo)
+
+#### [Oliver Lim](https://github.com/cuteolaf)
+- Full stack blockchain developer with 5+ years of experience
+- Quick learner and active contributor to open source projects
+ - [Fair Squares](https://github.com/fair-squares/fair-squares)
+ - [Imbue Network](https://github.com/imbuenetwork)
+ - [Anagolay Network](https://gitlab.com/anagolay/anagolay)
+ - ...
+
+### Team Code Repos
+
+We will be working on two separate repos, one for the UI and the other for the ink! contracts.
+
+- https://github.com/TheDotflow/dotflow-ui
+- https://github.com/TheDotflow/dotflow-ink
+
+Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.
+
+- https://github.com/Szegoo
+- https://github.com/cuteolaf
+
+### Team LinkedIn Profiles (if available)
+
+- http://linkedin.com/in/sergej-sakac-334a47252
+- https://www.linkedin.com/in/oliver-lim-2215a8235/
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 2,5 months
+- **Full-Time Equivalent (FTE):** 1.5 FTE
+- **Total Costs:** 19,000 USD
+
+### Milestone 1 Example — Basic functionality
+
+- **Estimated duration:** 1 month
+- **FTE:** 1,5
+- **Costs:** 8,000
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | Ink! contracts and the UI code will be well documented and open for everybody to take a look. The UI will be simple and intuitive to use. |
+| **0c.** | Testing and Testing Guide | The Identity ink! contract will be well tested with unit and integration tests. |
+| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
+| 1. | Identity Contract | We will write the code for the Identity contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Identity contract will provide a range of functions, including creating an identity, adding addresses that are mapped to specific blockchains, and updating these addresses as needed. The contract will automatically generate a unique identifier, referred to as `identityNo`, for each identity. To ensure maximum security, we will allow the identity creator to specify the accounts that are authorized to modify the identity's addresses. This will enable the creator to retain control of the identity even if they lose access to the account used to create it.|
+| 2. | My Identity page | The My Identity page will be developed using React.js, providing users with a user-friendly interface to interact with the Identity contract. This will include the ability to create a new identity, add or remove addresses associated with an identity, and access and copy the unique `identityNo` to share with others. This UI will also generate the `Identity Key` for the user's identity and will update it every time he adds a new blockchain address. This `Identity Key` will be accessible for the identity creator when sharing his identity. The interface will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section. |
+
+
+### Milestone 2 Example — Additional features
+
+- **Estimated Duration:** 1,5 month
+- **FTE:** 1,5
+- **Costs:** 11,000
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | The contract and the website code will be well documented and open for everybody to check. The UI will have a simple UI that will be intuitive to use. |
+| **0c.** | Testing and Testing Guide | The Address Book ink! contract will be well tested with unit and integration tests. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination. |
+| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
+| 0e. | Article | We will publish a Medium article that explains the details of our project. |
+| 1. | Address Book | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book will enable users to create an address book and populate it with the identities they interact with most frequently. The identities will be added via their identityNo since our main goal is abstracting away addresses from the users. When adding an identity to an address book the Identity Key will also be needed. The address book will be stored on chain but the `IdentityKey` will be stored in local storage. The application will expect the user to provide the `IdentityKey` when using the app from a different device for the first time. |
+| 2. | Routing functionality. | The code responsible for routing tokens to the correct destination will be incorporated into the frontend code written in TypeScript. This code will incorporate the necessary logic for constructing XCM messages to route tokens to the appropriate address. In cases where the destination chain is the same as the origin, a simple transaction will be executed. Because of possible race conditions where the identity owner is trying to update an address on a parachain while another user is trying to send funds to that identity on that parachain we introduce additional checks on the frontend. Before sending a transaction that will transfer the funds, the frontend will check whether there are any pending transactions happening that would change the address on the chain the user is transferring funds to. In case there is a pending transaction the user will get a warning and will be advised to wait for a moment and try sending the transaction again. |
+| 3. | Address Book page | We will write the code for the Address Book UI using React.js. The UI will be based on the provided mock design that we displayed above in the [UI design section](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design). The UI will make it possible for users to create an address book and add identities to it. |
+| 4. | Transfer page | We will create a user interface using React.js that will enable users to send tokens to a designated `IdentityId`. This UI will abstract away the complexity of addresses and leverage the Routing functionality described in this table(Section 2) to handle token routing. The UI design will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section for optimal user experience. |
+
+
+## Future Plans
+
+Our future plan is to expand our core functionality and add more features so that the tokens can be routed based on some different criteria. Some example of these ideas are:
+
+- Route tokens based on the amount, sender and/or the token itself
+- Split the transferred amount to multiple addresses
+
+An exciting feature we would like to build in the future is enable token transfers between blockchains that are not part of the Polkadot network(e.g. Polkadot<->Ethereum).
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** GitHub
diff --git a/applications/Eiger_Storage_on_Polkadot_1.md b/applications/Eiger_Storage_on_Polkadot_1.md
new file mode 100644
index 00000000000..e0467574a0c
--- /dev/null
+++ b/applications/Eiger_Storage_on_Polkadot_1.md
@@ -0,0 +1,118 @@
+# Proposal: Storage solution on Polkadot
+
+- **Team Name:** Eiger
+- **Payment Address:** Fiat 14.04.2023, 16:50 UTC+3
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+
+The main goal is to implement and maintain a Filecoin-like system parachain that uses DOT as the native token and is easily usable for all kinds of parachain projects in the ecosystem via XCM.
+
+### Project Details
+
+To accomplish this we are submitting this initial proposal to update our previous research and test how XCM could be used to allow the ecosystem to use this storage network.
+
+We are interested to build this because:
+- Native storage in Polkadot payable in DOT is not currently available
+- We have done the research 2 years ago.
+- After talking to community members in Decoded 2023 we noticed there is demand for this kind of functionality.
+
+We will not be using Trusted Execution Environments or Enclaves in this solution.
+
+###
+
+
+### Ecosystem Fit
+
+Currently a storage solution native to Polkadot is missing, by building a system parachain anyone in the ecosystem will be able to access storage thru XCM, pay in native DOT and build more complex applications withour relying on other networks.
+
+
+## Team :busts_in_silhouette:
+
+Eiger - We help leading technology companies to scale and develop their core technologies to gain an edge by providing expert teams in the most critical areas of modern web3 development.
+
+Eiger is part of the [Equilibrium group](https://www.eqg.co/) which includes engineers from our sister company [Equilibrium Labs](https://equilibrium.co/).
+
+### Team members
+
+- **Tomek Piotrowski** ([Github](https://github.com/tomekpiotrowski), [Linkedin](https://www.linkedin.com/in/tomasz-piotrowski-17466b4/)) Software Engineer at Eiger, specializing in Rust-based applications. With a strong background in software development, he has spent recent years focusing on the Rust programming language. At Eiger, Tomasz actively contributes to the advancement of Rust-based blockchains and their ecosystems.
+- **Mark Henderson** ([GitHub](https://github.com/aphelionz), [Twitter](http://twitter.com/aphelionz)) is the VP of Engineering at Equilibrium. He has led the team starting with the original Rust IPFS implementation in late 2019, through engagements with many of the largest names in Web3, and is part of the team that did [the original research](https://github.com/common-good-storage/report/blob/master/src/first.md) 2 years ago. Core contributor to OrbitDB, Rust IPFS, and Ziggurat.
+- **Piotr Olszewski** ([Github](https://github.com/asmie), [LinkedIn](https://www.linkedin.com/in/piotr-olszewski-8a239939/)) & **Karlo Mardesic** ([Github](https://github.com/Rqnsom), [LinkedIn](https://www.linkedin.com/in/karlo-mardesic/)) - currently working on MoveVM pallet, they will contribute with their Polkadot and Substrate knowledge and join the next stage of this project, implementation.
+
+### Contact
+
+- **Contact Name:** Daren Tuzi
+- **Contact Email:** daren@eiger.co (Founder & CEO of Eiger)
+- **Website:** [Eiger.co](https://www.eiger.co/)
+
+### Legal Structure
+
+- **Registered Address:** Linnankatu 3 A 24, 20100 Turku, Finland
+- **Registered Legal Entity:** Eiger Oy
+
+### Team's experience
+
+- [We researched this very topic 2 years ago](https://github.com/common-good-storage/report/blob/master/src/first.md)
+- [We are the main contributors to implementing IPFS in Rust](https://github.com/rs-ipfs/rust-ipfs)
+- We are building a MoveVM pallet for Polkadot (we will deliver Milestone 1 next week)
+
+Our clients include: Starknet, Aleo, Forte, Zcash, Fireblocks, Ripple, Algorand, Solana, Flow, Elusiv, Celestia, Stellar and more.
+
+### Team Code Repos
+
+- Contributions to SnarkOS for Aleo. https://github.com/AleoHQ/snarkOS
+- OrbitDB is a distributed, p2p, serverless database. https://github.com/orbitdb/orbit-db
+- The rust implementation of IPFS. https://github.com/rs-ipfs/rust-ipfs
+- The main implementation of Interledger in Rust. https://github.com/interledger/interledger-rs
+- Ziggurat - A Network protocol testing framework for ZCash, XRP, and Algorand. Notably, critical network vulnerabilities were found and reported to the core teams. https://github.com/runziggurat
+- Pathfinder, the full node implementation of Starknet https://github.com/eqlabs/pathfinder
+- Zcash uniffi https://github.com/eigerco/uniffi-zcash-lib
+
+
+## Development Status :open_book:
+
+The goal of this proposal is to update the work we have done in the past to account for what has changed in the past 2 years in the Polkadot ecosystem and the advancements made in storage solutions like Filecoin.
+
+In addition to this research and updating the code, we will also test how XCM could be used by anyone in the ecosystem to interact with this storage.
+
+## Development Roadmap :nut_and_bolt:
+
+### Update research, update code and test XCM
+
+- **Total Estimated Duration:** 1 month
+- **Full-Time Equivalent (FTE):** 1.5
+- **Total Costs:** 30,000 USD
+
+
+Two engineers will work together and in parallel to deliver these 3 subcomponents:
+
+1. Update the research done previously to reflect latest tech changes in Polkadot and Substrate. We want to figure out what it would take to implement a whole storage solution as a parachain without depending on 3rd part chains and evaluate what components need to be written from scratch and what can be reused.
+2. Update the [code delivered in CGS](https://github.com/common-good-storage/parachain) or start fresh, whichever makes most sense. The scope of this is to deliver scafolding/template repository with boilerplace and dummy funcitonality. On top of this we can then test the milesone #3 below.
+3. Research and test how XCM can be used. Using the scafolding code from #2 we can test how XCM can be used to access the storage from a different parachain.
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | Copyright and Licenses | Apache 2.0 and MIT |
+| **0b.** | Documentation/Tutorial | We will provide both inline documentation of the POC code and a basic tutorial that explains how a user can run the same test. |
+| **0c.** | Methodology | Detailed explanation of how the results were achieved and how to reproduce/verify the results. |
+| **0d.** | Infrastructure | We will provide the list of all requirements that can be used to verify the code deliverable with this milestone. This is related to deliverable 0b. Documentation and 0g. Docker |
+| **0e.** | Article | Content: Updated research doc detailing our findings, how the tech has changed and how the solution will look like. |
+| **0f.** | Testing and Testing Guide | We will deliver code that tests how XCM might be used to access this storage parachains. |
+| **0g.** | Docker | Where relevant. we will provide a Dockerfile(s) that can be used to run and test the MVP and the XCM test. |
+| **1.** | Updated CGS code | We will deliver a repositiory with the update MVP code |
+
+
+
+
+## Future Plans
+
+This initial grant will produce a game plan on how exactly this storage network will work. Using this knowledge we will submit another future proposal to build this solution. Once this storage solution has been built, it will be voted on by a governance vote. If successful then this system parachain will be available to be used by anyone in the ecosystem and payable in native DOT.
+
+
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** We are working on MoveVM pallet grant which asnwers the original RFP from the foundation so we were familiar with the ecosystem.
diff --git a/applications/FuzzLand.md b/applications/FuzzLand.md
new file mode 100644
index 00000000000..9a712bc9370
--- /dev/null
+++ b/applications/FuzzLand.md
@@ -0,0 +1,402 @@
+# FuzzLand
+
+- **Team Name:** FuzzLand
+- **Payment Address:** 0x3a2a700d9d822D23D3F0F55F4b097753b5B2FC9A (ERC20 DAI/USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1499#issuecomment-1634849391)
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+
+tldr: FuzzLand is a DAO leveraging crowd-sourced computation power to achieve **fast**, **accurate**, and **cheap** automated auditing.
+
+The importance of auditing has grown significantly in recent years as organizations strive to ensure the integrity and security of their systems. However, despite the importance of auditing, it remains challenging, with many auditing companies struggling to provide comprehensive and accurate reports.
+
+The use of human auditors by auditing firms presents several challenges, including the high costs of recruiting and training qualified personnel and the potential for human error. With the increasing complexity of software systems and the growing volume of data to be analyzed, manual audits can become increasingly time-consuming and error-prone. On the other hand, automated auditing solutions also present their own set of challenges. These solutions typically require high computational power and incur high running time overhead. Thus, many traditional automated auditing tools sacrifice completeness and soundness of the analysis for faster response time, resulting in both false negative and positive results.
+
+In contrast, FuzzLand aims to parallelize novel automated program analysis techniques to gain accurate results in a reasonable amount of time. To achieve high parallelism with low costs, FuzzLand platform allows the public to contribute computation power to accomplish the automated auditing in return for token rewards. In the meantime, all the program analysis intermediate statistics and waypoints are verified and stored on the FuzzLand chain, which can finally be leveraged to mint the auditing reports.
+
+Unlike traditional collaborative manual auditing platforms, FuzzLand uses sound automated program analysis (e.g., fuzzing and symbolic execution) techniques to provide accurate auditing reports. Since the program analysis results and intermediate waypoints can be easily verified through a fully automated oracle, the manual confirmation process is no longer needed. While it is impossible to quantify the performance of human auditors, FuzzLand can quantify the auditing progress and completeness of auditing reports based on metrics backed with on-chain data.
+
+The FuzzLand platform can offer two key benefits to the ecosystem. Firstly, it allows Substrate module and Ink developers to access low-cost, highly accurate auditing reports for their projects with on-chain guarantees. Secondly, the platform will be implemented as a Substrate chain and the platform's Substrate pallets can be easily reused by other projects.
+
+### Project Details
+
+#### Stakeholders
+
+* Project Owners: Anyone who needs an audit for their program.
+* Validator Nodes (i.e., Judges): A proof of stake network that verifies the audting information. Note that these nodes are not necessary the validators of the *chain*.
+* Auditor Nodes (i.e., Wardens): Anyone can run a nodes on their computers or even inside browsers to supply computation power for program analysis in return of token rewards.
+
+#### High Level Auditing Workflow
+
+```
++---------+ +-------------+ +-------------+ +-------------------+ +-------+
+| Auditor | | Validator 1 | | Validator 2 | | Project Owner | | Chain |
++---------+ +-------------+ +-------------+ +-------------------+ +-------+
+ | | | | |
+ | | | | 0. Onboard a project |
+ | | | |--------------------------------------------->|
+ | | | | |
+ | | | | 1. Ask for partition plan based on project |
+ | |<--------------------------------------------------------------------------------|
+ | | | | |
+ | | 1. Claim a partition plan and submit it |
+ | |-------------------------------------------------------------------------------->|
+ | | | | |
+ | | | 1. Challenge the partition plan if it is not correct |
+ | | |---------------------------------------------------------------->|
+ | | | | |
+ | | | | 2. Send the partition of the project |
+ |<---------------------------------------------------------------------------------------------------------------|
+ | -----------------------\ | | | |
+ |-| 2. Auditing with DPA | | | | |
+ | |----------------------| | | | |
+ | | | | |
+ | 3. When a testcase leading to vulnerability / new coverage found, submit the testcase |
+ |--------------------------------------------------------------------------------------------------------------->|
+ | | | | |
+ | | 3. Challenge the testcase if it is not correct |
+ | |-------------------------------------------------------------------------------->|
+ | | | | |
+ | | | | 4. Stop the auditing and mint the report |
+ | | | |--------------------------------------------->|
+ | | | | |
+ | | 4. Provide share of bounties based on the # of testcases submitted |
+ |<---------------------------------------------------------------------------------------------------------------|
+ | | | | |
+ | | | | 4. Provide share of bounties as reward |
+ | |<--------------------------------------------------------------------------------|
+ | | | | |
+```
+
+
+0. Project owner can create an auditing request by staking tokens as bounties and providing the compiled program.
+
+1. The program being audited is divided into smaller subprograms of equal exploring complexity using static analysis by validator nodes. Each node is assigned a unique subprogram to audit for a specific period. This process, known as partitioning, is extremely fast and helps prevent auditor nodes from wasting computational power on code other nodes have already explored. The partitioning plan is deterministic and can be easily verified by other validator nodes, reaching consensus among all validator nodes before the auditing campaign begins.
+
+2. Each auditor nodes pick up a specific partition in the partitioning plan minted based on weighted sampling. Then, auditor nodes leverage fuzz testing techniques to analyze their subprogram. Auditor nodes are incentivized to prioritize auditing requests that are new, have high program complexity, and offer higher rewards. This is because auditor nodes are motivated to find more test cases that lead to vulnerabilities and new coverage, as well as to receive higher rewards for the test case NFTs they mint.
+
+3. When auditor nodes detect a test case leading to vulnerability or new code coverage, they mint an NFT for the test case. Judge nodes then verify the test case by re-executing it. Since the execution is deterministic, the outcome must also be deterministic, allowing validator nodes to reach consensus about the validity of test case NFTs.
+
+4. Project owner can terminate an audit request. The termination requests also mint an NFT for an auditing report automatically based on the intermediate statistics, test cases, and vulnerabilities. A reward (i.e., bounties) is then given to the validator nodes and auditor nodes that generated or verified the test case NFTs.
+
+
+#### Technical Details
+
+**Partitioning Plan Synthesis**
+
+By converting a program into LLVM bytecode, we can create a weighted control flow graph (CFG) of it with the weight of each edge as relative difficulty of exploring such an edge. Graph partitioning algorithms can then partition the CFG into sub-trees, with the starting node of the CFG as the root of each tree. The partition plan can be concisely represented in O(log n) bytes, where `n` is the size of the CFG, making it possible to be fit into an on-chain variable.
+
+To determine the difficulty of exploring each edge in the CFG, we utilize static analysis tools. We pinpoint the comparison instruction that leads to the edge and determine the domain size of both the LHS and RHS. The domain size represents the likelihood of program execution failing into either side if the input is randomly selected. Currently, we use heuristics to determine the domain size. As future work, we can use abstract interpretation algorithms with a constraint solver to calculate it. The exploration difficulty is then estimated by dividing the domain size of the LHS and RHS.
+
+For instance, consider following simple program:
+
+```rust
+// input: Vec
](https://clipchamp.com/watch/nwzybRger1x "Interstellar Video: 55")
+- Designs of UI components
+https://book.interstellar.gg/Mobile_App.html
+
+- Documentation of core components
+https://book.interstellar.gg/
+
+#### Architecture Overview
+
+#### TTVP Detailed
+
+
+
+#### Technology stack
+
+- VHDL
+- C/C++
+- Java/Kotlin/Jetpack Compose/Swift/Swift UI
+- gRPC
+- Rust/Substrate
+- IPFS
+
+
+### Ecosystem Fit
+
+At parisDOT.comm we had a fantastic opportunity to present our project to the leading teams in the Polkadot Parachain community. And the feedback we received was nothing short of extraordinary. Our solution, which aims to provide both hardware security and user-friendliness in a wallet solution, struck a chord with the teams.
+
+Their positive response is a testament to the importance of a solution that addresses this critical need in the Polkadot ecosystem and beyond. The teams were not only impressed with our solution, but they were also eager to put it to the test as soon as it becomes available.
+
+This is a major market fit milestone for us, and we're thrilled to have the support of such influential players in the Polkadot community. We're dedicated to delivering a solution that meets their expectations and contributes to the continued growth and success of the Polkadot ecosystem.
+
+We are in active conversations with some of the teams we met there, and continuously have new discussions with new teams also beyond the Polkadot ecosystem. So far, everyone is impressed and enthusiastic about the solution.
+
+
+## Team :busts_in_silhouette:
+
+
+### Team members
+- Name of team leader:
+- Jean-Luc Leleu
+- Names of team members:
+- Nathan Prat
+- Eliot Leleu
+
+- Philippe Salats (advisor)
+
+### Contact
+
+- **Contact Name:** Jean-Luc Leleu
+- **Contact Email:** jll@interstellar.gg
+- **Website:** 
+
+
+### Overview 🎨
+
+ParaSpell is split into three main repositories at the moment and one new is being added soon:
+
+- XCM API - TBA: Meant to provide much faster response than integrating XCM SDK as well as being easier to integrate than XCM-SDK (No install needed)
+- [XCM SDK](https://github.com/paraspell/xcm-sdk): Meant to unify cross-chain experience on Substrate. Can serve any dApp developer that wishes to integrate XCM or other pallets support for they app.
+- [UI-V2](https://github.com/paraspell/ui-v2): Allows for launching local network and testing XCM or HRMP channels across that local network
+- [Docs](https://github.com/paraspell/docs): Extensive documentary for overview of ParaSpell, guide for SDK and UI
+
+
+
+#### SDK
+This SDK currently support 46 compatible XCM nodes. They can transfer XCM messages in three different scenarios.
+- Parachain to Parachain - HRMP
+- Parachain to Relay chain - UMP
+- Relay chain to Parachain - DMP
+
+SDK contains many useful features that allow for easier inntegration:
+- Builder pattern implementation, easy to construct XCM calls, much more used recently for simplicity of implementation.
+
+- Suggestions, SDK contains TYPES that help to guide developer through integration. For example he get's compatible nodes suggested.
+
+
+- Console printouts, SDK allows for printing into console so developer can alway check if call they constructed is correct.
+
+
+- Exporting registered assets for each compatible node in many useful functions
+
+- Exporting supported XCM pallets for each compatible node in useful functions
+
+And more..
+
+#### UI-V2
+UI is used as testing tool for Parachain developers, they can simply add their node into network and test it with HRMP channels as well as XCM transfers. UI also allows dApp developers to test and learn XCM before integrating it from our SDK.
+
+UI is made to be as simple to use as possible. It is now also deployed on netlify so developers only have to start local network from configuration file provided by ParaSpell which starts network of Relay chain and 3 different Parachains (Bifrost,Karura & Pichiu)
+
+Below are some examples of UI with running network:
+
+
+Above we can see open/ close channel screen. It is simple to work with and intuitive. Nodes are pulled from relay chain by query so if network is not running you cannot see any nodes.
+
+
+
+Above we can observe, that UI contains simple Wallet login with test accounts.
+
+
+
+Above we can see XCM screen which is also very simple to navigate and nodes are pulled from relay chain by query.
+
+#### Docs
+Docs contain important information regarding SDK, UI and other repositories that are in ParaSpell or ParaSpell contributed to / collaborated with.
+The key areas are:
+- Introduction
+
+- Guide on importing SDK
+
+
+- Guide on launching local network and UI
+
+
+
+- Guide on executing operations in UI
+
+
+- Guide on implementing SDK
+
+
+
+- Important links
+
+
+#### Architecture 🏗️
+##### Old
+The old design had SDK integrated into dApp:
+
+
+
+UI is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup.
+
+SDK currently handles transfers to 46 compatible Parachains and also can transfer to both Relay chains.
+
+##### New
+In the new design with XCM API, there is no need for integrating XCM SDK. There is only a need to send the request. No more installing packages. Works way faster and offloads dApp from heavy computing to generate calls.
+
+
+#### Technology Stack 💻️
+- Vue.js
+- Node.js
+- Typescript
+- Polkadot api libraries
+- Make
+- Parachain launch
+- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala)
+- Nest.js
+
+### Ecosystem Fit 🌳
+
+#### XCM API
+As mentioned in a tweet from Alice&Bob, we need Chain APIs to put XCM on steroids - [link](https://twitter.com/alice_und_bob/status/1664564442456109057?cxt=HHwWgsC9pdGi3JkuAAAA). We aim to achieve this by utilizing the XCM-SDK technology we built previously. Using XCM API compared to implementing XCM SDK into dApp can bring three main benefits:
+- Calls are generated much quicker
+- API is much simpler to implement than SDK
+- No need to install anything (Comes with the benefit of saving space and without issues with dependencies)
+
+Why we chose NestJS for XCM API:
+By choosing Nest.js as our backend HTTP REST API framework, we can harness the power of Node.js, leverage TypeScript's benefits, ensure maintainability through its modular architecture, and take advantage of its extensive community support. This will enable us to build a reliable, scalable, and well-documented XCM API that seamlessly integrates with the existing XCM SDK. In addition, Nest.js offers a powerful code generation feature that allows us to quickly scaffold boilerplate code for controllers, services, modules, and more. By utilizing the Nest.js code generator, we can significantly reduce development time and effort, ensuring rapid prototyping and efficient implementation of the XCM API endpoints. Compared to other TypeScript frameworks, Nest.js stands out with its modular architecture, seamless integration with Node.js, and strong community support, offering developers a scalable and maintainable solution.
+
+#### XCM SDK
+
+There are not many XCM & XCMP-related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster.
+
+In Polkadot and Kusama ecosystems, there are few XCM-related tools in development. For example, Moonbeam XCM SDK was released only recently. We bring a comparison table that compares our ParaSpell SDK to Moonbeam SDK
+| Features | ParaSpell XCM SDK | Moonbeam XCM SDK |
+| -----: | ----------- | ------------- |
+| Number of packages user has to install | User needs to install only 1 package | User needs to install 2 packages |
+| Support for Parachains | Already integrated for every XCM compatible pallet | Every new node has to be added manually by user |
+| Build pattern | Integrated as intuitive as possible | Integrated, not as intuitive to implement however |
+| Support for asset pallet operations | Integrated | Not integrated |
+| Support for HRMP pallet operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated |
+| Support for checking details that do not change | Integrated & also be covered with some error handling eg (too little amount being sent, not sufficient for XCM transfer) | Integrated in the form of a small "map" for different Tokens & Node IDs |
+| Support for Axelar GMP (General message passing) that will connect Substrate with EVM chains | Planned to be implemented in the future | No data |
+
+
+
+Unlike the already mentioned "Moonbeam XCM" platform ParaSpell provides UI enhancement that uses our XCM SDK and users can try/learn technology from it. ParaSpell also includes support for 46 Substrate Parachains that have XCM pallets compared to Moonbeam XCM to which users have to implement compatible nodes manually. ParaSpell SDK only needs one package compared to Moonbeam XCM which has a total of two. Compared to Moonbeam XCM which contains only XCM calls ParaSpell also contains calls that can open or close HRMP channels. We also include support for Parachains that have a template pallet for XCM called polkadotXCM this pallet is a little harder to work with than xTokens, even more for inexperienced developers. On top of that, this proposal aims to improve ParaSpell even further with introduction of LightSpell XCM API. We have not yet seen any XCM-API proposals or project and we aim to solve this gap as first team.
+
+Another comparison worth mentioning is UI vs Morph which is also an enhancement of the XCM UI Transfer tool
+| Features | ParaSpell XCM UI | Morph |
+| -----: | ----------- | ------------- |
+| Focus: | Developers & users that wish to try XCM locally first | Users |
+| Wiki: | Comprehensive Wiki explaining XCM, how to add assets to UI & Nodes and more implemented | Not implemented |
+| Support for transfers: | In three different scenarios | In two scenarios |
+| Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented |
+| Support for HRMP channel opening/closing: | Fully implemented | Not implemented |
+
+Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains.
+
+We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for the entire ecosystem in our opinion. With the introduction of XCM API, this improves even further.
+
+Our target audiences are Web3 projects and starting/current blockchain developers.
+## Team :busts_in_silhouette:
+
+### Team members
+
+Dušan Morháč - Student, project Founder & Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+Michael Absolon - Student, XCM SDK & XCM API Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+### Contact
+
+- **Contact Name:** Dušan Morháč
+- **Contact Email:** dudo.morhac@gmail.com
+
+
+### Legal Structure
+
+- **Registered Address:** Tomášovská 453/2, Kalinovo 98501, Slovak Republic
+- **Registered Legal Entity:** Dušan Morháč
+
+### Team's experience
+- Dušan is the founder & researcher behind this project and he has successfully presented it at the international conference ICECET2022 held in Prague from which there is an article regarding XCMP & ParaSpell project. It is published by IEEE [link](https://ieeexplore.ieee.org/document/9872938). He also successfully presented it at ICBC 2023 conference held in Dubai. Dušan also studies Blockchain technology and had a bachelor's thesis about cross-blockchain sharing from which this idea was born. Dušan continues research on this idea in his Master's thesis. He is actively working on ParaSpell https://github.com/paraspell full-time & has also participated in other ecosystem projects. Recently he attended Polkadot Blockchain Academy 2023 in Buenos Aires which gave him a lot of insight into the ecosystem and he also graduated from the academy successfully. Here is NFT that was minted as a certificate by Parity - [link](https://singular.app/collectibles/statemine/20/12)
+
+
+- Michael is a dedicated TypeScript developer with 2 years of full-time experience in the Web2 sphere. Michael's expertise in this field was further solidified in 2019 when he won first place in the Junior Internet Web competition for his online multiplayer game, which was written in JavaScript. In addition to his professional background, Michael also achieved a bachelor's degree in the same computer science University as Dušan and he is currently pursuing a master's degree which focuses on Blockchain. His passion for technology led him to explore Blockchain technology in his free time. He was recently offered the opportunity to work on ParaSpell XCM SDK with Dušan and he delivered many of the key features SDK now offers.
+
+### Team Code Repos
+
+- https://github.com/paraspell/xcm-api
+- https://github.com/paraspell/xcm-sdk
+- https://github.com/paraspell/ui-v2
+- https://github.com/paraspell/docs
+
+### Team Github Profiles 🧑🎓
+
+- https://github.com/dudo50 Dušan Morháč
+- https://github.com/michaeldev5 Michael Absolon
+
+### Team LinkedIn Profiles 🧑🎓
+
+- https://www.linkedin.com/in/dudo50/
+- https://www.linkedin.com/in/michael--absolon/
+
+## Development Status :open_book:
+
+The new [XCM-API](https://github.com/paraspell/xcm-api) is in development and we are currently searching for the fastest server with the lowest cost requirements.
+
+[SDK](https://github.com/paraspell/xcm-sdk) is currently released into the main and is in a version that is fully operable. There are still some tweaks we plan to add and make, they are not part of this grant however. [UI-V2](https://github.com/paraspell/ui-v2) currently runs on state-of-the-art technology version VueJS 3 and the newest version of Nuxt. It deprecated V1 and introduced a much smoother interface and modules brought from the sub-scaffold template ParaSpell contributed to. [Docs](https://github.com/paraspell/docs) are currently in ready state but there is still some tweaking to do.
+
+**Sidenote**: We have recently developed an article about Polkadot & Paraspell called Enhancing XCMP Interoperability Across Polkadot Paraverse and it was accepted to the International IEEE BCCA 2023 conference held in Kuwait.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 2 months
+- **Full-Time Equivalent (FTE):** 1 FTE
+- **Total Costs:** 10 000 USD
+
+### Milestone 1 - Create LightSpell⚡️: XCM-API
+
+- **Estimated duration:** 2 months ⌛️
+- **FTE:** 1
+- **Costs:** 10 000 USD 💰️
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide both readme.md and official docs documentation |
+| 0c. | Testing and Testing Guide | Testing guide will be mentioned in official docs & core unit tests will be provided |
+| 0e. | Create Medium article about development of LightSpell | Add article covering new features & improvements brought with LightSpell |
+| 1.a | Integrate API for XCM functionality | Use Nest.js to integrate core XCM SDK functionality to send XCM messages |
+| 1.b | Integrate API for Asset functionality | Use Nest.js to integrate core XCM SDK functionality to do Asset operations |
+| 1.c | Integrate API for XCM Pallets functionality | Use Nest.js to integrate core XCM SDK functionality to query XCM Pallets of different Parachains |
+| 1.d | Integrate API for HRMP functionality | Use Nest.js to integrate core XCM SDK functionality to open/close HRMP channels |
+| 2. | Integrate token authentification | Integrate token authentification with limited requests to remove the possibility of DDOS (Bigger request limit can be requested for free via email provided in docs)|
+| 3.a | Add core Integration tests | Add core Integration tests to ensure everything is working together as expected |
+| 3.b | Add core Endpoint (e2e) tests | Add core endpoint tests to let the user try to use API without writing any code and also to demonstrate if API works |
+| 4. | Integrate LightSpell into ParaSpell docs | Add comprehensive guide for every feature that API will offer [link](https://paraspell.github.io/docs/api/TBA.html) |
+
+## Future Plans 🔭
+
+Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels.
+
+The project goal is that XCM-SDK & XCM-API will serve dApp developers and UI will teach new substrate developers to use XCM and will serve existing substrate developers to test their freshly baked Parachains.
+
+The newly added XCM-API will simplify XCM-SDK integration and will be much faster than integrating XCM-SDK into dAPP directly. Both repositories will remain dependent on each other. Further maintenance funding for servers and keeping XCM API up to date will be requested from Polkadot treasury.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Personal recommendation
+
+##### Project achievements in chronological order ⌛️
+
+- 📙 Article about the project created & presented at international conference ICECET2022 held in Prague (450 out of 1000+ articles accepted) Link to IEEE publication - [IEEE Sharing Fungible Assets Across Polkadot Paraverse](https://ieeexplore.ieee.org/document/9872938/)
+- 🥈 2nd Prize, Build an XCM-related Tool for Moonbeam - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🥉 3rd Prize, EVM+ DApp for aUSD yield - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🎈 Web 3 Foundation base grant [Application](https://github.com/w3f/Grants-Program/pull/1118), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/584)
+- 🐍 [Basilisk](https://bsx.fi/) treasury proposal 2 / 2 Approved [link](https://basilisk.subsquare.io/treasury/proposal/2), [link2](https://basilisk.subsquare.io/treasury/proposal/4)
+- 🔭 Web 3 Foundation phase 2 grant Milestone 3 / 3 delivered [Application](https://github.com/w3f/Grants-Program/pull/1245), [Delivery1](https://github.com/w3f/Grant-Milestone-Delivery/pull/670), [Delivery 2 & 3](https://github.com/w3f/Grant-Milestone-Delivery/pull/715)
+- 📕 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE ICBC 2023 held in Dubai [links TBA]
+- 💼 Kusama Treasury Funding proposal number 1 - Upgrade SDK, [Application](https://kusama.subsquare.io/referenda/referendum/123s), [Delivery](https://docs.google.com/document/d/1lMY_8EtQ41IX7Zn9VIMAiG1k3oLYN0h_lVj8dWDwZ_k/edit?usp=sharing)
+- 🏗️ Web 3 Foundation phase 3 grant (Make SDK better) Milestone 1 / 1 delivered [Application](https://github.com/w3f/Grants-Program/pull/1589), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/836)
+- 📘 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE BCCA 2023 held in Kuwait [links TBA]
diff --git a/applications/LiisaPortfolioTracker.md b/applications/LiisaPortfolioTracker.md
new file mode 100644
index 00000000000..da742528247
--- /dev/null
+++ b/applications/LiisaPortfolioTracker.md
@@ -0,0 +1,280 @@
+# Polkadot NFT Portfolio Tracker by Liisa - MVP
+
+- **Team Name:** Liisa
+- **Payment Address:** 0x096a685Bfd75c3998CFC4c70177e17ee6b582B0A
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+
+## Project Overview :page_facing_up:
+
+Liisa operates as a multi-chain NFT data analytics platform, engineered to empower collectors and investors in making proficient, data-driven decisions.
+
+This project consists of the development of a custom-built portfolio tracker, explicitly devised for NFTs within the Polkadot blockchain network, catering to the specificities of NFT investment strategies.
+
+Within the Substrate/Kusama/Polkadot/Web 3 ecosystem, Liisa intends to emerge as a central supplier of granular NFT analytics, distinguishing itself with a user interface tailored to meet the specific requirements of NFT investors.
+
+The portfolio tracker is designed to accommodate the diverse needs of a broad user base, ranging from active traders to long-term investors and collectors. It pioneers innovative metrics that drive the NFT infrastructure forward, thereby promoting a robust and data-enriched investment environment.
+
+
+
+
+### Architecture
+
+
+
+
+NFT Tools, currently require users to manually upload the collection via NFT-Up, we’re working to make it drag&drop
+
+
+Token/Coin tools. We’re looking at the example when we creating 1 million XOIN token (see “Coin Minting” section)
+
+
+Example of smart contract analytic. In this image, we’re doing analytic on marketplace.paras.near.
+
+### Ecosystem Fit
+
+We aim to launch on Polkadot and Kusama, here’s what problem we’re trying to solve:
+
+- For creators, creating a smart contract for their NFTs and tokens is hard. Especially in relatively new WASM smart contracts like ink! .
+- For UI developers, blockchain development is too complex. Furthermore, each chain has its own complexity.
+- Limited tooling for Polkadot and Kusama ecosystem.
+- For emerging chain, we help them create smart contract templates.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- CEO & Founder: Adhiguna Mahendra
+- Product Lead & Founder: Ekki Rinaldi (Ekki)
+- Full-stack Developer & Founder: Rizky Irfianto (Irfi)
+- Database Engineer & Founder: Bagas Prakasa
+- Full-stack Developer: Ade Yusup
+- Smart Contract Engineer: Amajid Sinar (Jedi)
+- Business Development: Vincent Salaka
+
+### Contact
+
+- **Contact Name:** Ekki
+- **Contact Email:** ekki@profond.ai
+- **Website:** https://profond.ai
+
+### Legal Structure
+
+- **Registered Address:** 2810 North Church Street, Wilmington, Delaware 19802
+- **Registered Legal Entity:** Profond AI, Corp.
+
+### Team's experience
+
+Our founders we’re building the biggest NFT marketplace in the Near ecosystem (Paras NFT Marketplace) and recently integrated with Astar Network. As builder and part of NFT community, we understand what builders need (especially FE engineer) and for artist who want to launch their on NFT. Our team led by tech veteran who had experience working in Silicon Valley, Adhiguna Mahendra, with 20+ years of experience.
+
+We helped grow the NEAR NFT ecosystem by contributing to NFT with open-source projects such as NFT smart contract standard, marketplace smart contract, vesting smart contract, and so on as you can see on the project’s repo: [https://github.com/parasHQ/](https://github.com/parasHQ/)
+
+Here’s our recent works:
+
+Paras Launchpad: [https://launchpad.paras.id/](https://launchpad.paras.id/) - NFT Launchpad in Astar using ink!
+
+Arkana Raffler: [https://arkana.gg/](https://arkana.gg/)
+
+Pipapo Ticketing System: [https://pipapo.io/](https://pipapo.io/)
+
+### Team Code Repos
+
+- [https://github.com/emarai](https://github.com/emarai)
+- [https://github.com/ekkirinaldi](https://github.com/orgs/profondHQ/people/ekkirinaldi)
+- [https://github.com/bagasprakasa](https://github.com/bagasprakasa)
+- [https://github.com/internnos](https://github.com/internnos)
+- [https://github.com/adeyusupp](https://github.com/adeyusupp)
+
+### Team LinkedIn Profiles (if available)
+
+- [https://www.linkedin.com/in/adhigunamahendra/](https://www.linkedin.com/in/adhigunamahendra/)
+- [https://www.linkedin.com/in/bagasprakasa/](https://www.linkedin.com/in/bagasprakasa/)
+- [https://www.linkedin.com/in/irfianto/](https://www.linkedin.com/in/irfianto/)
+- [https://www.linkedin.com/in/amajidsinar/](https://www.linkedin.com/in/amajidsinar/)
+- [https://www.linkedin.com/in/ekkirinaldi/](https://www.linkedin.com/in/ekkirinaldi/)
+- [https://www.linkedin.com/in/vincentsalaka/](https://www.linkedin.com/in/vincentsalaka/)
+- [https://www.linkedin.com/in/adeyusupp/](https://www.linkedin.com/in/adeyusupp/)
+
+## Development Status :open_book:
+
+PoC → Here’s our current MVP [http://console.profond.ai/](http://console.profond.ai/)
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** Duration of the whole project (e.g. 2 months)
+- **Full-Time Equivalent (FTE):** 2 FTE
+- **Total Costs:** $10.000
+
+### Milestone 1 — No code smart contract builder
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 4,000 USD
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide documentation page on how to create NFT (PSP34) and FT (PSP22) smart contract with our interface. API documentation for project settings will also be provided. |
+| 0c. | Testing and Testing Guide | All functions will be covered with full integration test, testing guide will also be provided. |
+| 0d. | Article | We will publish an article that explains the no code builder |
+| 1. | No Code NFT Creation (ink!) | Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP34 Smart contract. We are abstracting the technical details from users, users just need to upload NFT images, set metadata, and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates. |
+| 2. | No Code Fungible Token Creation (ink!) | Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP22 Smart contract. We are abstracting the technical details from users, users just need to set metadata and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates. |
+| 3. | Project Management Module | Allows users to create more than one projects. We are using NestJS for backend framework. |
+| 4. | Multichain Integration | Allows users to choose between Polkadot Parachains and Kusama |
+
+### Milestone 2 Example — Analytics and API
+
+- **Estimated Duration:** 1 month
+- **FTE:** 2
+- **Costs:** 6,000 USD
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide documentation page on how to create basic NFT collection (PSP34) using our no-code builder and creating a fungible token (PSP22). |
+| 0c. | Testing and Testing Guide | All functions will be covered with full integration test, testing guide will also be provided. |
+| 0d. | Article | We will publish an article that explains the analytics and API usage |
+| 1. | Analytic Functionality | Add on-chain analytic for the smart contract. |
+| 2. | REST API Service | API for users to get the data analytic. |
+
+## Future Plans
+
+Experimenting in business model. We have two kind of ideation we want to validate:
+
+1. Indexer service, providing RPC for dApp to cut their operational costs
+2. Royalties enforcement for each NFT created.
+
+On top of that, we aim to onboard more emerging chains and big chains like Solana and Ethereum.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Web3 Foundation Website
diff --git a/applications/QRUCIAL_DAO.md b/applications/QRUCIAL_DAO.md
index e6d26ef3e45..73d872b832d 100644
--- a/applications/QRUCIAL_DAO.md
+++ b/applications/QRUCIAL_DAO.md
@@ -4,8 +4,8 @@
>
> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal.
-- **Team Name:** QRUCIAL OÜ
-- **Payment Address:** BTC - bc1qwr7awq55z2udjvxj0ar7qfeasf70fasee8fxf2
+- **Team Name:** QRUCIAL DAO
+- **Payment Address:** BTC - 32V2Qmk2xNVddNNvwxGPDhdsofLJr6Gcsa
- **Level:** 2
> ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.*
@@ -84,25 +84,23 @@ CCTF provides a proven track record of hackers solving challenges and based on t
### Team members
- Web3 Architect: six / David Pethes - CTO of QRUCIAL, Founder of CCTF, Polkadot Head Ambassador of Eastern Europe
-- Business Architect: ra33it0 / Sebastian Kraus - CEO of QRUCIAL, EFF member
- Runtime Developer: Wigy / - Senior Rust developer, Ex-Parity substrate core developer
-- Full-stack Developer: Silur / Ábrahám Endre - Researcher at Hungarian Academy of Sciences (MTA), Ex-Ethereum Foundation developer
-- DevOps Engineer: knockoff / Nico Selby - R&D team manager at QRUCIAL
+- Frontend Developer: kmildi / Ildiko Keleti - Senior Web3 Frontend developer
### Contact
- **Contact Name:** six / David Pethes
-- **Contact Email:** hello@qrucial.io
+- **Contact Email:** six@cryptoctf.org
- **Website:** qrucial.io
### Legal Structure
- **Registered Address:** Harju maakond, Tallinn, Kesklinna linnaosa, Narva mnt 7-652, 10117
-- **Registered Legal Entity:** QRUCIAL OÜ, Registration number: 16357543
+- **Registered Legal Entity:** Crypto CTF OÜ, Registration number: 16156552
### Team's experience
-QRUCIAL OÜ is a web3 security company.
+QRUCIAL is a web3 security DAO.
This is the first time we apply for a grant.
@@ -170,7 +168,7 @@ The PoC is working, and we want to move forward in developing a live testnet ver
### Milestone 2 — Implement Exogenous tooling and hardened node system
-- **Estimated duration:** 2 months
+- **Estimated duration:** 2 months (final delivery in 2023 June)
- **FTE:** 0.7 FTE
- **Costs:** 20,000 USD
@@ -188,9 +186,8 @@ The PoC is working, and we want to move forward in developing a live testnet ver
## Future Plans
-- In the short term, we'd like to have the grant, so development goes faster. QRUCIAL as a company will keep funding the project until it becomes self-sustaining (meaning, the governance system keeps the DAO running on its own).
+- In the short term, we'd like to have the grant, so development goes faster. QRUCIAL DAO keeps funding the project on its own.
- CCTF (cryptoctf.org) is already a partner, helping to bring the best web3 hackers to the system.
-- Elfz'n'Trollz is a marketing partner, so we don't just develop a DAO, but also make it usable and visually acceptable to all audiences.
- After final milestone, we will start building a larger community for QRUCIAL DAO and improve our partnership with CCTF.
## Additional Information :heavy_plus_sign:
diff --git a/applications/QSTN.md b/applications/QSTN.md
index 17e89d5b4bb..4423b4b794b 100644
--- a/applications/QSTN.md
+++ b/applications/QSTN.md
@@ -187,14 +187,14 @@ Article 3: https://news.bloomberglaw.com/litigation/google-plus-7-5-million-priv
### Overview
-- **Total Estimated Duration:** 6 months
-- **Full-Time Equivalent (FTE):** 6 employees (2 developers, 3 designers, 1 blockchain architect [Orrin])
+- **Total Estimated Duration:** 12 months
+- **Full-Time Equivalent (FTE):** 8 employees (4 developers, 3 designers, 1 blockchain architect [Orrin])
- **Total Costs:** 10,000 USD
### Milestone 1 Example — Implement Substrate Modules
-- **Estimated duration:** 6 months
-- **FTE:** 6 employees
+- **Estimated duration:** 12 months
+- **FTE:** 8 employees
- **Costs:** 10,000 USD
| Number | Deliverable | Specification |
diff --git a/applications/RedStone Network.md b/applications/RedStone Network.md
index f6934258d2c..8731b5d6ab4 100644
--- a/applications/RedStone Network.md
+++ b/applications/RedStone Network.md
@@ -3,6 +3,7 @@
- **Team Name:** Redstone Network
- **Payment Address:** 0x24cfc36f699dacc5cb652630ddd894a8df658233 (Ethereum ERC20 USDT)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1093#issuecomment-1624203004)
## Project Overview :page_facing_up:
diff --git a/applications/ScoutCoinFabrik.md b/applications/ScoutCoinFabrik.md
new file mode 100644
index 00000000000..f4c1c286733
--- /dev/null
+++ b/applications/ScoutCoinFabrik.md
@@ -0,0 +1,107 @@
+# Scout CoinFabrik
+- **Team Name:** CoinFabrik (Nektra S.A)
+- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDT)
+- **[Level]:** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Scout: Security Analysis Tool
+
+We are building an extensible open-source tool (or set of tools) to assist Rust Polkadot / Kusama smart contract developers to detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques.
+
+This tool will help developers write secure and more robust smart contracts.
+
+Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains.
+
+
+### Project Details
+
+We have already conducted research work with the Universidad de Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development.
+
+We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities.
+
+### Ecosystem Fit
+
+We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, Polkadot / Kusama developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Ariel Wassbein, Head of Reaseach
+- Valeria Caracciolo, Business Develpoment
+- CoinFabrik's development and auditing team - when required.
+
+### Contact
+
+- **Contact Name:** Valeria Caracciolo
+- **Contact Email:** valeria.caracciolo@coinfabrik.com
+- **Website:** https://www.coinfabrik.com/
+
+### Legal Structure
+
+- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina
+- **Registered Legal Entity:** Nektra S.A.
+
+### Team's experience
+We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 180 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.
+
+Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.
+
+### Team Code Repos
+
+- https://gitlab.com/coinfabrik-private/data/frecuencia-de-vulnerabilidades
+- https://drive.google.com/drive/u/1/folders/1HoaL6EXX1Wky7e1SHYBY6oIZDGK2sgDD
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/arielwaissbein/
+- https://www.linkedin.com/in/valeriacaracciolo/
+
+
+## Development Status :open_book:
+
+We have been working on different aspects of the tool:
+- Research on security analysis tools for Rust-based blockchains.
+- Listing common vulnerabilities and usability issues in different systems and technologies.
+- Tools to assist developers.
+
+We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 1 month
+- **Full-Time Equivalent (FTE):** 5 FTE
+- **Total Costs:** 15,000 U$D
+
+### Milestone 1: Proof of Concept
+
+- **Estimated duration:** 1 month (Day 1 to Day 30)
+- **FTE:** 5
+- **Costs:** 15,000 U$D
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT
+| 0b. | Documentation | We will provide a report, listing relevant security issues introduced in smart contracts developed with ink!. This will include a summary of findings and how the results were procured, a detailed description of each vulnerability/best practice, and links to the code that exemplifies them.
+| 0c. | Testing and Testing Guide | No tests with be produced at this stage.
+| 0d. | Docker | Does not apply at this stage.
+| 0e. | Article | We will upload to our blog a report summary.
+ **1** | Research | Producing a curated list of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!, considering the list of [analysis categories](https://blog.coinfabrik.com/analysis-categories/) currently used for our manual smart contract audits.
+ **2** | Development | Producing code examples and snippets of smart contracts written in ink! for each type of vulnerability from the list mentioned in 1. Research.
+ **3** | Development | Proof of concept code detecting some (relevant) issues included in the list of vulnerabilities and best practices.
+
+
+## Future Plans
+
+(Our original plan was to apply for a 3 months grant, to reach a public release of the tool. But we were advised to apply for a shorter objective, so we are presenting only Milestone #1 from our plan) After completing this first milestone, we are planning on applying for 2 additional iterations to reach a tool prototype (Milestones #2) and public release (Milestones #3). Our mission is to continue to work on improving automated and assisted tools for finding security vulnerabilities and writing more secure code. Our objective is to help the Polkadot / Kusama community produce better and more secure code with these tools.
+
+## Referral Program (optional) :moneybag:
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention. Our inquiries were addressed by David Hawig and Bhargav Bhatt, who also gently advised us on this presentation.
diff --git a/applications/ScoutCoinFabrik_2.md b/applications/ScoutCoinFabrik_2.md
new file mode 100644
index 00000000000..f627032e0a1
--- /dev/null
+++ b/applications/ScoutCoinFabrik_2.md
@@ -0,0 +1,116 @@
+# Scout CoinFabrik
+- **Team Name:** CoinFabrik (Nektra S.A)
+- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Scout: Security Analysis Tool
+
+We are building an extensible open-source tool (or set of tools) to assist ink! smart contract developers detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques.
+
+This tool will help developers write secure and more robust smart contracts.
+
+Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains.
+
+
+### Project Details
+
+We have already conducted research work with the University of Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development.
+
+We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities.
+
+### Ecosystem Fit
+
+We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, ink! developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Ariel Wassbein, Head of Reaseach
+- Valeria Caracciolo, Business Develpoment
+- CoinFabrik's development and auditing team - when required.
+
+### Contact
+
+- **Contact Name:** Valeria Caracciolo
+- **Contact Email:** valeria.caracciolo@coinfabrik.com
+- **Website:** https://www.coinfabrik.com/
+
+### Legal Structure
+
+- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina
+- **Registered Legal Entity:** Nektra S.A.
+
+### Team's experience
+We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 180 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.
+
+Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.
+
+### Team Code Repos
+
+- https://github.com/CoinFabrik/web3-grant
+- https://gitlab.com/coinfabrik-private/data/frecuencia-de-vulnerabilidades
+- https://drive.google.com/drive/u/1/folders/1HoaL6EXX1Wky7e1SHYBY6oIZDGK2sgDD
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/arielwaissbein/
+- https://www.linkedin.com/in/valeriacaracciolo/
+
+
+## Development Status :open_book:
+
+We have been working on different aspects of the tool:
+- Research on security analysis tools for Rust-based blockchains, applicable to ink! Smart contracts
+- Listing common vulnerabilities, best practices, and enhancements related to smart contracts written in ink!
+- Producing code examples and snippets of smart contracts showing the mentioned issues.
+- Built a PoC (proof of concept) of a tool that identifies relevant security issues.
+
+We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant.
+
+We have finished the first milestone of this project ([Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept)), accomplishing all the deliverables listed in the milestone table.
+
+Please note, however, that this milestone is the second grant associated with the same project: [ScoutCoinFabrik](https://github.com/CoinFabrik/web3-grant). The first grant focused on the tool’s PoC, and in this second grant we aim to develop a prototype.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 5 weeks
+- **Full-Time Equivalent (FTE):** 5 FTE
+- **Total Costs:** 30,000 USD
+
+### Milestone 1: Prototype
+
+- **Estimated duration:** 5 weeks
+- **FTE:** 5
+- **Costs:** 30,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | Documentation hosted on a separate webpage. |
+| 0c. | Testing | Integration testing. Specific tests for every linting detector based on code examples and snippets of smart contracts. |
+| 0d. | Docker | Does not apply at this stage. |
+| 0e. | Article | We will upload a report summary to our blog. |
+ **1.a** | Research and Development | Vulnerability examples. In addition to the [examples developed in Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept), we will develop more code examples and snippets of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!. |
+ **1.b** | Research and Development | Further example versions of [vulnerabilities developed in Milestone 1 of ScoutCoinFabrik PoC](https://github.com/CoinFabrik/web3-grant/tree/main/vulnerabilities). This step is geared to provide a wider set of examples, therefore improving our ability to measure the precision of our prototype and any other ink! vulnerability detection tool. |
+ **2.a** | Development | Building a prototype that improves over the [development of Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept), detecting more classes of vulnerabilities and improving in precision on existing detectors. We are to build a prototype that can analyze Rust code to detect vulnerabilities in ink! smart contracts and possibly in pallets and other pieces of code. This builds over [this proof-of-concept tool](https://github.com/CoinFabrik/web3-grant) we've built and [delivered as part of a grant for the web3 foundation](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/ScoutCoinFabrik-1.md) by:
+ 
+
+ Chainviz alpha version
+
- 
+ 
- Figure 1 ChainViz Alpha system architecture
+ Figure 1 Chainviz alpha system architecture
- 
+ 
- Figure 2 ChainViz v1 proposed system architecture
+ Figure 2 Chainviz v1 proposed system architecture
- 
+ 