Free2ℤ: What's your 𝑧?

Hello Zcash Forum friends. I have submitted a grant proposal to take from prototype to reality. This is the proposal.

Elevator Pitch: Free2Z will drive Zcash mass-adoption by making private peer-to-peer giving easy, fast and fun with beautiful content and simple features

Total Request (USD): $123,000

We have received no other funding or grants to date and are not currently seeking any funding from other sources.

Applicant background

Skylar Saveland is a software engineer with more than 15 years experience crafting performant and scalable software solutions. As Director of the MultiCloud Account Automation team at SAP, he has developed automated integrations for the four major cloud providers (AWS, GCP, Azure and AliCloud) for SAP’s 425,000 global customer base. Before his promotion, he wrote key cloud automation software for SAP as Lead Engineer using Golang and developed highly scalable APIs and microservices using Python and Django Rest Framework as well as developing TypesScript UIs using React. Free2Z will essentially be built on the same best-of-the-best FOSS web application stack that Skylar has been working on for 15 years.

Before SAP, Skylar was a Vice President and Backend Software Engineer at JPMorgan Chase, working on build platforms for Chase consumer websites built with Python and JavaScript.

Jonathan Bird, PhD. is a senior software engineer at SAP working on the MultiCloud team developing cloud engineering solutions with TypeScript, Golang and Python. Before SAP he developed Java/Spring Microservices for Identity Verification as a Service at JPMorgan Chase. He previously was UI tech lead for the Homepage team leading development on a high-performance website with more than 80 million unique monthly views.

Before Chase, he was CEO of Salud Bucal Universal, a startup in Mexico bringing modern technology and processes to the development and delivery of dental healthcare in Mexico.

Description of Problem or Opportunity

Free2Z unleashes the power of Zcash to make possible direct and private donations to both individuals and content creators. This will transform the online fundraising and content creation industries while driving Zcash adoption on a much larger scale for end-users.

From patients seeking life-saving surgery to disaster relief efforts, online fundraising is changing lives every day. Unfortunately, this useful industry is plagued by intermediaries charging small and large fees, usually rates for using the platform and an additional 2.9%-5% for credit card transaction costs. These fees add up to a significant expense for users; for instance GoFundMe and Fundly charge about 8% to use their service while the total for Kickstarter is closer to 18%.

While many people would like to make private or anonymous donations to the donee of their choice, current technologies make this impossible. For example, GoFundMe requires credit or debit cards to make donations: “you are required to enter the name on the credit card when making donations

Content creators face a similar problem. In order to be compensated for producing high-quality content, many creators have been placing their content behind paywall websites such as Paywalls are fracturing an already less open internet; forcing creators to decide between sharing their content with a broader audience or trying to get fairly compensated. There are also tipping platforms that allow users to directly support creators but they take a significant cut from creators (like Patreon’s 7.9-14.9% cut) and require collecting Personal Identifiable Information (PII) from donors.

Zcash provides an ideal platform for developing robust solutions to both the problem of fundraising and how to fairly compensate content creators, while cutting out intermediaries and providing security, privacy and optional anonymity for donors. By leveraging the power of Zcash, the Free2Z software engineering team has successfully developed a basic prototype proof of concept. Now Free2Z seeks support from the community to turn this proof-of-concept into an easy-to-use, scalable website that can run forever on solid technical and legal foundations.

Proposed Solution

Free2Z is a private and secure content creation platform that leverages ZEC to allow anyone to share content, receive funds from donors and connect privately with supporters. zPages are the heart of Free2Z. They are web pages where users can format content using Free2Z markdown and embed media from almost any source. Additionally, users can quickly and easily display math equations, add syntax-highlighted code and eventually even zip321 markdown directives.

zPages are only visible to Funded Creators on Free2Z until a small sum (at this writing set at 0.001 Zcash) has been sent to fund the zPage. Once a page is funded (and explicitly published by the creator), the content becomes visible to anyone in the world. The minimum funding requirement is an anti-spam measure that makes it more expensive for bad actors to operate on the site. Zcash is not strictly needed to interact with the site. Users are free to browse pages and create their own zPages without ever having Zcash. Funded members of Free2Z can find unfunded pages and kick in the minimum sum to publish the page. Many creators on Free2Z will likely acquire their first Zcash via z2z transactions from the Free2Z community. Thus, new Zcash holders can be born into the shielded pool without having to purchase Zcash.

