Frankenwallet: DIY boot drive for privacy, security & SPO

[GENERAL] Name and surname of main applicant

Robert Phair

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

Individual

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

9

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

No

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

Document, test, improve, and launch a public repository for the Frankenwallet: a DIY bootable high security environment for privacy, light wallets, stake pool operations, and secure record keeping.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

No

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies.

[GENERAL] Will your project’s output/s be fully open source?

Yes

[GENERAL] Please provide here more information on the open source status of your project outputs

The output web site will be almost entirely documentation (including perhaps a few human readable scripts), so it will be best covered by the CC BY-SA 4.0 (Attribution, ShareAlike) license. This differs from the default "Attribution" CC BY 4.0 in that derivative works must also be open sourced according to the same license.

The NonCommercial component for Creative Commons licensing doesn't seem well suited to the open source promotion of this material, because of drawbacks given here (Wikimedia: The Creative Commons licencing scheme: NC – NonCommercial) including restricted use in academic contexts and prohibition on Wikipedia itself. Therefore CC BY-SA 4.0 appears best to support growing communities around open source documentation.

As with all Creative Commons licenses, it also includes a well-known standard limitation of liability which makes it very clear — vitally for the persistence of this project — that users employing the Frankenwallet in the management of their secure assets will be doing so at their own risk.

[METADATA] SDG rating

As would any educational tool that promotes technological security and self-sufficiency, the Frankenwallet could be used in service of any of the SDG goals without supporting any goal(s) in particular. Likewise the success of this project would not be measurable by any of the KPIs that are suggested in that framework.

[SOLUTION] Please describe your proposed solution.

The Frankenwallet is a documentation project for building a do-it-yourself (DIY) platform for the privacy and security of cryptocurrency holdings and operations.

A bootable device built according to these instructions is likewise called a Frankenwallet. Note therefore the Frankenwallet is not a product or an installable piece of software: it is a tool a user or operator will build for themselves from open-source, peer-reviewed documentation.

Though the scope of features is quite different than the commercial "hardware" wallet, it is intended to offer a similar security assurance — mainly, isolating one's private keys from an insecure networked environment — but with appeal to users and operators who prefer to control their own private keys rather than trusting them to a "black box" of incompletely known design and behaviour.

This project has already been under development since first employed in the COSD stake pool launch in August 2020, and has been publicly documented since January 2021. So far this solution has seen private use, with interest from other developers and DIY enthusiasts, but has not yet achieved its potential as a part of Cardano's standard offerings for privacy and operational security.

The author and proposer Robert Phair believes that achieving this full potential is a matter of focused user / developer outreach, with repeated cycles of improvement based on user feedback, while executing a plan for specific improvements based on popular use cases and expectations of community support and open source documentation.

Since this project is planned and budgeted at 9 months, an expected March 2024 onboarding for Catalyst Fund 11 means Cardano community would have a working, community tested and validated procedure, with its own GitHub repository and web site, before the end of 2024.

Status of the Frankenwallet at this time:

At cosd.com/frankenwallet is a roughly 40-page web microsite with a draft set of installation guides, standards and templates enabling readers to install and use a removable Linux OS drive (the "Frankenwallet") as a highest-security, air-gapped transaction signing environment with the ability to manage and store encrypted files and archives.

When one's primary computer is booted from this removable drive, operators can do all these things while completely isolated from Internet access:

• store and work securely and flexibly with private keys
• sign transactions and securely keep records of transaction details
• securely manage a Cardano stake pool, its pledge, and its private keys
• execute complex command line transactions, e.g. token minting and NFT creation
• follow prepared instructions from saved blockchain data and save encrypted files on the "insecure" host machine
• make encrypted backups without ever revealing keys or passwords in the insecure host environment.

In addition to this "cold" or air-gapped configuration, providing maximum privacy and security, a second "cool" configuration was documented which allows functionally limited Internet access. This provides greater usability, but less security... yet much more privacy and security isolation than a user's regular desktop environment.

Users of this "cool" Frankenwallet have a dedicated Linux OS on which to keep their web-based browser wallets, interact with dApps and DEXes, and securely encrypt wallet secrets like passphrases for backup and storage in the outside world — without ever exposing their crypto portfolio and private data to the security risks of their regular desktop environment.

In either case, since it runs entirely from a removable drive, the Frankenwallet offers the option not to have a second machine or hardware wallet for secure Cardano operations.