Funding a page unlocks the killer feature of zPages: the Creator Peer-To-Peer address (p2paddr). Creators can set a shielded Zcash address as a p2paddr. When a creator is logged in and adds a new zPage, they can add a p2paddr to receive direct, private donations from the Zcash community. When the page is published, the p2paddr is published to the world via API and a convenient user interface which allows anyone to donate to the page and message the creator, privately and without intermediaries. The only fee is the typical 0.00001 ZEC (currently < $0.01) sent to the miners who secure the network.

Free2Z also uses gamification to provide a more engaging experience by continuously re-ranking pages based on their on-chain interactions (funding, upvoting, downvoting, and commenting). The on-chain interactions will also provide an organic, automated, transparent curation mechanism that will tend to put great content at the top and terrible content at the bottom (or all the way down to a special garbage bucket).
Free2Z offers a way for the broader Zcash community to share content and support causes and content creators that they care about while celebrating the privacy and anonymity that is the essence of Zcash.

  • Retail ZEC holders will have a fun app to use ZEC in a newbie-friendly way, adding demand for ZEC and adding new holders.

    • ZEC is needed on Free2Z to:
      • create pages, fund pages, comment on pages, downvote pages…
      • Most creators will choose to use a Zcash shielded address to receive support and messages from supporters. But, creators are free to use other types of addresses.
  • Zcash core devs will benefit from Free2z’s early adoption, testing and integration at scale with productive feedback and even upstream changes from the Free2Z team. Free2Z will be a top user of many products in the Zcash ecosystem such as zcashd and plans to be among the first to implement Orchard addresses at scale.

  • Wallet devs will benefit from more users, more feedback, more QA and upstream changes from the F2Z team. Wallet devs may also choose to leverage the F2Z API as an address book.

  • DeFi users and services will benefit from F2Z’s innovations in automating payment behaviors. The first such behaviors are simple - a minimum funding amount (currently 0.001 ZEC) can turn on a page, as well as another small transaction (currently 0.0001 ZEC) to post a comment. Through the development of high-level libraries, in particular those dealing with ZIP-321 and private memos, F2Z will empower DeFi users and services to automate their own unique behaviors based on ZEC payments.

  • Zcash community participants can earn ZEC for their Zcash content and gain exposure on Free2Z: meme collections, community news, market analysis, in-depth technical writing, educational materials. Community meetups and conferences and local groups can use F2Z to publicize their projects and connect with a wider audience. But, Zcash-related content is only a small fraction of what is possible. F2Z will also create a space for Zcash community participants to profit from their talents which are not directly related to Zcash: music, art, educational material, causes, passion projects, consulting, hiring, finding collaborators and like-minded people. Members may also find financial support and encouragement in times of need by making a simple appeal for funds.

Solution Format

The key deliverable will be a fun and useful website built on Zcash, established on solid legal foundations, ready for viral scale and accessible to a large audience. Free2Z will offer an incredible user experience and will help drive Zcash adoption as a killer app that many users will find helpful in their day-to-day lives.

Free2Z will:

  • Be simple to use even for people who have never heard of Zcash
  • Highlight the unique properties of Zcash
  • Have extremely good privacy characteristics
  • Attract fun and engaging content
  • Get strong buy-in and engagement from the current Zcash community
  • Create positive interactions between veteran Zcash enthusiasts and new Zcash learners
  • Have A+ accessibility for all devices and all people

Technical Approach

Free2Z is software and content. The software is written in a monorepo which currently has four main components:

  • F2Z UI: React/MUI with remark/rehype, iframely, nginx
  • F2Z API: Django DRF, nginx
  • F2Z Full Node: zcashd full node - async workers in Python sync payments to DB
  • F2Z DB: A postgres database that maintains ACID state of the web application


  • F2Z UI: We will open source reusable components for Zcash such as our zip-321 rendering, QRcode displays and custom zcash markdown directives
  • F2Z Wallet integration: We plan to work with wallet/app developers to help them use F2Z API as an address directory for zaddresses.
    • We may maintain a fork of zecwallet-lite which has F2Z integrated for browsing, p2p payments and chat and contribute improvements upstream to ZWL
  • F2Z Full Node: we will examine and evaluate zebrad, lightwalletd and other software in the ecosystem to understand their strengths and weaknesses for our use cases as we add support for upcoming protocol upgrades. We will run our zcashd fullnode and be early to test new versions and provide feedback to the core devs.
  • We will likely run a complete test/staging environment that utilizes the Zcash testnet
  • The F2Z team has deep experience scaling with Kubernetes so that would be a good option to consider as the application gets more popular. Ansible would be another option for reproducible infrastructure.

A traditional webapp is easy to scale. A typical web2 webapp changes the database through an https API. The Free2Z application leverages some of the features of a typical webapp but it also listens to events from the zcashd wallet to make changes to the database. Our architecture combines the strengths of traditional web applications and web3 apps. Python/Django handles content revisions extremely well and provides a rock-solid architecture for developing CMSs and content-driven applications. At the same time, we leverage the blockchain for actions that can properly be immutable such as funding pages, commenting, etc. The inexpensiveness of revisions in traditional web apps can make them cheap for spammers, scammers and hackers to hijack web apps for nefarious purposes. This is one reason why Free2Z incorporates the blockchain for some actions which can be immutable such as funding a page, commenting and upvoting and downvoting content. Payments are the only time when content becomes immutable. Free2Z has an architecture which supports scalability, security and a healthy, spam-free ecosystem.

The software team will be working in a highly iterative, agile approach based on Bonsai which is a synthesis of XP, Lean, Kanban and Kaizen. We will be integrating changes and promoting them to production constantly. We will be reporting progress and gathering feedback transparently using issues, projects and milestones in our public github org and our public github repo.


Free2Z is innovating in a space that has a certain amount of legal uncertainty. Since the key model of private, anonymous transactions over the internet is still legally untested, we are concerned about a potential negative legal or regulatory action. For this project to be a success, we will require the support of the ZF legal team to help us to develop airtight terms of service, legal agreements and other basic contracts. By getting hands-on support from the ZF legal team, we will ensure that the Free2Z application is in compliance with relevant local and international laws. In addition to the direct support from the ZF/ECC legal team, Free2Z will retain a top law firm for additional support in case new legislation pending in the United States, Europe and other countries comes to challenge Free2Z’s platform. We expect this collaboration will strengthen the Zcash ecosystem as a whole since any potential challenges to Free2Z are likely threats to other Zcash-based applications. For Zcash to reach its full potential, the Zcash community as a whole will have to hang together in the near future in order to fend off potential legal challenges that could stifle innovation.

Execution risks

The Free2Z team has written and scaled applications using similar tech stacks to millions of monthly users. Given sufficient funding and time, we are confident of our ability to develop and scale this application with a small team, even with exponential growth.

Operations and support could incur costs when we are operating at scale with thousands of users. To avoid this overhead, we will write great docs, have clear help-text, automate as much as possible and proactively clarify what must be done for the system to work.

We plan to be profitable in the long-term. But, we have to strike a balance between prices and operational overhead in order to optimize adoption and accessibility while maintaining high quality. If we don’t get the balance right we could face the following problems:

  • Content quality suffers because we are too inexpensive
  • Operational overhead is too high because we have a lot of adoption but we are too inexpensive
  • Adoption and usage stagnates because we are too expensive

To avoid these problems, we may implement dynamic pricing; lower prices to encourage more usage, as well as higher prices to reduce operational overhead per revenue. A risk with dynamic pricing is that it would add some complexity for users; a comment may cost 0.0001 one day and 0.005 the next. With zip321 and good documentation we expect the site to be easy to use for anyone, even with dynamic pricing.

Unintended Consequences

Legal challenges

Study after study has found that cryptocurrencies are being used overwhelmingly by law-abiding people for legitimate purposes. Still, like with any open platform, there is always a chance that bad actors will utilize the platform for nefarious ends. Spammers and scammers are a key risk for the healthy maintenance of a public platform like Free2Z. The requirement to fund a page with Zcash before it becomes publicly visible has kept spammers off the website so far, but additional measures may be required with increased user growth.

A key feature on our roadmap is adding the ability to upvote and downvote a zPage by making a small Zcash deposit with a specific zip321 URI on the page. It will be easy to list and rank pages by upvotes. This will add community curation to zPages and help the pages with broadest community support to percolate to the top.

Another concern is the use of zPages to fund illegal or immoral activity. As we mentioned before, the hands-on support of the ZF/ECC legal team to write robust terms of service and well-written contracts should help us to ameliorate this concern. In addition to community policing, we will eventually have to leverage machine learning algorithms to identify problem actors as the site grows and as the size of the user base increases we will also make increased use of community monitoring; assigning clout to trusted members to help point out violations of our terms of service and other destructive activities.


Another potential concern is that Free2Z may become just another centralized service. To mitigate this risk, we will create easy ways for creators to extract their content to back it up and to move it to other sites. In addition, we will, at a minimum, open source components to make it easier for other people to build similar services. We may even create a fully open source Free2Z that people can host and customize on their own. We will likely spin off self-hosted solutions that could function like Zcash-powered Magento or WordPress sites.