It also offers to bridge the gap between the devoted Cardano community and long time enthusiasts of other cryptocurrencies. For instance Ethereum users extending or migrating to Cardano will have a common tool to generate addresses, keys and transactions offline: since the flexible Linux OS will allow Cardano and these other blockchain CLIs to be installed in the same environment.

For an an abridged version of the Frankenwallet setup procedure, see the official Cardano Foundation page on the Developer Portal (SPO Tools: Get Started with the Frankenwallet).

Improvements to the Frankenwallet in the course of this proposal:

The following steps — to convert the existing proof of concept into a well known, validated community tool — are the basis for this project's milestones and budget. These are tagged to correspond to the MILESTONES section below, and each represent about 1 month of work over a 9-month period to delivery:

(1a) Convert all pages in draft e-book into GitHub Markdown or HTML pages - As well as standardising this material, this will enable community contributors and reviewers to submit changes and improvements as more people begin using the platform.

(1b) Configure Jekyll or equivalent to build front end site from GitHub material - Installing a process to build a public web site, in e-book form, from the GitHub material: which can simply be followed by users and operators as any other reference, documentation or tutorial.

(1c) New content creation (1 of 2): Use cases - As well as filling in any omissions in the existing material, adding documentation and tutorials for the newer "cool" configuration supporting user wallets.

(2a) Community invitation to review web site design and content - Announcing to Cardano users and developers that this material is available for open testing and public comment, beginning 6 months of response to issues and discussions raised on the new GitHub repository.

(2b) New content creation (2 of 2): Special cases in privacy, security, and operations - Researching and documenting: tutorials for privacy use cases (e.g. developer key sharing, "will and testament"); security workflow; installing Frankenwallet on an encrypted part of a main disk.

(3a) Install SPO Scripts and test in Frankenwallet, then add documentation - Proving Frankenwallet can be used as a functional replacement for the "Air Gap" second machine long recommended to Cardano stake pool operators, even if using the operator scripts in addition to the bare Cardano command line interface.

(3b) Publication, testing, and evaluation with SPO scripts - Soliciting and incorporating responses from the SPO community about using the Frankenwallet and the SPO scripts together; beginning 3 months of final test, with a demanding user base, for all uses of the Frankenwallet.

(4a) Improvement based on SPO feedback, addressing tech issues - Roughly a one-month period to address any major design or documentation issues identified by the SPO community, and to improve the general quality of online documentation for the general user community.

(4b) Resolving GitHub issues / discussions, video tutorials, final reporting - Video demonstrations will be expected for the 3 major use categories (command line, SPO scripts, and user wallets), with a review and report of the full 9 months of GitHub linked + verified progress, and the usual Catalyst demonstration close-out video.

NOTES about the name "Frankenwallet"

Technical readers should please observe the name is unrelated to the Franken address — an informal reference to the more standard term mangled address for a Cardano address of mixed origin.

Also, the term "wallet" — intended to relate applications and target audience to the proprietary "hardware wallet" — is also used differently than for wallet apps, because the Frankenwallet does not actually manage funds. Yet the term is now officially applicable according to recent definition of a "zero-data" wallet which relies upon the user to store addresses, assemble transactions and manage keys: all done manually in the Frankenwallet by deliberate record-keeping, prepared procedures and operator scripts.

See this page on the draft web site (Why "Frankenwallet") for the full story of its name and origin.

[IMPACT] Please define the positive impact your project will have on the wider Cardano community.

Target audience: general use cases

(condensed and updated from the Frankenwallet documentation at the e-book introduction page) The Frankenwallet will be useful to anyone who:

• needs to use a software wallet on their desktop system, but does not want to expose wallet passphrases and spending passwords to browser- and Internet-based attacks;
• needs to work directly with cryptocurrency private keys, especially payment keys or other high value resources targeted by hackers;
• operates a stake pool, and doesn't want to keep a second dedicated "air gap" machine or transfer account and pool keys on an unencrypted memory stick;
• wants read + write access to all their computer files and folders while working in a secure, Internet-restricted environment;
• believes a hardware wallet or its use will be betray the owner's identity, or lose the owner's funds, either by design flaw or by the design itself;
• wishes a hardware wallet could have the flexibility and user-friendly features of a full-fledged operating system;
• wants to keep encrypted records of everything from wallet passphrases to transaction purposes, saved on one's main computer for easy local and off-site backup;
• etc.