Like Zcash Free2Z is built with privacy as a principle. This means:

  • Everything is self-hosted
  • No third parties without consent
  • No Personally Identifiable Information necessary

Rich media embeds and privacy don’t typically go together very well. So, by default, we will not show 3rd party embeds without the user’s consent. We will also allow users to access the F2Z public data via API instead of the UI so that they can choose exactly what they will do with the content data. For example, a wallet/app developer could choose to fetch content for pages and ignore embed directives.

Evaluation plan

Quantitative metrics that can be made public:

  • Number of creators
  • Number of zPages created
  • Number of Transactions to F2Z wallet
  • Total z2z sent to F2Z
  • Number of comments
  • Number of total hits for iframely embeds
  • Top embeds
  • Publicly available numbers from eg hypestat

We will welcome open, transparent feedback from our users in our public github org and our public github repo. Engagement and sentiment there and on our Twitter will provide an idea of how happy the Zcash community is with Free2Z.


Category Amount
Hardware/Software $0
Services $16,000
Compensation $107,000
Total $123,000


Services Budget
Cloud Services $11,000
Legal Services $5,000
Total $16,000

Cloud Services

We are running a highly scalable internet stack on VPS which should scale to millions of daily page loads without an issue. We will be caching content and optimizing page sizes. Initially we will have a production and test environment consisting roughly of the following.

  • VPS running our web application server (Gunicorn/Python/Django/Redis), reverse proxy, etc ($100/month)
  • VPS running Postgres SQL DB server ($50)
  • UI has own Ngnix, running React frontend ($50)
  • Zcash full node running on own VPS ($50)
  • No need for S3 bucket since we are using Iframely

This size will be able to get us to 1000s of reads per second and enough writes to support thousands of active users. This scale will likely get us to the end of the year. If we experience truly viral growth and massive adoption sooner, we may consider raising funds with equity or returning to make another grant proposal to go to a full HA setup with k8s and managed cloud database.

We are using Iframely to host and serve embedded rich media. Iframely charges $29 for 10,000 hits, and $400 for one million hits.

Legal Services

We will put $5,000 towards legal services to establish Free2z on a rock-solid legal footing and review documents produced by ZF lawyers.

Since this project is counting on the direct support from the legal team at ZF to help Free2Z develop terms of services and other legal agreements, the legal compensation budget that we are anticipating is quite modest. Free2Z needs $5,000 to have the documents produced by the ZF reviewed. We plan to use our own funds to retain a top law firm for additional support in the case of legal action.

We do not anticipate significant legal challenges because we plan to be extremely thorough with the initial setup and extremely transparent with our operations. However, in the case of some future legal or regulatory action against Free2Z, we will request legal support from ZF and possibly an additional grant to defend our Don’t Know Your Customer (DKYC) stance.


$107,000 USD

Type # Hours Rate Subtotal
Free2Z Feature Development 750 $100 $75,000
Test Environment, Protocol 150 $100 $15,000
Open source components 170 $100 $17,000
Total $107,000

Skylar and Jonathan will be responsible for the work.

Schedule and Milestones

We plan to operate in an extremely iterative manner. Feedback from the community will ultimately guide what gets implemented more than what we imagine months out. We expect priorities to emerge from real-world usage by the community. Top priorities may yet be unimagined. But, some things we are sure we want to complete.

Milestone 1 - MVP 1.0 - estimated completion date: 2022/05/01


MVP of Free2Z platform deployed to production. The deliverable will a UI at and api at where the committee will be able to verify the following features:

  • Create account and login without email, cellphone number or other PII
  • Able to create a zPage and fund it with Zcash wallet
  • Demonstrate private memo Zcash payload for actions: fund page, comment, etc
  • Basic https API for content
  • Documentation and video series on how to create pages and use Free2Z with basic Zcash info for curious newbies

Milestone 2 - UX, user feedback, hardening, polish - estimated completion date: 2022/07/04


Deliverable 2.1*

  • Add rich content to page, links to: (links to videos, sound, images, etc)
    • Videos
    • Sound
    • images
  • Add capacity to embed as well as scientific and mathematical formulas

Deliverable 2.2*

  • Add comments to pages
  • Upvotes and downvotes

Deliverable 2.3*

  • Attend to all issues and feedback reported by the community

Milestone 3 - Protocol and Open Source Development- estimated completion date: 2022/10/08


Deliverable 3.1*

  • Full test environment on testnet
  • Excellent accessibility
  • Thorough helptext and documentation so that the site will be easy to use for anyone, regardless of their knowledge of Zcash
  • SEO search engine optimization

Deliverable 3.2*

Open source focus will be dictated by the community demand. We will put in the referenced hours, likely focusing on some of these ideas:

  • Possible Open source contributions:
    • First version of typed Python RPC client
    • Blog post on Python RPC and guidance for further development
    • Django example. Stretch: reusable app
    • Open source Free2Z wallet
    • Reusable React Components
    • Self-hosted FOSS CMS or online store based on F2Z

Deliverable 3.3*

  • Protocol upgrades: Upgrade Free2Z to support Orchard addresses (if suitable).

Total proposed USD value of grant: $123,000 USD

If you read this far, I’m impressed! Check out some more writing on here: Free2z

I’m excited to hear what everyone thinks!


Off the cuff thought is that free2z is awesome and this does not seem that expensive for such expertise and passion. I’d even recommend upping the legal costs - lawyers are darn expensive.

Bringing passionate people to the ecosystem is priceless. Thanks for such a thorough explanation of your grant.


Thanks David! The low legal cost is predicated on ZF helping us with all of the foudational terms/conditions bootstrapping documents and being ready to help us defend those documents if we have any adversity.


Thank you for the very detailed proposal!


I’m really liking the idea of allowing for wallet integration through the APIs.

Might be a little out of scope but I’m imagining using something similar to this but in a private context. Starting a fund inviting friends to dinner and privately sharing it with them. Let them privately pay what they can afford. Etc etc…


I love Free2z! :heart:

Greetings from Venezuela.

Free2z is a powerful tool that gives content creators the great opportunity to earn income for their efforts, privately and securely.

Thank you for making it possible!


How not to love them?

Today I have a new PC thanks to the Zcashers community, thanks to Free2z.

Thanks for this! :heart:


Good news to know that Free2z is aiming for community funding with Zcash Community Grants.

I am an early Free2z user who has had the opportunity to participate in the project as a content creator and see its first steps and value proposition.

Skylar has always had a willingness to interact with the community to learn about their interests and needs to improve the development of Free2z.

I believe that Free2z has a focused approach to empower the talents and project funding opportunities of those of us who are part of the Zcash community.

In turn, F2Z is an excellent resource for engaging new Zcash users (and active members of its community), who will learn about the value of financial privacy in today’s digital age. It is very useful for both new users coming into the cryptocurrency world and those who have been in this ecosystem for a while, but know little or nothing about Zcash. The best way to learn about Zcash is by using friendly and accessible tools for all types of users. This removes any barriers and facilitates rapid adoption.

Free2z has been one of the most valuable resources that have helped me in my role as an Ambassador to recruit new Zcash members for the Spanish community. I am a witness of what this project is capable of achieving, its reach and impact both socially and economically to develop the potential of its participants.

I can’t wait to see what else Free2z will offer in the coming months and how it will impact Zcash adoption.

I support this proposal for funding, as it offers many benefits, which Skylar and Jonathan expose in a comprehensive and precise manner in their proposal.


Hi Free2Z team! First, thank you for writing this comprehensive proposal. I love that you have created a proof of concept to generate interest from the community and solicit feedback. I have some questions around the common risks associated with web applications, especially one that is handling community member funds and leverages login credentials, and the steps that you will be taking to mitigate risks such as cross-site scripting and various injection attacks that could target the platform or the end users.

  1. Can you describe your team’s familiarity and experience with the OWASP top 10 Web Application Security risks?
  2. Can you describe your team’s experience with following secure coding practices to ensure that these risks are mitigated? Does your team have code review experience tailored toward finding and mitigating these risks?
  3. Do you have at your disposal or plan to use any automated or manual tools to test the security of this application against the OWASP top 10?
  4. Have you considered working with a 3rd party to conduct an assessment of the site?

Broader questions for the community:

  1. What security standards have we imposed on web apps in the past?
  2. What standards should we ask of grant applicants? Options may include requiring testing via automated web vuln assessment tools/web app assessments by 3rd parties/peer code review (and by whom)? Develop policy to adhere to secure coding practices or mitigate against OWASP top 10 that grant applicants must agree to?

Note: There is more commentary coming about security related discussions for this and other grants. Keep an eye out for this week’s ZCG meeting minutes which should be posted later this week.


Auditing requirements

I feel the community has been lax with the security side of thing in the past. We should include the audit into the deliverables as I think your suggesting. Especially for a web app where the end user may not have the expertise to assess the risk of using a non audited app.