Target audience: vs. the hardware wallet

Vocal members of the Cardano community have long insisted that funds are only "safe" when they are on a hardware wallet, in spite of the facts that:

• Early in Cardano's life cycle, Ledger exposed the identity of a huge number of its users (2020-12-20: Ledger users threaten legal action after hacker dumps personal data)
• Hardware companies routinely construct devices to facilitate universal surveillance by intelligence and law enforcement agencies (e.g. NSA Laughs at PCs, Prefers Hacking Routers and Switches)

It is beyond the scope of both this proposal and the Frankenwallet documentation to convince the reader that there are security or privacy problems with hardware wallets. The impact of this proposal is simply that users will now have a choice to take privacy and security into their own hands with a device of open source origin to use instead.

For more points to consider about this part of the community impact, see:

• draft Frankenwallet page (But I can afford a hardware wallet...)
• hardware wallet vs. Frankenwallet approach in Cardano Forum discussion.

Means of engagement and success measurement:

Web site - first order of engagement (for users)

All software and crypto communities are contacted most often by users looking for documentation and tutorials. The Frankenwallet development plan will ensure the new site frankenwallet.com is a commonly known resource in the Cardano community for building an "air gap" / SPO environment or more securely hosting their web-based wallets. Measurements of success would be:

• KPI: web site visitors per day
• KPI: search engine performance for "Frankenwallet" other common search terms

GitHub material - Deep-level engagement (for reviewers, experts and community leaders)

Here the source material for the web site will be accessible along with its own development history and any user-requested dialogue and interaction. Anyone with a GitHub account, even outside of the Cardano community, will be able to post comments and suggestions through these standard features which can also be counted as KPIs to measure progress:

• GitHub issues - problem reports, and sometimes requests for help; can be tagged with "bug" (something wrong with documentation) vs. "feature" (suggested improvement)
• GitHub discussions - serving same role as Forum for discussions focused on certain threads (e.g. Frankenwallet topics affecting usability, security, web site presentation)
• GitHub pull requests (PRs) - change records and discussions of when changes are made to content - these can also be contributed by community members

Note that Issues, Discussions and PRs will all be visible on the top bar of the GitHub repository itself, so anyone looking at the repository will be able to get a good view of its growth and community engagement at any point during the project.

GitHub also has the distinct advantage over social platforms like Telegram and Discord in that

• it does not require KYC for participation (important for a privacy-related subject)
• all comments and interactions create permanent links which are visible to the public: promoting complete visibility to the Cardano community and for Catalyst auditing.

Users, contributors or auditors interested in following the Frankenwallet project will only have to select the Watch button on the top bar in GitHub to subscribe by email to any or all of the key events above.

Catalyst monthly reports

Impact can also be measured through reports of site development and feedback, broken down by the type of interaction and particular issue. For examples of how these reports will look, see the latest reports in this repository for the proposer's concurrent Catalyst funded project (github.com/rphair/cip-editing).

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

How this approach can be confirmed feasible now

Considering that the Frankenwallet is documentation rather than a developed product, it been feasible from the first time it was documented (in mid-2020) for private use in building a real stake pool and protecting its pledge. All working models used in the author's stake pool operations since then have also been following this documentation.

The Cardano Foundation's Developer Portal has also provided an endorsement of the Frankenwallet, effectively confirming its feasibility by expert reviewers, by including it with the officially listed Operator Tools.

How it can be confirmed feasible at future iterations

After Milestone 1 of this project (see next section), all subsequent milestones will solicit community feedback in which any problems can be pointed out by any GitHub user by filing an "issue" (as directed on the new web site). Therefore every substantial change will be followed by a round of review in which problems affecting feasibility will be documented and corrected.

Managing of funds

Not relevant in this case because the material expenses are minimal and will be abundantly covered by the initial project payment:

• Domain (frankenwallet.com) - already purchased and can be renewed at proposer's expense.
• Cardano infrastructure - all local equipment and Cardano nodes necessary for testing have already been procured for the COSD stake pool and are already paid for by the proceeds from the pool.

[Project Milestones] What are the key milestones you need to achieve in order to complete your project successfully?

Build collaborative documentation web site sourced from GitHub

Months 1 through 3

Starting with prior material for the Frankenwallet (at cosd.com/frankenwallet), migrate all pages to GitHub files at repository github.com/rphair/frankenwallet and use automated site building tools and front-end design methods to produce a finished, public-ready web site from this material: editing the previously drafted material in the process.