Have we considered if Zfnd (or ZCG) is willing to managed the audit process? I assume if we did Zfnd could contract out the audit in the beginning but as the Zcash application space expands it’d be cool if Zfnd increased their capabilities to do audits in-house on an ongoing basis.

OWASP top 10

Seems like a reasonable goal.

1 Like

Hi @wobbzz,
It’s great to get some feedback from someone so passionate about security! We feel the same way actually :slight_smile:
As regards to the OWASP top 10 Web Application Security risks, we have both had those drilled into us from years working in banking and other sectors where security represents an existential threat on a daily basis. So definitely familiar with that list; at one point I had a print-out of the top ten threats on the wall in my cubicle (back in the good old days when I still had a cubicle!)

As a developer the most exciting thing is learning new languages and frameworks and exploring new programming paradigms. However, in the case of Free2Z, our stack resists this temptation to try something new in favor of battle-tested, somewhat boring technologies that have excellent built in security (Django and React). While it makes the development work less interesting, using this solid stack allows us to avoid loads of common security risks.

At a higher level, Free2Z eliminates most serious concerns associated with financial apps by unleashing the power of Zcash. We are not a bank and at no time have custody or control over user funds. The privacy and power of Zcash make this possible!


This sounds good, yet the questions around user account authentication, security & backups are the primary concern. I can’t recollect if ZCG has funded a hybrid Web2-3 app that has a login component with a Zcash account owned by the end user. Would you mind expanding on the steps you are planning to take to handle the security of user-generated content & data?

What are the plans for improving the UX of free2z?
Would anyone be able to fork & host an instance of free2z?

1 Like

This is a really reassuring response!

I agree. I would like to see an audit but like I stated in our meeting Monday (minutes out soon) I also don’t want to hold up the delivery of awesome applications to the ecosystem. Additionally, the question came up of at what milestone of a project’s development is it best to do an audit? Should we wait for a certain user threshold to be reached?

I agree that would be cool and helpful for the community. Having an auditor on retainer is another option. We have also discussed with ZF developing an expert roster list that community members can put their name on with associated skills to be called upon to help with stuff like this and earn some Zcash.


If the project is for developers (e.g. library/tooling) then I think we can mark the repo/tooling as beta and unaudited (e.g. in GitHub readme). For ZCG funded apps where the end user is not a developer unfortunately I’m not sure we can delay some kind of review.

No idea about when the audits should occur. I guess it depends on the project. If we want a more casual and ongoing review process from community members then maybe approximately every 10,000 lines of code and structure the milestones accordingly?

:person_raising_hand:. This would be very cool. I think there is a pretty solid number of good developers in the community that’d participate in this and a good way of getting community members more involved. Definitely worth trialing the idea at any rate.


Hi @wobbzz! Thanks for the questions.

The first thing to understand about free2z and security is the attack surface area, what is at stake and what attackers can gain by attacking free2z. I’ve had several ideas for startups using Zcash over the years. But, I’ve never acted on the these earlier ideas, mainly because the threat models are too scary, the risk is too high for my comfort, the compliance and regulatory requirements too daunting and expensive. One of the main reasons I decided to pursue the prototype so vigorously is because the security is quite manageable (A04-2021). Firstly, at no time does free2z have any community member funds. Any funds that go to free2z are considered to be donations or payments to free2z and are the property of free2z. Free2z enables creators to raise funds completely peer-to-peer without intermediating these transfers. But, even without any custody or intermediation, security is still extremely important to us. Let’s consider the main possible problems that we need to be concerned with:

  • an attacker is allowed to see something they shouldn’t be able to see
  • an attacker is allowed to modify data which they shouldn’t be able to modify
  • an attacker is allowed to inject malicious content that hurts other users or the website

These are still very serious risks. So, let’s look at your questions in turn.

We are extremely familiar with the OWASP top 10. For years I did consulting for small businesses doing complete webapps including payments and PCI compliance. I went to PyCon 5 or 6 years in a row in these early days to learn all about software and security best practices and followed Django closely from about 2006. I worked for Transgaming’s GameTreeTV for a couple of years including building their API on the public internet and doing financial reconciliation, reporting financial results directly to the CFO. I did consulting for the World Bank building complete self-contained systems for geospatial data visualization (DB-API-UI). Instead of taking a full-time job in DC with the World Bank, I opted to take a Senior Developer role at JPMC in 2012. I was a leader on several teams from building an internal platform-as-a-service for other developers at the bank to use Django (including vetting all dependencies and launching internal package managers, compiling entire application environments deterministically from scratch), to working on the build team for chase dot com, arguably the biggest financial website in the world. JPMC is very serious about the OWASP top ten. I probably did 50 hours of formal training regarding OWASP in the 6 years I was at JPMC. Now I’ve been at SAP for almost 4 years. SAP is also very serious about security and I have built a very serious system at SAP that involves a lot of users and a lot of requests. The system includes a relatively complex role-based access control system that I developed. The number one concern for my team at SAP is security and we go to great lengths to make sure that our applications are secure. We discuss security best practices ad nauseam and strive to go from good to great to best. My team uses cutting-edge best practices, working closely with engineers from IaaS providers, often using new features in beta before they become best practices for other companies. Even in worst-case scenarios we have redundant safeguards in place to prevent attackers from utilizing our systems for malicious purposes.

Free2z is technically quite trivial compared to systems I have built in my career. That’s one of the reasons I wanted to build free2z: technically trivial but perhaps quite important in other respects.

I’m one of the more experienced people in the world regarding secure coding practices and code reviews. I’ve done over 500 code reviews in the last 12 months alone. I’d estimate that security is relevant in over half of these reviews. I’m the top all-time contributor to a codebase with millions of lines of code and over 50 contributors.

We have FOSS tools that scan our dependencies for vulnerabilities (A06-2021). Everything is currently fresh and green. Stale dependencies are a major potential source of concern over time. I’m an expert at CI/CD, deterministic builds and maintaining dependencies. So, as long as I’m engaged, dependencies shouldn’t be a problem. By idiomatically using quality, up-to-date FOSS dependencies, a portion of the top10 vulnerabilities (that could be found via automated scan) become irrelevant for such a small app. Some 99% of the code for free2z is in the very mainstream open source dependencies.

The biggest concern in the top10 for free2z, in my opinion, is “broken access control” because that’s where the custom code and business logic is that can’t be very easily scanned for. In this case, the best solution is probably comprehensive unit tests that make sure no regression allows users to perform actions which they should not be able to perform (like editing someone else’s page).

I haven’t had any plans to use anything in particular as far as automated OWASP scanning. I’m doubtful that such scans would find anything because ultimately the webapp is a very straightforward example of idiomatic nginx+react+django+postgres. Do you have an example of an automated scan service/product/tool which might be helpful? I’m open to suggestion and always welcome more eyes.

The surface area is small; so, we should be able to pretty thoroughly work over the system. I just added an API spec that everyone is welcome to look at: F2Z API. It’s embarrassingly unpolished and some things in there are wrong. But, feel free to try to find vulnerabilities - especially problems with the access control.

I opened a bounty for security flaws for 3 ZEC and recently raised the bounty to 7 ZEC. No one has found anything significant yet. But, the community has come through with a few suggestions for best practices that we have acted on.

I haven’t really given it much thought to be honest - beyond the bounty I posted and soliciting help from the community. I talked to Saad for a good while today and he did an informal mini-audit for me. He was unable to find an attack. But, he did point out some basic best-practice things like turning on HSTS, turning off server version info and bumping/removing a few stale frontend versions (that I don’t use in a dangerous way anyways). Nothing he found could have been readily exploited to hurt the site or users. I did send him 0.25 for his efforts.

I like the idea of a ZF-affiliated community team or 3rd party that can regularly audit websites that get funded through grants. Passing a security audit could be a condition of funding - the team requesting the funding has to attend to everything reported by the security-audit team. That way, the community perhaps gets a bit of economy-of-scale and each small team doesn’t have to be totally on the hook for finding their own vulnerabilities and every site which receives a grant can have a sort of “ZF seal of security” approval.



There is nothing special about authentication with free2z. The only thing we support right now is a plain, boring, industry-standard session cookie that is the default for Django. We can easily add JWT and other options for API access. We can also add any 3rd party oauth, if people want - Twitter, Github, Google, etc. This would all be done with off-the-shelf, popular, battle-tested Django open source components. Nothing really to remark on. Passwords are stored salted and hashed according to the latest industry standards. Everything is over SSL with HSTS without exception.


See my response to wobzzz. In practice the main points of concern are:

  • Sanitizing input
  • Safe rendering
  • Not completely fumbling the simple access controls

"a login component with a Zcash account owned by the end user"