The development process will be similar to these standard instructions (GitHub Actions: building a Jekyll site with GitHub Pages) and include CSS + HTML theming and integration features for "headless" static web design: similar to the process to build the Cardano Developer Portal from these source files (github.com/cardano-foundation/developer-portal).

Milestone outputs (from SOLUTION section)

• (1a) Convert all pages in draft e-book into GitHub Markdown or HTML pages
• (1b) Configure Jekyll or equivalent to build front end site from GitHub material
• (1c) New content creation (1 of 2): Use cases

Acceptance criteria

• Web site has method to build either automatically or on demand from GitHub content.
• Method to build and update web site is documented on new web site itself.
• Resulting site has e-book navigation (TOC / outline, with previous / next buttons).
• Resulting site has collaborative features (shows author, links back to GitHub material).
• Resulting site has a modern theme with readable text, images and command lines.
• All pages in draft site outline are either present or their content included on the new site.
• Removed old content, e.g. obsolete configuration for "node wallet" (Daedalus).
• New web content: update and clarify "SPO Templates" from draft site.
• New web page: how to choose whether you will need a "cool" or a "cold" Frankenwallet.
• New web page(s): "cool" configuration supporting primary use case of security and privacy for light (browser based) wallets.

Initial peer review and user testing, adding security and operational scenarios

Months 4 and 5

The project will be opened up to public review, primarily based on two documented use cases so far: the "cold" (air gapped) configuration for secure use of Cardano keys via the CLI, and the "cool" (restricted Internet) configuration for more security; private use of light wallets and dApps; and encrypted record-keeping.

As this progresses, some complex issues not present in the original Frankenwallet documentation will be addressed:

• Tutorial(s) for using Frankenwallet to assemble confidential crypto instructions containing passphrases and keys, as for keys and other "secrets" shared with developers or a "Will and Testament" document
• Additional configuration path to put the Frankenwallet on an encrypted partition of a computer's own disk, rather than an external drive
• Subjective content answering such questions as, "How do I know my key backups are encrypted safely?" or "Why are my passphrases safe in an encrypted LibreOffice document?"
• Support and Disclaimers: official definition of "support" (e.g. we can't fix your computer if you break it following these instructions, but YES we can improve our site based on your experience) and emphasis on "Limitation of Liability" from our Creative Commons license

Milestone outputs (from SOLUTION section)

• (2a) Community invitation to review web site design and content
• (2b) New content creation (2 of 2): Special cases in privacy, security, and operations

Acceptance Criteria

• Links to postings on Cardano Forum, in all applicable categories (SPO, Developers, general) directing interested users to the Frankenwallet site.
• New site page(s): Contribution and/or Community, explaining process of GitHub issues and discussions.
• New site page(s): How to put Frankenwallet on an encrypted partition of an internal drive (experts only)
• New site page(s): Addressing user security reservations about software encryption
• New site page: Creating a Will and Testament document
• New site page: Sharing private keys with other developers
• New site page(s): Support (definition of what maintainer does and doesn't do), and Disclaimer of warranty and liability
• Links for "feedback" and "contribution" accessible from web site footer and/or header.
• (In Catalyst reports) Summaries of user interaction via any GitHub issues and discussion, from announcement month onward.

Integration with stake pool operator scripts, testing with SPOs

Months 6 and 7

The Cardano StakePool Operator Scripts have been used since 2020 and have a huge body of users who are expected to maintain pool keys and secure their pledge on dedicated "air gap" machines, but without any standard instructions being provided to build these machines. Procedures for setting up their secure environment have mainly been circulated by the Telegram "SPO Best Practices" workgroup and in isolated postings on the Cardano Forum.

This period will focus on Cardano SPOs and begin a 3-month validation period to ensure stake pool operators feel comfortable using the Frankenwallet in their workflow, with all relevant information about setting up this environment documented on the web site, with all pending improvements documented on GitHub as they emerge from this point onward.

Exposure of SPOs to the Frankenwallet, followed by any refinements to the procedure and documentation based on this interaction, is likely to produce the best improvments to the Frankenwallet due to their high expectations of security, for convenient workflow, and for complete, high quality documentation.

Milestone outputs (from SOLUTION section)

• (3a) Install SPO Scripts and test in Frankenwallet, then add documentation
• (3b) Publication, testing, and evaluation with SPO scripts

Acceptance Criteria

• New web site section and pages: Installing and using the SPO Scripts
• Announcement via Telegram Cardano Stake Pool Best Practice Workgroup with any indicative responses: offering Frankenwallet and asking for feedback
• Announcement via SPO Scripts repository issue and links to any indicative responses: suggesting Frankenwallet to the maintainer and key contributors, asking for feedback
• Announcement via Cardano Forum in SPO group, asking operators to install and test with the SPO Scripts
• Summary of all page creation and editing based on user and SPO feedback for this period
• (In Catalyst reports) Continued summaries of user and SPO interaction via any GitHub issues and discussion

Final improvements, product-calibre delivery, closure

Months 8 and 9

This period is used to further elaborate any operational or security scenarios identified by the SPO community as needing improvement. SPOs will also be interested in the "cool" configuration of web-based wallet isolation and are likely also to submit feedback about it. This period will draw all pending test cases together and post any required new material on the web site.

The user community, and likely milestone reviewers, would also expect a video based on each of the major use scenarios in addition to the Catalyst close-out video based on the project as a whole, so the final month will produce video illustrations of the 3 proven configurations ("cold" with CLI, "cold" with SPO scripts, and "cool" with browser wallets + dApps).

Milestone outputs (from SOLUTION section)

• (4a) Improvement based on SPO feedback, addressing tech issues
• (4b) Resolving GitHub issues / discussions, video tutorials, final reporting

Acceptance Criteria

• Summary of all page creation and editing based on user and SPO feedback for this period
• (In Catalyst reports) Continued summaries of user and SPO interaction via any GitHub issues and discussion: indicating either closure OR why remaining open
• Video: "cold" Frankenwallet + CLI: command-line management of Cardano keys and transactions
• Video: "cold" Frankenwallet + SPO Scripts: walk-through of scripts installation + main stake pool operations
• Video: "cool" Frankenwallet + user wallets: usage for browser wallets + dApps, with guidelines for security and privacy
• Video (project close-out): setup overview, and final reporting on project as per Catalyst specifications.
• Final written report, as per Catalyst specifications.

[RESOURCES] Who is in the project team and what are their roles?

The entire project will be executed by Frankenwallet inventor / documentation author Robert Phair, in the following roles:

• Technical writer - web content development, illustration and tutorial writing
• Platform architect - deploying content on GitHub to build continuously as public web site
• Web Designer - theming for public-facing web site, with navigation UI / UX
• Software tester - pre-emptive testing during documentation, duplication of user problems
• GitHub repository maintainer - response, prioritisation, tagging and coordination of issues and discussions

General credentials, contacts and media channels:

GitHub: rphair

Twitter (X) business handle: @COSDpool

Cardano Forum: @COSDpool

Qualifications for Cardano standards and documentation:

An official editor of the Cardano Foundation CIP repository, its #1 most counted contributor and GitHub repository co-maintainer.

Cardano Developer Portal: the #1 most counted contributor outside Cardano Foundation and GitHub repository collaborator.

Author of Security section on Developer Portal, including standards for Air Gap Environment and Secure Transaction Workflow.

Provided first public documentation of whole CIP Process at Medium article series beginning here (Cardano Improvement Proposals (CIPs) — Introduction from an Insider).

Cardano standards (CIPs): CIP-0013 co-author and current maintainer.

Cardano Summit, September 2021: Standards panellist on Governance track

Qualifications for interaction with community (users, developers, SPOs):

Discord > CIP Editors Meetings official server (invite): Editor role, CIP helping hand on #general channel.

Group moderator of CIP Room, Cardano Professional Society (independent members-based organisation).

Stake pool operator since beginning of Shelley era (COSD: low-fee single pool) since Q3 2020; seven-time winner and current holder of Cardano Foundation community delegation.

Operations, project management and web design experience:

UNIX/Linux systems integrator, project manager, CMS web designer, and software standards architect since late 1980's (C.V. / Resume).

Computer industry consultant with thirty years of professional experience in systems integration, networking, programming / design, technical writing, and project management.

Business advisor for cloud computing, online marketing + commerce, data security, technical training and emerging technologies.

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources.

See MILESTONES for a full description of these tasks, and VALUE FOR MONEY for an explanation of these two bill rates:

• Content hours = 150 ada per hour (routine writing and content creation)
• Development (dev) hours = 300 ada per hour (work requiring expert qualification)

Each of these 9 project tasks documented in MILESTONES is planned for 1 project month (9 months total) and budgeted for 4 weeks (36 weeks) containing 70 hours each 4-week period (average 17.5 hours per week).

Each milestone will also have an additional allocation of 10% of the total hours for public documentation including Catalyst written reporting (see VALUE FOR MONEY for justification). These additional 4 weeks of work (36 + 4 = 40 weeks total) will be distributed evenly across each milestone.

Milestone 1 (Months 1-3) = Building collaborative documentation web site

1a) 60 content + 10 dev = Convert old material to GitHub (2 hours * 30 key pages + tech review)

1b) 20 content + 50 dev = Integrate GitHub material into new site (mainly devops + some content)