I’m not sure if you mean to imply custody with your phrasing Zcash account owned by the end user. Currently payments can come to free2z with the following intents:

  • page_fund (fund, upvote)
  • page_defund (downvote)
  • page_comment (make comment and upvote page)
  • page_decomment (make comment and downvote page)
  • general donation
  • donation on a particular topic (like p2p but free2z is the creator/recipient)

Everything that arrives in the F2Z wallet is the property of free2z (and is swept out of the hot wallet with a very low threshold).


The user data that free2z holds is as follows:

password (stored hashed and salted with industry standards)
zPage data (title, content, p2paddress, category, timestamps …)

That’s actually it right now. The entire database is currently 287K. In the case of dramatic success, we might opt for a managed DB solution like GSQL. Or, going a different route, we might buy physical hardware and start our own datacenter :smiley:. For now, I’m fine pushing prod database backups around manually and using standard solutions - encryption, passwords, standard opsec - to keep the data from falling into the wrong hands. But, this actually does bring up a pretty important question of where the data should ultimately live and how the site should ultimately be hosted. I really like GCP and GSQL as convenient products - backups are constant and you rarely/never need them; but, it’s a little expensive for a personal hobby project IMO. With this grant, we may put everything on GCP. But, do we really like Google? Is there a comparable service that is more privacy-centric? I’m open to suggestions about hosting. We only need basic commodity hardware, standard Linux stuff, good connectivity. Since everything is currently done with my own personal time and funds, I find cheap VMs to be adequate. Realistically, in the short-mid term, this will be fine and we will add cores, ram and more machines as needed.

We’ll be using my own One Bonsai agile methodology to constantly go to production with the biggest improvements for the least effort. If you have a specific ask or problem then you can file an issue and/or ping on Twitter.

Or, I really like using small notes in GH projects since the team is so small:

Probably not but maybe. I think generic components and basic examples would probably be more useful as open source than the entire site. But, maybe if there is a lot of demand for self-hosted free2z or a lot of people who want to make real contributions to the code need access we can make it open source.


Thanks @birdify for the feedback about your experience with OWASP WebApp risks. It’s good for the community to know that you have these principles in mind when creating this application and good to know that the application will not have custody or control over user funds.

@skyl I appreciate that you and @birdify are giving serious thought to the attack surface of Free2Z and are even going a step further to proactively offer bug bounties and accept community support to test and review the platform. Given that you are not a custodian of funds for the users of Free2Z my thinking was more along the lines of the attack surface points that you outlined.

Thanks for being open to auditing. These are great ideas.

I’ve taken some training in Web App penetration testing. It has never been a full-time responsibility of mine, but in my current role I used a commercial web app vuln scanner called Acunetix to scan some acquired technical debt. This helped my team find and decommission some serious vulnerabilities after manually testing/confirming their presence (and saved us a lot of time). I normally don’t like to put too much trust in automated scanning capabilities but I’ve had the opportunity to compare its findings to an assessment led by an industry respected 3rd party and would recommend it. This tool has a “continuous monitoring” capability as well. This is ideally a tool that a ZF-affiliated community team or 3rd party would leverage like you mentioned above. There may be other tools available too.


I’d actually love a 3rd-party security audit. I can even give access to the code. It wouldn’t probably be my first choice of how to use scarce resources. But, I’d certainly rather have it than not. I wouldn’t have any problem with grant funds being contingent on us remediating anything found by a ZF-associated security team. I think it would be good general practice for web stuff funded by ZF so the community can share without reservation. It would stink if everyone in the community started sharing a ZF-funded website and then it turned out to have a serious security problem. That’s what we used to call “reputational risk” at the bank.

As for timing, I’d say earlier is better in our case. Once the fundamental foundations are confirmed as solid, it should be pretty easy for us to ensure each increment doesn’t introduce something fatal. We will write unit tests for the access-control related business logic so our continuously-to-production methodology doesn’t cause a fat-finger regression.


Hey @skyl , Thanks for reaching out to me regarding the status of this grant. As per our conversation earlier today, the ZCG discussed this grant yesterday and has the following two pending items in regards to Free2Z :

  1. Since ZF cannot provide legal support to grant applicants in any capacity, please update the grant proposal with a retainer legal budget. This amount will be separate from your estimated startup-legal costs and milestone deliverables and be available to use(released from ZF) whenever you have legal expense needs. (see the May 2 ZCG meeting notes when available).
  2. For the security audit, we request your input to create an RFP to source code auditors that have experience in reviewing your code stack. We will be in touch with you in the coming weeks regarding this.

Once the @ZcashGrants have the updated grant proposal amounts, we can arrange a mobile vote towards the grant to meet the intended milestone dates for this proposal.