1c) 40 content + 30 dev = Existing page improvement, additional topics + research

Total hours = 210 hours = 21 hours reporting

Content budget = (120 + 21) * 150 = 21150 ada

Dev budget = 90 * 300 = 27000 ada

TOTAL = 48150 ada

Milestone 2 (Months 4-5) = Improving and documenting robust privacy + security procedures

2a) 40 content + 30 dev = Community review, technical responses

2b) 20 content + 50 dev = Continued review, advanced topics + security scenarios

Total hours = 140 hours = 14 hours reporting

Content budget = (60 + 14) * 150 = 11100 ada

Dev budget = 80 * 300 = 24000 ada

TOTAL = 35100 ada

Milestone 3 (Months 6-7) = Integration with Stake Pool Operator scripts

3a) 70 dev = Integration with SPO scripts

3b) 40 content + 30 dev = Community review with SPOs + fine-tuning procedures

Total hours = 140 hours = 14 hours reporting

Content budget = (40 + 14) * 150 = 8100 ada

Dev budget = 100 * 300 = 30000 ada

TOTAL = 38100 ada

Milestone 4 (Months 8-9) = Validation, video documentation and reporting

4a) 40 content + 30 dev = Improvement based on SPO feedback, addressing tech issues

4b) 70 content = Resolving GitHub issues / discussions, video tutorials, final reporting

Total hours = 140 hours = 14 hours reporting

Content budget = (110 + 14) * 150 = 18600 ada

Dev budget = 30 * 300 = 9000 ada

TOTAL = 27600 ada

GRAND TOTAL = 48150 + 35100 + 38100 + 27600 = 148950 ada

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

Establishment of project bill rates:

ADA/USD rate at project submission (2 hours before deadline): 9AM UTC 30 Dec (4AM UTC 30 Dec) = $0.373206

Therefore hours in BUDGET + COSTS are billed at:

Content hours = 150 ada per hour (equivalent 0.373206 * 150 = $56 / hour), corresponding to reasonable rates for commodity web design and technical writing, for these project tasks:

• Content generation: Web copywriting; public digests of user experience and project progress; video production
• Community engagement: GitHub documentation; user / reviewer enquiries and responses via GitHub

Development hours = 300 ada per hour (equivalent 0.373206 * 300 = $112 / hour), corresponding to a reasonable rate for full stack web development and operational consulting (standard = $150 per hour), for these tasks:

• Research: OS Security, Linux system architecture, encryption tools
• Development of "headless" content management system, built with devops tools from GitHub source into public web site

Catalyst reporting NOTE - "Project Management", "Overhead" and "Reporting" for Catalyst projects are generally around 15% of the project bid, especially for agency-delivered projects. Therefore the addition of 10% the total number of hours for Catalyst routine documentation (also content in the project repository) is both reasonable and realistic.

Q: What if the hours allocated for community feedback and response aren't used?

Firstly, the allocated time will be spent on improving the final product in any case. I (the author and proposer) can personally guarantee a public-facing web site based on these materials will keep getting critiqued and refined based even on informal feedback and suggestion, in anticipation of whatever questions and difficulties users and developers might have in the future.

Secondly, this material has already been in development for 3 years (since mid-2020) without any payment. This has already taken well over 100 hours of writing and at least as many hours testing and refining that documentation. Therefore any perceived excess in budgeted costs would be offset by the huge amount of time I have already volunteered to this project. :)

[IMPORTANT NOTE] The Applicant agrees to Fund Rules and also that data in the submission form and other data provided by the project team during the course of the project will be publicly available.

I Accept