escapethe3ra-monero-observer-maintenance-spring-2022.md

+---
+layout: cp
+title: escapethe3RA Monero Observer maintenance (Spring 2022)
+author: escapethe3RA
+date: February 26, 2022
+amount: 27
+milestones:
+  - name: March
+    funds: 9
+    done: 31 March 2022
+    status: finished
+  - name: April
+    funds: 9
+    done: 30 April 2022
+    status: finished
+  - name: May
+    funds: 9
+    done: 31 May 2022
+    status: finished
+payouts:
+  - date: 17 April 2022
+    amount: 9
+  - date: 19 May 2022
+    amount: 9
+  - date: 29 June 2022
+    amount: 9
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (spring 2022): March, April and May.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily/As Needed: post new *MO Community Messages*
+- Daily/As Needed: post new *MO Resources*
+- Daily/As Needed: post new *MO Calendar Events*
+- Weekly (Monday): publish the *MO XMR TA Report* (technical analysis Monero price report)
+- Weekly (Saturday): publish the *MO Artistic Saturday Top 5 Report*
+- Monthly: publish the *MO Blitz Report* (includes everything that happened the previous month)
+- As Needed: housekeeping (revise stories to make sure links and content is still relevant)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (no 404's, domain is paid, etc)
+- Optional/bonus: add new features, improvements and website sections
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August 2021 with Monero Observer and other smaller projects:
+
+- published 658 x MO stories/reports (https://www.monero.observer/stories)
+- published 24 x MO XMR TA reports (https://www.monero.observer/tag/analysis)
+- published 6 x MO Blitz reports (https://www.monero.observer/tag/blitz)
+- published 150 x MO Community Messages (https://www.monero.observer/tag/community)
+- published 5 x MO Artistic Saturday Top 5 Reports (https://www.monero.observer/tag/art)
+- created several guides on GPG encryption, RSS feeds and Monero contributors (https://www.monero.observer/ultimate-guide-new-monero-contributors/, https://www.monero.observer/gpg-cleartext-signatures/, https://www.monero.observer/gpg-generate-full-keypair/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- added a MO Calendar section (https://www.monero.observer/tag/calendar)
+- started MO Community Messages and MO Artistic Saturday initiatives (https://www.monero.observer/tag/community, https://www.monero.observer/tag/art)
+- added a MO Resources section (https://www.monero.observer/resources)
+- added multiple RSS feeds (https://www.monero.observer/rss)
+- other project improvements (https://www.monero.observer/changelog)
+ 
+# Proposal
+
+Work for 25 hours per week over 3 months at a rate of 0.09 XMR / hour. At $160 / XMR (21 daily EMA) this makes 27 XMR (0.09 * 100 * 3).
+

escapethe3ra-monero-observer-maintenance-spring-2023.md

+---
+layout: cp
+title: escapethe3RA Monero Observer maintenance (Spring 2023)
+author: escapethe3RA
+date: Mar 5, 2023
+amount: 39
+milestones:
+  - name: March
+    funds: 13
+    done: 31 March 2023
+    status: finished
+  - name: April
+    funds: 13
+    done: 30 April 2023
+    status: finished
+  - name: May
+    funds: 13
+    done: 31 May 2023
+    status: finished
+payouts:
+  - date: 7 June 2023
+    amount: 39
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (spring 2023): March, April and May.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily: update reports, stats, changelog, version control
+- Daily/As Needed: post new *MO Community Messages*
+- Daily/As Needed: post new *MO Resources*
+- Daily/As Needed: post new *MO Calendar Events*
+- Weekly (Sunday): publish the *Monero Dev Activity Report*
+- Weekly (Saturday): publish the *MO Artistic Saturday Top 5 Report*
+- (Bi)Weekly (Monday): publish the *MO Cypherpunk Transmission Report*
+- Monthly (1st): publish the *MO Blitz Report*
+- As Needed: housekeeping (revise and update reports)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (server maintenance, billing, etc)
+- Optional/bonus: publish new Monero and privacy related guides, meeting logs and summaries, add new features, improvements and website sections, start new community initiatives
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August 2021 with Monero Observer and other smaller projects:
+
+- published 1763 x daily MO stories/reports (https://monero.observer/stories)
+- published 779 x on demand MO Community Messages (https://.monero.observer/tag/community)
+- published 19 x monthly MO Blitz reports (https://monero.observer/tag/blitz)
+- published 13 x weekly MO Cypherpunk Transmission reports (https://monero.observer/tag/CT)
+- published 52 x weekly Monero Dev Activity Reports (https://monero.observer/tag/dev)
+- published 56 x weekly MO XMR TA reports (https://monero.observer/tag/analysis)
+- published 58 x weekly MO Artistic Saturday Top 5 Reports (https://monero.observer/tag/art)
+- published 16 x on demand Monero Workgroup Meeting Log Summaries & uploaded 100 meeting logs to MO (https://monero.observer/tag/logs/)
+- added 265 x on demand MO Resources (https://monero.observer/resources)
+- created several Monero, privacy and security related guides (https://monero.observer/tag/guides/, https://monero.observer/verify-install-update-monero-cli-wallet-linux-guide/, https://monero.observer/ultimate-guide-new-monero-contributors/, https://monero.observer/gpg-cleartext-signatures/, https://monero.observer/gpg-generate-full-keypair/, https://monero.observer/list-anon-email-service-providers/, https://monero.observer/read-monero-observer-terminal-newsboat/, https://monero.observer/monero-cli-wallet-cheat-sheet/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- started MO Community Messages, Monero Dev Activity Report, XMR TA Report, MO Artistic Saturday, and Cypherpunk Transmission initiatives (https://monero.observer/tag/community, https://monero.observer/tag/dev/, https://monero.observer/tag/analysis, https://monero.observer/tag/art, https://monero.observer/tag/CT)
+- added MO XMR Stats section (https://monero.observer/stats/)
+- added MO Resources section (https://monero.observer/resources/)
+- added MO Calendar section (https://monero.observer/tag/calendar/)
+- added MO Blacklist section (https://monero.observer/blacklist/)
+- added multiple RSS feeds (https://monero.observer/rss/)
+- started self-hosting a terminal-based git server containing the MO UI source code (https://monero.observer/monero-observer-self-hosted-git-server/)
+- created a hidden service for MO (https://monero.observer/monero-observer-new-server-hidden-service/)
+- other project improvements (https://monero.observer/changelog/)
+ 
+# Proposal
+
+I will work for 25 hours per week over 3 months at a rate of 0.13 XMR / hour. At $150 / XMR (21 daily EMA) this makes 39 XMR (0.13 * 100 * 3).

escapethe3ra-monero-observer-maintenance-summer-2022.md

+---
+layout: cp
+title: escapethe3RA Monero Observer maintenance (Summer 2022)
+author: escapethe3RA
+date: May 29, 2022
+amount: 36
+milestones:
+  - name: June
+    funds: 12
+    done: 30 June 2022
+    status: finished
+  - name: July
+    funds: 12
+    done: 31 July 2022
+    status: finished
+  - name: August
+    funds: 12
+    done: 31 August 2022
+    status: finished
+payouts:
+  - date: 4 August 2022
+    amount: 24
+  - date: 26 September 2022
+    amount: 12
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (summer 2022): June, July and August.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily: update stats, changelog, version control
+- Daily/As Needed: post new *MO Community Messages*
+- Daily/As Needed: post new *MO Resources*
+- Daily/As Needed: post new *MO Calendar Events*
+- Weekly (Monday): publish the *MO XMR TA Report* (technical analysis Monero price report)
+- Weekly (Saturday): publish the *MO Artistic Saturday Top 5 Report*
+- Weekly (Sunday): publish the *Monero Dev Activity Report*
+- Monthly (1st): publish the *MO Blitz Report* (includes everything that happened the previous month)
+- As Needed: housekeeping (revise stories to make sure links and content is still relevant)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (server maintenance, billing, etc)
+- Optional/bonus: publish new Monero and privacy related guides, meeting summaries, add new features, improvements and website sections, start new community initiatives
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August 2021 with Monero Observer and other smaller projects:
+
+- published 975 x daily MO stories/reports (https://www.monero.observer/stories)
+- published 37 x weekly MO XMR TA reports (https://www.monero.observer/tag/analysis)
+- published 12 x weekly Monero Dev Activity Reports (https://www.monero.observer/tag/dev)
+- published 18 x weekly MO Artistic Saturday Top 5 Reports (https://www.monero.observer/tag/art)
+- published 9 x monthly MO Blitz reports (https://www.monero.observer/tag/blitz)
+- published 294 x MO Community Messages (https://www.monero.observer/tag/community)
+- published 4 x Monero Workgroup Meeting Log Summaries (https://monero.observer/tag/logs/)
+- created several Monero, privacy and security related guides (https://monero.observer/tag/guides/, https://monero.observer/verify-install-update-monero-cli-wallet-linux-guide/, https://www.monero.observer/ultimate-guide-new-monero-contributors/, https://www.monero.observer/gpg-cleartext-signatures/, https://www.monero.observer/gpg-generate-full-keypair/, https://monero.observer/list-anon-email-service-providers/, https://monero.observer/read-monero-observer-terminal-newsboat/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- started MO Community Messages, Monero Dev Activity Report and MO Artistic Saturday initiatives (https://www.monero.observer/tag/community, https://monero.observer/tag/dev/, https://www.monero.observer/tag/art)
+- added a MO Resources section (https://www.monero.observer/resources)
+- added a MO Calendar section (https://www.monero.observer/tag/calendar)
+- added multiple RSS feeds (https://www.monero.observer/rss)
+- started self-hosting a terminal-based git server containing the MO UI source code (https://monero.observer/monero-observer-self-hosted-git-server/)
+- created a hidden service for MO (https://monero.observer/monero-observer-new-server-hidden-service/)
+- other project improvements (https://www.monero.observer/changelog)
+ 
+# Proposal
+
+I will work for 25 hours per week over 3 months at a rate of 0.12 XMR / hour. At $130 / XMR (21 daily EMA) this makes 36 XMR (0.12 * 100 * 3).
+
+*Note: After this period, Monero Observer will turn 1, marking 365 days of uninterrupted daily Monero news reporting. Thanks for being a loyal reader and supporter, I am very proud to be part of the best community out there.*

escapethe3ra-monero-observer-maintenance-winter-2022.md

+---
+layout: cp
+title: "escapethe3RA Monero Observer maintenance (Winter 2022)"
+author: escapethe3RA
+date: Nov 29, 2022
+amount: 39
+milestones:
+  - name: December
+    funds: 13
+    done: 31 December 2022
+    status: finished
+  - name: January
+    funds: 13
+    done: 31 January 2023
+    status: finished
+  - name: February
+    funds: 13
+    done: 28 February 2023
+    status: finished
+payouts:
+  - date: 14 January 2023
+    amount: 13
+  - date: 6 March 2023
+    amount: 26
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (winter 2022/23): December, January and February.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily: update reports, stats, changelog, version control
+- Daily/As Needed: post new *MO Community Messages*
+- Daily/As Needed: post new *MO Resources*
+- Daily/As Needed: post new *MO Calendar Events*
+- Weekly (Sunday): publish the *Monero Dev Activity Report*
+- Weekly (Saturday): publish the *MO Artistic Saturday Top 5 Report*
+- (Bi)Weekly (Monday): publish the *MO Cypherpunk Transmission Report*
+- Monthly (1st): publish the *MO Blitz Report*
+- As Needed: housekeeping (revise and update reports)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (server maintenance, billing, etc)
+- Optional/bonus: publish new Monero and privacy related guides, meeting logs and summaries, add new features, improvements and website sections, start new community initiatives
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August 2021 with Monero Observer and other smaller projects:
+
+- published 1494 x daily MO stories/reports (https://monero.observer/stories)
+- published 608 x on demand MO Community Messages (https://.monero.observer/tag/community)
+- published 15 x monthly MO Blitz reports (https://monero.observer/tag/blitz)
+- published 7 x weekly MO Cypherpunk Transmission reports (https://monero.observer/tag/CT)
+- published 39 x weekly Monero Dev Activity Reports (https://monero.observer/tag/dev)
+- published 56 x weekly MO XMR TA reports (https://monero.observer/tag/analysis)
+- published 44 x weekly MO Artistic Saturday Top 5 Reports (https://monero.observer/tag/art)
+- published 12 x on demand Monero Workgroup Meeting Log Summaries & uploaded 57 meeting logs to MO (https://monero.observer/tag/logs/)
+- added 231 x on demand MO Resources (https://monero.observer/resources)
+- created several Monero, privacy and security related guides (https://monero.observer/tag/guides/, https://monero.observer/verify-install-update-monero-cli-wallet-linux-guide/, https://monero.observer/ultimate-guide-new-monero-contributors/, https://monero.observer/gpg-cleartext-signatures/, https://monero.observer/gpg-generate-full-keypair/, https://monero.observer/list-anon-email-service-providers/, https://monero.observer/read-monero-observer-terminal-newsboat/, https://monero.observer/monero-cli-wallet-cheat-sheet/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- started MO Community Messages, Monero Dev Activity Report, XMR TA Report, MO Artistic Saturday, and Cypherpunk Transmission initiatives (https://monero.observer/tag/community, https://monero.observer/tag/dev/, https://monero.observer/tag/analysis, https://monero.observer/tag/art, https://monero.observer/tag/CT)
+- added MO XMR Stats section (https://monero.observer/stats/)
+- added MO Resources section (https://monero.observer/resources/)
+- added MO Calendar section (https://monero.observer/tag/calendar/)
+- added MO Blacklist section (https://monero.observer/blacklist/)
+- added multiple RSS feeds (https://monero.observer/rss/)
+- started self-hosting a terminal-based git server containing the MO UI source code (https://monero.observer/monero-observer-self-hosted-git-server/)
+- created a hidden service for MO (https://monero.observer/monero-observer-new-server-hidden-service/)
+- other project improvements (https://monero.observer/changelog/)
+ 
+# Proposal
+
+I will work for 25 hours per week over 3 months at a rate of 0.13 XMR / hour. At $135 / XMR (21 daily EMA) this makes 39 XMR (0.13 * 100 * 3).

escapethe3ra-monero-observer-website-2.md

+---
+layout: cp
+title: escapethe3RA Monero Observer maintenance (3 months)
+author: escapethe3RA
+date: November 25, 2021
+amount: 21
+milestones:
+  - name: December
+    funds: 7
+    done: 31 December 2021
+    status: finished
+  - name: January
+    funds: 7
+    done: 31 January 2022
+    status: finished
+  - name: February
+    funds: 7
+    done: 28 February 2021
+    status: finished
+payouts:
+  - date: 16 January 2022
+    amount: 7
+  - date: 16 February 2022
+    amount: 7
+  - date: 20 March 2022
+    amount: 7
+---
+
+# What
+
+I will continue to maintain *Monero Observer* (https://monero.observer) for the next 3 months (winter 21/2022): December, January and February.
+
+Tasks:
+
+- Daily: search, curate, structure and post new reports/stories
+- Daily/As Needed: post new *MO Community Messages*
+- Weekly: publish the *MO XMR TA Report* (technical analysis Monero price report)
+- Monthly: publish the *MO Blitz Report* (includes everything that happened the previous month)
+- As Needed: housekeeping (revise stories to make sure links and content is still relevant)
+- As Needed: outreach (engage with the community on Matrix, Reddit, XMPP, emails)
+- As Needed: make sure the website is live and working as expected (no 404's, domain is paid, etc)
+- Optional: add new features, improvements and website sections
+
+# Who
+
+escapethe3RA, I have started contributing to the Monero ecosystem in August with Monero Observer and other smaller projects:
+
+- published 356 MO stories (https://www.monero.observer/stories)
+- published 11 MO XMR TA reports (https://www.monero.observer/tag/blitz)
+- published 3 MO Blitz reports (https://www.monero.observer/tag/analysis)
+- created several guides on GPG encryption, RSS feeds and Monero contributors (https://www.monero.observer/ultimate-guide-new-monero-contributors/, https://www.monero.observer/gpg-cleartext-signatures/, https://www.monero.observer/gpg-generate-full-keypair/)
+- redesigned *Monero Means Money* website, donated bounty to GF (https://moneromeans.money/, https://github.com/escapethe3RA/monero-means-money/)
+- started MO *Community Messages* initiative (https://www.monero.observer/tag/community)
+- other project improvements (https://www.monero.observer/changelog)
+ 
+# Proposal
+
+I will work for 25 hours per week over 3 months at a rate of 0.07 XMR / hour. At $220 / XMR (10% buffer) this makes 21 XMR (0.07*100*3).
+

escapethe3ra-monero-observer-website.md

+---
+layout: cp
+title: Monero Observer news website
+author: escapethe3RA
+date: August 23, 2021
+amount: 15.99
+milestones:
+  - name: September
+    funds: 5.33
+    done: 30 September 2021
+    status: finished
+  - name: October
+    funds: 5.33
+    done: 31 October 2021
+    status: finished
+  - name: November
+    funds: 5.33
+    done: 30 November 2021
+    status: finished
+payouts:
+  - date: 15 October 2021
+    amount: 5.33
+  - date: 16 November 2021
+    amount: 5.33
+  - date: 15 December 2021
+    amount: 5.33
+---
+
+# WHAT
+
+I will maintain **Monero Observer**[^1] for the next 3 months (autumn 2021): September, October and November.
+
+Essentially:
+
+- DAILY: search, curate, structure and post new content (CHANGELOG available: https://www.monero.observer/changelog/)
+- AS NEEDED: housekeeping (revise stories to make sure links and content is still relevant)
+- AS NEEDED: outreach (engage with the community mainly via email to encourage participation and get new stories/tips faster)
+- AS NEEDED: make sure the website is live and working as expected (no 404's, domain is paid, etc)
+- WEEKLY: publish Monero XMR TA Report, a weekly XMR technical analysis report (reference: https://www.monero.observer/tag/analysis/)
+- MONTHLY: publish Monero Observer Blitz, a monthly report that includes everything that happened the previous month (reference: https://www.monero.observer/tag/blitz/)
+- (BONUS, OPTIONAL) AS NEEDED: publish Monero & privacy/opsec-related guides (reference: https://www.monero.observer/tag/guides/)
+
+# WHO
+
+Myself: escapethe3RA, a Monero enthusiast, a private citizen.
+
+# WHY
+
+I strongly believe that the Monero community would benefit from the existence of the Monero Observer, both right now and in the long run.
+
+While there are a few other places where people can get news and stories from around the Monero community, I am proposing a slightly different and more efficient approach.
+
+Here are some of my thoughts:
+
+- we need a dedicated Monero-only news website that is being run by someone in our community, privately
+- the general writing style should resemble a journalistic approach, based on facts and as little opinion as possible
+- clean, minimalist interface, no bloat, few images
+- references/sources should never be absent from each post; furthermore the author should seek to prioritize privacy-respecting platforms and thus share the links to those if possible (ie. invidio.us instead of youtube.com, nitter.net instead of twitter.com)
+- readers must be allowed unrestricted access to the stories, privately via tor (zero Javascript, no cookies, no tracking or any kind of analytics service, no pop-ups, no newsletters, no CDN, no captchas, no ads whatsoever)
+- smaller stories should also be covered whenever possible, in order to support and encourage community participation in a decentralized way, the Monero way (individual bloggers, small time alt platform video and guide makers, tiny merchants)
+- search engine juice should be allowed to flow to every site in the community and disabled (rel=nofollow) for big tech sites (in the references/src links)
+- advertising should be approached very conservatively and human-to-human contact should be prioritized whenever possible (think: email still works, word of mouth will never die, if you build something they will come so have a strong foundation ready;)
+- stay away from mainstream centralized social media if possible; RSS should be encouraged, it's still the best (IMHO); potentially add decentralized social accounts (ie. federation) in the future 
+
+There's more, but I believe these notes should suffice for now.
+
+I have already taken the liberty to dedicate my past couple of weeks to this project: find a voice and well defined structure for the content, design the website, research and write the posts, add reference links and deploy.
+
+You can visit the website and get a glimpse of my work so far. Before I continue with the project in this direction I need the community's feedback and approval. If you think this would be useful, comment and support my proposal. Thoughts, constructive criticism and discussions are encouraged.
+
+If you wish to contact me you can do so by sending me an email (address on the website's about page, PGP key available for sensitive content).
+
+# MILESTONES
+
+The work hours that I have already put in this month will **not** be counted towards this proposal. First of all I wanted to know approximately how many hours I'd need to put in beforehand and secondly I wanted to show up with a PoC.
+
+I am proposing to maintain Monero Observer for the next three months of autumn: September, October and November at a rate of $15/hour, 80 hours a month. The total is 15.99 XMR at the rate 1 XMR == $225 (~10% buffer from current Kraken price).
+
+Thus, there will be three milestones, 5.33 XMR each, paid on the last day of each month: 30 September, 31 October, 30 November.
+
+If all goes well and the community finds the project useful we can discuss 2022 plans.
+
+Thanks for reading!
+
+Ta-ta,
+**escapethe3RA**
+
+[^1]: https://monero.observer

fcmp++-development.md

+---
+layout: wip
+title: Full-Chain Membership Proofs + Spend Authorization + Linkability Development CCS
+author: kayabaNerve
+date: April 13, 2024
+amount: 920 XMR
+milestones:
+  - name: Provide a specification of the circuit and high-level protocol
+    funds: 80 XMR
+    done:
+    status: unfinished
+  - name: Productionize the crate for the arithmetic circuit proof
+    funds: 160 XMR
+    done:
+    status: unfinished
+  - name: Productionize the crate for the Elliptic Curve Divisor Library
+    funds: 80 XMR
+    done:
+    status: unfinished
+  - name: Implement the gadgets
+    funds: 320 XMR
+    done:
+    status: unfinished
+  - name: Implement the circuit
+    funds: 200 XMR
+    done:
+    status: unfinished
+  - name: Implement the Generalized Schnorr Protocol
+    funds: 40 XMR
+    done:
+    status: unfinished
+  - name: Implement multisig for the Generalized Schnorr Protocol
+    funds: 40 XMR
+    done:
+    status: unfinished
+
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+This CCS is to develop Full-Chain Membership Proofs (a trustless solution) into Monero under RingCT, replacing the existing CLSAG. This is distinct from prior intents to integrate FCMPs into Monero with Seraphis, and was prior discussed in a [MRL meeting](https://libera.monerologs.net/monero-research-lab/20240401) with well reception. That same meeting organized the [funding of security proofs for Generalized Bulletproofs](https://ccs.getmonero.org/proposals/cypherstack-gbp-security-proofs.html), a critical component for FCMPs (under both this proposal and Seraphis). This builds upon the [work prior done on FCMPs](https://ccs.getmonero.org/proposals/kayabaNerve-fcmp-retroactive.html), and does most of the ground work for FCMPs with Seraphis as well.
+
+The exact deliverables will be:
+- A document detailing the arithmetic circuit (a 'ZK program') and necessary integration work
+- A ready-for-auditing Rust implementation of an amenable (trustless, formally proven, sufficiently performant) arithmetic circuit proof (currently expected to be Generalized Bulletproofs)
+- A Rust library for calculating elliptic curve divisors
+- The FCMP proof, as necessary for usage with RingCT
+- The GSP (Generalized Schnorr Protocol) proof acting as the signature, with multisignature functionality
+
+### Milestones
+
+The milestones are unordered, barring the first to provide a specification. The gadgets will be specified as a series of constraints in a non-machine-interpretable manner intended to allow human understanding and review of the flow and composition. With the definition of the proofs (largely modelled as black boxes to the protocol), all of the supporting infrastructure will also be defined as necessary to comprehend the integration into Monero and new privacy protocol created.
+
+"Productionize the crate for the arithmetic circuit proving system" means to develop the arithmetic circuit proof implementation to the point I endorse auditing it. With those audits, the crate would be eligible for usage in production. Any audits of the implementation would only be sane after the proof implemented is formalized, with security proofs. Currently, the proposed proof is GBPs, and security proofs for it are actively being worked on. If they fail to be proven, this milestone is worded in such a way an alternative proof (with acceptable properties, from being trustless to sufficiently performant to building upon sufficiently accepted academia) may also be accepted. If there are no alternative proofs acceptable, this milestone will be considered not possible at this time, and for the purposes of this CCS, 'failed'.
+
+"Productionize the crate for the Elliptic Curve Divisor Library" means to develop the crate for calculation of divisors into a point it can be audited.
+
+"Implement the gadgets" means to implement the prior-specified gadgets, and all supporting code for them, such that they are ready for soundness proofs, formal verification, auditing, and etc.
+
+"Implement the circuit" means to implement the prior-specified circuit, and supporting high-level functions, to the degree described for the gadgets. This will also include an implementation of the towering curve cycle, Helios and Selene, though not one expected to be performant enough for deployment.
+
+"Implement the Generalized Schnorr Protocol" means to implement the [Generalized Schnorr Protocol](https://eprint.iacr.org/2009/050.pdf) as needed for Monero's usage.
+
+"Implement multisig for the Generalized Schnorr Protocol" means to implement a 2-round multisignature protocol, inspired by FROST, for the aforementioned Generalized Schnorr Protocol. This would have O(n) signing complexity and identifiable aborts.
+
+All of these milestones will be done myself, kayabaNerve. Integration into Monero will be handled externally to this CCS, with jberman stating their intent to submit their own CCS. The steps for integration (regarding new protocol structures and how data such as the tree root will be specified/used when verifying transactions) will be part of the specification from the first milestone.
+
+### Audits
+
+https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/449 establishes an earmarked fund for paying for audits, as necessary for all of the work produced by this CCS. The justification for this structure is mainly provided within that CCS, and is considered out of scope to this CCS.
+
+### Relation to Seraphis
+
+GBPs, the Elliptic Curve Divisor library, the circuit specification (except the first layer), and the gadgets apply to a deployment of FCMPs with Seraphis (making this work largely reusable even if we don't move forward with FCMPs *before* Seraphis). The only part which wouldn't explicitly is the first layer of the circuit (which is currently expected to be composed of two distinct layers) and potentially the Generalized Schnorr Protocol work (as they are not currently used by Seraphis, yet I have proposed their use within Seraphis).
+
+This work, if extended with the forward-secrecy discussions held *and all associated wallet code necessary*, would also be feature-complete with Seraphis. This would leave Seraphis, the protocol, a simpler/potentially more performant protocol, not an upgrade to privacy. This CCS, as currently specified, does not intend to detail all of the wallet upgrades which would be necessary (leaving that to future hard forks, keeping the scope of this concise and minimizing the timeline till deployment).
+
+### Other Necessary Development
+
+As aforementioned, integration must also be done, and development of a performant implementation of the towering curve cycle. While jberman has spoken up for the former, another party will need to be found for the latter (such as tevador, who found the cycle and has expressed domain expertise). Barring finding another party for the latter, I would have to personally learn how to implement efficient modulo arithmetic and step up (a problem left to the future).
+
+### Failure
+
+If the work within this CCS for any reason fails, the funds raised and remaining (held by core, per the rules of the CCS) will roll over into a general MRL research fund to sponsor further research and development, such as proofs for and review of Seraphis. The direction of and process for this new fund will be decided and agreed upon such a roll over occurring by core and discussions within MRL. The idea for this was premised on the idea of hiring researchers, Cypher Stack specifically, on retainer with the MRL having discretion over how those hours were spent. That was discussed at the same meeting as this proposal (proposal as in cryptographic idea, not proposal as in CCS proposal) with sufficiently well reception for me to propose it as the fallback here.

fcmp++-research.md

+---
+layout: wip
+title: "Full-Chain Membership Proofs + Spend Authorization + Linkability Research CCS"
+author: kayabaNerve
+date: April 13, 2024
+amount: 2000
+milestones:
+  - name: Provide a soundness proof for the proof using Elliptic Curve Divisors (MAGIC/Veridise)
+    funds: 70
+    done:
+    status: unfinished
+  - name: Formally verify the gadgets
+    funds: 0
+    done:
+    status: unfinished
+  - name: Prove the composition to be unlinkable, unforgeable, and non-malleable
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the Implementation of GBPs
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the Elliptic Curve Divisors Library
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the implementation of the gadgets
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the implementation of the circuit
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the implementation of the Towering Curve Cycle
+    funds: 0
+    done:
+    status: unfinished
+  - name: Audit the implementation of the Generalized Schnorr Protocol
+    funds: 0
+    done:
+    status: unfinished
+payouts:
+  - date: 22 May 2024
+    amount: 198
+  - date: 30 May 2024
+    amount: 70
+  - date: 13 August 2024
+    amount: 38
+  - date: 25 November 2024
+    amount: 38.5
+  - date: 13 December 2024
+    amount: 118.5
+  - date: 7 March 2025
+    amount: 53.43
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+This CCS is to prove, review, and audit Full-Chain Membership Proofs (a trustless solution based on Generalized Bulletproofs) into Monero under RingCT, replacing the existing CLSAG. This is distinct from prior intents to integrate FCMPs into Monero with Seraphis, and was prior discussed in a MRL meeting with well reception. That same meeting organized the [funding of security proofs for Generalized Bulletproofs](https://ccs.getmonero.org/proposals/cypherstack-gbp-security-proofs.html), a critical component for FCMPs (under both this proposal and Seraphis). The review and audits here would also lay the ground work for FCMPs with Seraphis as well.
+
+All of these milestones have "?" for their required funds. The goal of this CCS is to raise the funds necessary to contract various external parties. All XMR will be held per the usual CCS policy, by core, until the necessary agreements are made for each milestone. The intention of this is to prevent needing to file several CCSs (addng delays) and to minimize the amount of confusion re: funding efforts. I do not want to have to justify to the community, after 5 CCSs for audits, why a 6th one is still justified and FCMPs aren't a black hole of endless fundraises for audits.
+
+Unfortunately, that last note cannot be completely unavoided. Since there are not auditors ready for each and every milestone, this CCS may run out of funds prior to completion of all milestones (requiring another CCS). The amount chosen (2000 XMR, roughly 230k USD) was chosen on the belief it's reasonable for the scope described. Due to the subject matter (ZK proofs and circuits) currently being one of the hottest fields in the cryptocurrency space at large, with both startups and VCs, I'm unable to provide any such guarantee.
+
+With that note, it may sound optimal to do individualized CCSs. That'd not only add weeks/months to the process (as some of these audits are serialized, so a delay in one adds to the delay in the next), it'd risk being unable to contract certain auditors. In my experience, auditors schedule as long as months out *from time of agreement*. In the time it takes to discuss the proposal and raise the funds, auditors' availability schedules may shift dramatically, including in rates (shifting the amount necessary/adding a deadline for the discussion and fundraising). Hence this proposal.
+
+kayabaNerve and jberman are the people primarily expected to find such parties, with the actual agreement on parties and amount to be by their endorsement, and a general agreement within MRL that the proposed expenditure is reasonable. The word choice of reasonable means that the proposed parties are reasonably trusted to be able to adequately perform the work proposed, the amount to be paid is understandable and amenable, and if there are other potential parties, none are clearly, completely, and definitively better choices. 
+
+If the work within this CCS for any reason fails, or completes with a remaining balance, the funds raised and remaining (held by core, per the rules of the CCS) will roll over into a general MRL research fund to sponsor further research and development, such as proofs for and review of Seraphis. The direction of and process for this new fund will be decided and agreed upon such a roll over occurring by core and discussions within MRL. The idea for this was premised on the idea of hiring researchers, Cypher Stack specifically, on retainer with MRL having discretion over how those hours were spent. That was discussed at the same meeting as this proposal (proposal as in cryptographic idea, not proposal as in CCS proposal) with sufficiently well reception for me to propose it as the fallback here.

feather-2020.md

+---
+layout: cp
+title: Feather wallet GUI development
+author: Feather team
+date: 1 September 2020
+amount: 188
+milestones:
+  - name: 1st milestone
+    funds: 94
+    done: 3 September 2020
+    status: finished
+  - name: Alpha release
+    funds: 94
+    done: 20 October 2020
+    status: finished
+payouts:
+  - date: 3 September 2020
+    amount: 94
+  - date: 23 October 2020
+    amount: 94
+---
+
+# What
+
+Feather is an [upcoming open-source desktop Monero wallet](https://www.youtube.com/watch?v=tylbteVtwrw) with some interesting features. It has been in development for over a year. Community reception thus far has been quite positive.
+
+- [/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/](https://www.reddit.com/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/)
+- https://twitter.com/xmrdsc/status/1297275505704685568
+- https://twitter.com/xmrdsc/status/1297620436184899585
+- https://twitter.com/xmrdsc/status/1297906498899775490
+
+A lot of work has gone into the project. The Feather team is excited about what has been developed and could use funding to support the cause of releasing this FOSS application, as there is still a couple of months left to bridge before release.
+
+## TO-DO
+
+We have most functionality working, the challenges ahead are:
+
+1. Static builds for Windows and Mac OS
+2. Upstreaming various patches to `src/wallet/api/wallet2_api.h` (CLI - that libwalletqt (GUI) can use, mostly additions).
+3. Creating and hosting a dedicated static website.
+4. Hosting both high performance clearnet and Tor remote nodes.
+5. Hooking up buildbots to our git for nightly builds
+6. Node switching inside the application.
+7. Testing to ensure the wallet is stable and robust
+8. Fixing platform-specific bugs
+
+## CCS
+
+Previously, dsc_ made [a proposal](https://ccs.getmonero.org/proposals/dsc-2019-q2.html) for Monero GUI development for which he has completed 1 out of 3 milestones. We believe it would be beneficial if those funds could be used to support finishing our Feather wallet project instead, as both proposals are regarding GUI work, we feel Feather is more important/impactful to the community.
+
+We would like to use the remainder of the 2 milestones, the first being distributed **now**, to support ourselves while working on Feather, and the second milestone will be reached in (hopefully) October, when we go into alpha. 
+
+Feather will:
+
+- Release code under the Monero License.
+- Self-host the website/issue-tracker/git-repositories (and also make it available through Tor).
+- [dsc__](https://www.reddit.com/user/dsc__) and [tobtoht](https://www.reddit.com/user/tobtoht) will maintain future releases.
+- Upstream wallet2 changes so that the Official GUI may borrow functionality.
+- Deliver something great to the Monero community.
+
+## What can we expect during alpha relase?
+
+It will include most functionality - Linux and Mac OS.
+
+1. Our repositories (Feather, websocket back-end (Python)) will be opened to the public
+2. The community has the ability to test and give suggestions, create PRs
+3. Static Linux builds via Docker (Qt 5.15.0) on an Ubuntu 18 base image
+4. Self compilation required (we will not distribute static binaries)
+
+We are targetting October.
+
+The alpha version takes place on stagenet and it'll be an opportunity to test integration with various Linux distros. Bugs can be reported and managed on our self-hosted issue tracker. People running Mac OS are free to participate in the testing, but our focus will largely be on Linux.
+
+## What can we expect on release?
+
+1. Linux / Mac OS static binaries
+2. A website with pgp signed binaries and documentation
+3. Upstreaming of wallet2 changes
+4. The features described in our [announcement post](https://www.reddit.com/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/) and [video](https://www.youtube.com/watch?v=tylbteVtwrw)
+5. A robust/fast Linux/Mac OS Monero wallet.
+
+We believe a full release in December is realistic.
+
+## What can we expect after release?
+
+- Windows support (Q1 or Q2 2021, [cross compilation attempts here](https://git.wownero.com/feather/mxe/commit/a6ed6f3c323c301dcdeed3fc685fce4b993d8900))
+- Multi-sig (Still exploring the various options, [more info here](https://www.reddit.com/r/Monero/comments/ikiv8t/what_we_need_for_adoption_is_trivial_multisig/g3l7os6/))
+- Debian package
+- Wallet refresh over clearnet, transaction submission over Tor
+- Feather as a websocket server (to be announced)
+
+We will continue to maintain Feather after release, however any **significant** feature updates (such as multisig) may require additional funding through a separate CCS depending on the time and effort required to implement them.
+
+## Ending note
+
+We have been careful to make certain promises on timelines and features in this CCS proposal - mostly due to the complexity of the project. We target deadlines but delays may occur. However, we've already got a lot finished (as can be seen in [our video](https://www.youtube.com/watch?v=tylbteVtwrw)).
+
+If we are not able to raise funding, it will be delayed notably as we will have to find ways to support ourselves. In that case the application will of course still *eventually* release under an open-source license, somewhere in 2021.
+
+

gingeropolous_1TB_MRC.md

+---
+layout: cp
+title: Gingeropolous 1TB MRC upgrade
+author: Gingeropolous
+date: November 9, 2024
+amount: 20
+milestones:
+  - name: Install 1TB ram in new epyc server
+    funds: 100% (20 xmr)
+    done: 24 January 2025
+    status: finished
+payouts:
+  - date: 3 February 2025
+    amount: 20
+---
+
+
+1TB ram for new MRC server
+
+I finally purchased a new epyc server, and I need to get ram for it. I was just going to get the minimal needed to make the thing mine some xmr, but figured we can pack this thing to the gills to provide some monstrous compute capacity for monero R&D.
+
+For some background, I manage the Monero Research Computing cluster, which is essentially just my mining rigs that I've put more ram and storage in. I provide access to the MRC to various monero researchers and developers, so they can get some stuff done. The rigs mine when there is no activity by the users. 
+
+Currently, monero researchers are primarily using the box "Junior", which is a 64 thread AMD Ryzen Threadripper 3970X with 256 GB ram (max ram for the mobo). There is a 5x nvme striped lv thingy that allows for some fast swap, but its still just swap. This rig was upgraded years ago through the CCS (https://ccs.getmonero.org/proposals/gingeropolous_zenith_storage.html) to provide ample storage space for researchers (74 TB HDD - funded by me, 14TB nvme - funded by CCS), as working with the monero blockchain requires storing and moving massively large files. I have other boxes, but they are your average mobo that can take a max 128 GB. Rucknium has been able to do some distributed compute across all the boxes (at one point 7 or so boxes?), but I've found most folks just want a single box with massive amounts of ram. 
+
+This proposal is for funds for me to purchase 1 TB of ram to install in a new 2x 7h12 server (256 threads!) so monero researchers can stop fiddling with memory constraints when working or waiting for the poor 64 threads to chug through their tasks. The system maxes out at 4 TB (!!!!), so perhaps if funding goes over the request and hits enough to get more ram, then that will happen. 
+
+This is important for the community because more compute ==  more research capabilities for monero researchers. This request was already brought up during a monero research lab meeting, and the members were interested in adding this capacity to our cluster. 
+
+Milestone 0 isn't included, because its me purchasing the 2x epyc server. I just did that. So thats done. 
+
+Milestone 1 is when I have the 2x epyc server up and running with 1TB of ram installed. I'll take a screen shot and upload it. 
+Timeline: 3 months? This should all be done by 2025-02-01 at the latest, but I expect this to be up and running by 2025-01-01.
+
+Amount: I plan on purchasing this ram:
+https://www.ebay.com/itm/225753803091
+
+So that comes out to around 15 xmr. I'm requesting 20 xmr for some padding and to pay for some of my time and I'll probably end up buying more stuff I wouldn't need for mining (like a 4TB nvme for the box because always more storage). If I receive a lot over the requested amount, I'll consider either finding higher quality ram (anyone have any input on that A-tech stuff?) or more ram. 
+

gingeropolous_zenith_storage.md

+---
+layout: cp
+title: Research Computing Upgrade
+author: Gingeropolous
+date: May 10, 2022
+amount: 51
+milestones:
+  - name: Expand data storage on existing server
+    funds: 27
+    done: 26 July 2022
+    status: finished
+  - name: Month 1 support 
+    funds: 8
+    done: 26 July 2022
+    status: finished
+  - name: Month 2 support 
+    funds: 8
+    done: 23 August 2024
+    status: finished
+  - name: Month 3 support 
+    funds: 8
+    done: 24 August 2024
+    status: finished
+payouts:
+  - date: 27 December 2022
+    amount: 35
+  - date: 4 September 2024
+    amount: 16
+---
+
+# Gingeropolous CCS Request
+
+
+Hello all! This CCS proposal is to fund me to work part time on monero in various capacities, fund some monero research computing infrastructure, and to support my official training in Computer Science. I am a long time member of the monero community, and I've always wanted to dedicate more time to Monero. I am in a place professionally where I can potentially pivot to become "full time monero" if support is available. I have a lot of projects that have interested me over the years. This first CCS is to increase the storage capacity of a particular machine, as Rucknium is embarking on a project that needs a lot of fast storage. In addition, I also requests funds for my time. In the future, I plan on submitting additional CCS requests to further improve computational and storage infrastructure for the monero research and development community, perform various monero R&D, and begin my official computer science education / training. 
+
+# Who:
+
+I am Gingeropolous, long time community member and tinkerer. Over the years I've worked on various things in Monero. Notable things include webmin for xmrchain.net, testing fluffyblocks on mainnet (https://www.reddit.com/r/Monero/comments/6dords/help_test_fluffyblocks_compact_blocks_whatever/), and being sometimes the only mining pool for testing PoW variants during the ASIC war (remember killallasics.moneroworld.com ?). For some background, I do hold a PhD in a field of biomedical science, and I am/was a Research Assistant Professor. I came into monero years ago with no cryptocurrency, linux, or software development experience - but I've been building and working with computers for decades. I've had a lot of help from many monero contributors, and I feel i've reached a point of competance that I hope is valuable to the project. This CCS will hopefully be my first of many. During the dedicated and protected time (that I will request in the future), I hope to become even more valuable to the project through various training, infrastructure, and research activities. I have already begun my path to getting a Masters in Computer Science by working on the pre-requisite courses, as I have nothing on paper that indicates that I will perform well in a CS degree. 
+
+# What: 
+
+## Infrastructure: high end servers and tools for monero development and research
+
+## Specific to this CCS: Funds to increase storage on existing hardware to fascilitate current research
+
+I would like to build, maintain and administrate high-end servers for monero development and research in a cost effective manner. From my own experience in monero, it's ideal if you can just do things faster. Build something, test it / run it, tweak something, do it again. Time spent waiting for the computer to do something means you lose time and momentum - and this momentum, and time in general, is scarce for open source contributors that mostly contribute in their free time. Thus, I plan on providing high end servers to the monero developer and researcher community. Lots of ram, virtually unlimitted storage, and threads everywhere. 
+
+I've already done this at a small scale with my own funds, providing access to my existing mining hardware (with some additional memory and storage upgrades just for monero R&D) to researchers like Sarang, Rucknium, and ack-j; members of the Noncesence Research Lab, and developers like TheCharlatan, mj-xmr, jberman. For example, ack-j recently told me "Hey so that the multiprocessing worked great yesterday and saved an estimated 100 days compared to running it on my VM with 1 thread." Renting this kind of hardware from a hosting provider can get expensive. Furthermore, CCS investments in this infrastructure represesent one-time investments. Once it is built, I will provide access to the monero R&D community as long as I can keep the lights on (with or without community funding). The end goal of this effort (built over the years) will be a veritable research computing cluster with job scheduling etc (if people want that - sometimes direct shell is just easier). For the time being though, it will be much simpler - custom VM provisioning (if needed) and dedicated metal. Additionally, I will provide i2p and/or onion connections to allow any member of the community to use the resources in a private manner.  
+
+Granted, the building of this infrastructure creates an obviously centralized thing, and I'm not a huge fan of that. For the time being, I think it will be OK, but part of my future effort will include a way by which other monero folks rich in computer resources (e.g., those with big monero mining ops) can add their computers to a global monero research computational resource. To this end, a future project will include scripts that allow for anyone to launch their own Monero Research and Development cluster. For instance, a way for someone to build their own databases etc. 
+
+## Existing infrastructure in the Monero Research Computing garage:
+HPE Proliant DL325 Gen10 AMD EPYC 7402P 48 thread, 64 GB RAM
+ASUS Zenith 2 Alpha with 64 thread Threadripper 3970x , 256 GB ram, 2TiB NVME, 24TiB HDD. (I maxed out the RAM on this one)
+some sad old opterons with 96 GB ram
+~6 3900x AMD systems with 16-64gb ram and various storage abilities.
+1 1920x threadripper with 32gb ram 
+old laptops so we can run performance tests on scrap
+
+UPS:
+
+N1C L-series 3000VA 
+
+Network:
+1 gbps up/down with unlimitted bandwidth
+1 gbps 48 port network switch
+
+# Funds requested in this CCS:
+A. 5 * 4096 Gb  NVME SSDs to max out the high-speed storage capability of the Zenith 2 Alpha. Market prices have these around $1k.  Currently considering Kingston KC3000 M.2
+
+B. 3 months of part time salary support and partial costs: this will allow me to spend more time with the hardware (for instance, that new UPS isn't installed yet), focus on computer science pre-reqs, and assist with electrical costs. During this time I will also assist with whatever Monero things I can assist with - usually these involve testing software and trying to find bugs. I will also put more time into helping folks on Reddit, IRC, and Matrix. I am requesting $1500 a month. 
+
+# Timeline / Milestones:
+
+Storage: I will purchase the drives upon full funding of the request, and request a payout once I provide a screenshot of the drives mounted. 
+Monthly: I will provide an update (roughly a month) when I feel I have completed enough to warrant a payout.  
+
+I have calculated the XMR based on the USD fiat price of ~~$165~~. $185 (roughly using the daily 21 ema as of commit) 
+
+I am open to any suggestions for this proposal. 
+
+Expiration 2022-12-01 (YYYY-MM-DD). If not all claimed, released to the general fund. 
+
+51 xmr total, 27 for SSDs, 8x3 for monthly support

gupax.md

+---
+layout: cp
+title: "Gupax: GUI for P2Pool+XMRig"
+author: hinto
+date: 10 October 2022
+amount: 100
+milestones:
+  - name: Working GUI + Documentation
+    funds: 80% (80 XMR)
+    done: 20 December 2022
+    status: finished
+  - name: 1 year of maintenance
+    funds: 20% (20 XMR)
+    done: 28 December 2023
+    status: finished
+payouts:
+  - date: 22 December 2022
+    amount: 80
+  - date: 9 January 2024
+    amount: 20
+---
+
+![banner.png](https://github.com/hinto-janaiyo/gupax/raw/main/images/png/banner.png)
+
+## What
+[Gupax](https://github.com/hinto-janaiyo/gupax) is a cross-platform GUI for [P2Pool](https://github.com/SChernykh/p2pool)+[XMRig](https://github.com/xmrig/xmrig). I was really happy when Monero GUI implemented P2Pool directly (many users seem to be using it) however, the embedded miner is slower than the dedicated XMRig miner. Unfortunately, integrating XMRig directly into Monero GUI is a no-go mainly due to [anti-virus issues.](https://github.com/monero-project/monero-gui/pull/3829#issuecomment-1018191461) Personally, I also think keeping Monero GUI's scope simple (monerod+wallet) is the way forward. Either that, or a properly implemented [plugin system.](https://github.com/monero-project/monero-gui/pull/3829#issuecomment-1018406709)
+
+Gupax is a completely seperate GUI that can act as a companion alongside Monero GUI. One window with monerod+wallet, and another for P2Pool mining (with XMRig used for max hashrate!). It can act standalone as well, connecting to a remote node so no Monero node is needed.
+
+## Why
+There are a couple (abandoned) GUIs for XMRig, and 1 for P2Pool (Monero GUI). There are 0 for both combined. These two together are only accessible via the command line, which is not ideal. If you take a look at [/r/MoneroMining](https://www.reddit.com/r/MoneroMining) at any given moment, there will be threads where people are confused on how to set everything up. I'm 100% certain if there was a simple GUI solution people could point at ("just use Monero GUI + Gupax"), there would be many, many more miners on P2Pool. [On August 12th when MineXMR shutdown](https://www.reddit.com/r/Monero/comments/wb7a9s/minerxmr_is_shutting_down_august_12th_and), had a P2Pool+XMRig GUI existed, I'm certain it would have gained a much more significant chunk of the total hashrate. Instead, much of it went towards to the 2nd/3rd largest centralized pools.
+
+I've been facinated with p2p mining even before SChernykh created Monero's P2Pool. Bitcoin's P2Pool was also seen in the same way as Monero's P2Pool is seen today, but the community neglected it, development stopped and it died off. The massive corporate ASIC farms popping up and making deals with centralized pools did not help either. [Here's an example thread from 2014](https://reddit.com/r/Bitcoin/comments/1uii40/p2pool_is_a_completely_decentralized_mining_pool). It is eerily similar to the Monero threads I read today.
+
+I'd like P2Pool to live on and be accessible to as many people as possible. The current Monero GUI implementation is great, but I want everyone to have access to the ***full hashrate*** of what their machines are capable of.
+
+## Implementation
+- **OS:** Gupax will be tested for Windows, macOS, and Linux. Maybe the BSDs (see "Questions" below)
+- **Docs:** All Gupax usage will have documentation on GitHub; General P2Pool/XMRig info will also be included
+- **Packaging:** Gupax will be packaged in a bundled zip/tar that includes P2Pool/XMRig, and as a standalone binary that expects you to bring your own P2Pool/XMRig. Both will be the same binary, only difference being the first will include all necessary components. Maybe an installer as well (see "Questions" below)
+- **Efficiency:** I don't normally care about resource usage too much because (although not ideal...) most computers can afford to run heavy programs. However, the context for Gupax is a ***mining*** machine, it would be too ironic if it impacted the hashrate performance, and so, Gupax uses the very lightweight [Rust egui library](https://github.com/emilk/egui). By default egui is an "immediate mode" GUI, meaning frames are rendered 60x/sec. This is turned off in Gupax so frames are only rendered upon user interaction. This allows for a fast and lightweight GUI. For context, it uses around 5x less CPU when switching around tabs compared to Monero GUI
+
+## Planned
+- **Community Node:** An option to use a trusted community Monero node instead of your own. At a small privacy cost, this allows users to immediately start mining on P2Pool without downloading the entire chain
+- **Update:** Built-in update/upgrader for Gupax/P2Pool/XMRig and an (opt-in) auto-updater that runs at startup
+- **Config:** All the basic configurations you would expect with P2Pool/XMRig (main, mini, peers, thread count, etc)
+- **Status:** Status tab displaying mining statistics using P2Pool & XMRig's APIs
+
+## Demo
+Here's a demo of a working GUI prototype:
+
+![](https://user-images.githubusercontent.com/101352116/194763334-d8e936c9-a71e-474e-ac65-3a339b96a9d2.mp4)
+
+[More info and the source/binaries can be found here](https://github.com/hinto-janaiyo/gupax). Please give it a try and leave feedback.
+
+## Who
+I'm [hinto-janaiyo](https://github.com/hinto-janaiyo).
+
+I created and maintain [monero-bash](https://github.com/hinto-janaiyo/monero-bash), which is also an effort to spread P2Pool usage. Frankly speaking, I think monero-bash is many more times more powerful than Gupax, more complex, more options, works better for me, etc. I use it daily, it's the sole way I interact with Monero/P2Pool/XMRig, but I realize it targets a niche group. Gupax is the GUI version with the goal that it's as accessible as possible, while still being powerful.
+
+## Funding
+**Timeframe:** 2 months (8 hours/day, 448 total hours)  
+**Total:** 100 XMR ($14700 USD @ 1XMR/$147)  
+**Rate:** $32.8/hour (14700 / 448)
+
+The GUI is (mostly) already done, but it is still slightly buggy and fonts/sizing/style still need touchups. The internals will take the majority of the 2 months I think this will take to complete. There are two milestones for a total of 100XMR:
+  1. v1.0.0 release + All documentation (80XMR)
+  2. 1 year of maintenance (20XMR)
+
+I'll likely be adding features on my own time afterwards as well (if they are useful to users). There will be documentation on everything, so even without my direct help, it will hopefully be easy for users to use and/or help each other out. I will most likely maintain this project for as long as I'm in this community and there are people using it.
+
+## Questions
+These are some design decisions that I think would be better decided as a community. If you have any opinions on the following, please leave feedback:
+- **Q1. Auto-updater ON or OFF by default?** 
+  - I think having up-to-date software is important but also, I do not like making connections unless users explicitly decide to
+- **Q2. Which nodes should be included as "Trusted community nodes"?**
+  - This is the list of nodes users can select to avoid running their own Monero node. Requirements are: good uptime, trusted by the community, ZMQ enabled. Current list: rino@node.community.rino.io, sethforprivacy@node.sethforprivacy.com, and selsta@selsta1.featherwallet.net 
+- **Q3. Include an installer?**
+  - I'm not familiar with Windows/macOS installers, but if having one would increase adoption, getting some help would be nice
+- **Q4. Support the BSDs?**
+  - I'm not familiar with the BSDs and testing releases on them will take away from development time
+- **Q5. Which license?**
+  - Normally I would have licensed this under MIT however P2Pool and XMRig are under GPLv3. Although I'm not directly using their code, I am planning to include their binaries so I feel it's appropriate to also use GPLv3. I do not mind using GPLv3, but feedback is welcome
+- **Q6. Name/design change?**
+  - Gupax is a stupid acronym for: GUI Uniting P2Pool And XMRig. The ugliness of both the name and logo have grown on me but I'm open to changes

h4sh3d-atomic-swap-implementation.md

+---
+layout: cp
+title: Monero Atomic Swaps implementation funding
+author: h4sh3d et al.
+date: September, 2020
+amount: 2727
+milestones:
+  - name: M1.A.1 User-facing
+    funds: 7% (190.89 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.A.2 Service internals
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.B.1 External specification of swap-lib
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.B.2 Internal specification of swap-lib
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M1.C Specification of chain-syncer
+    funds: 3.25% (88.6275 XMR)
+    done: 31 March 2021
+    status: finished
+  - name: M2.A. Cryptographic libraries
+    funds: 3.375% (92.03625 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.B. swap-lib
+    funds: 11.25% (306.7875 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.C. swap-client
+    funds: 5.625% (153.39375 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.D. swap-daemon
+    funds: 13.5% (368.145 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M2.E. chain-syncers
+    funds: 11.25% (306.7875 XMR)
+    done: 15 December 2021
+    status: finished
+  - name: M3.A.1 xgroup-dleq-lib
+    funds: 8.75% (238.6125 XMR)
+    done: 16 January 2023
+    status: finished
+  - name: M3.A.2 ecdsa-adaptor-sig
+    funds: 8.75% (238.6125 XMR)
+    done: 16 January 2023
+    status: finished
+  - name: M3.B. chain-syncer
+    funds: 5.25% (143.1675 XMR)
+    done: 16 January 2023
+    status: finished
+  - name: M3.C.1 swap-cli
+    funds: 3.5% (95.445 XMR)
+    done: 16 January 2023
+    status: finished
+  - name: M3.C.2 swap-gui
+    funds: 5.25% (143.1675 XMR)
+    done: 16 January 2023
+    status: finished
+  - name: M3.D. swap-daemon
+    funds: 3.5% (95.445 XMR)
+    done: 16 January 2023
+    status: finished
+payouts:
+  - date: 23 April 2021
+    amount: 190.89
+  - date: 25 April 2021
+    amount: 354.51
+  - date: 22 December 2021
+    amount: 1227.15
+  - date: 8 February 2023
+    amount: 954.45
+---
+
+:warning: *DIFFERENT CCS RULES ARE IN PLACE FOR THIS PROPOSAL! PLEASE READ THE FOLLOWING!* :warning:
+
+```
+As a trial, this CCS proposal is going to operate on slightly different rules
+given the unprecedented scope and duration of this proposal. For this proposal
+ONLY, refunds will be issued in the event that the funding is not satisfactory
+or the milestones are not completed. This differs from the standard of excess or
+unused funds going to the general fund.
+
+To qualify for a refund, the donator must send their tx ID, amount, and return
+XMR address to luigi1111@getmonero.org (PGP fingerprint:
+FE6D D72A 19CD C5FC 6CB9  1696 BA18 1389 4EDD 58B9, full PGP key at
+github.com/monero-project/monero/blob/master/utils/gpg_keys/luigi1111.asc) NO
+LATER than ONE WEEK after their donation is made. Any remaining unclaimed funds
+(in the event that the proposal is not completed) will be sent to the general
+fund as usual. If refunds are to be issued, the funds will be returned via the
+provided XMR address.
+
+In summary, the funds can be either:
+
+Unclaimed, leading to the general fund receiving them in the case of a failed
+proposal.
+
+Claimed within one week of the donation, leading to a refund in the case of a
+failed proposal.
+
+Note: The hope is that the refunds will not be needed, and the proposal will get
+funded and completed. In the event of proposal completion, refunds will NOT be
+issued. It is only if the proposal is not completed or funded to satisfaction,
+and ONLY for this proposal.
+```
+
+# Monero Atomic Swap implementation funding
+
+Previous CCS: [Monero Atomic Swaps research funding](https://ccs.getmonero.org/proposals/h4sh3d-atomic-swap-research.html)
+
+Hi everyone,
+
+Three months ago, I posted a CCS for continuing my research on Monero Atomic Swaps. That research is now complete and the results can be found [here](https://www.reddit.com/r/Monero/comments/i1fknt/ccs_results_monero_atomic_swaps_research/). The resulting protocol is implementable today; no more missing crypto! So much so that a PoC was implemented in no time; thank you, kayabaNerve and PlasmaPower! Thus I am reaching out to propose getting a team to work on implementing this protocol, with the end goal of creating a production-ready client/daemon for swapping Bitcoin and Monero. Our design enables to seamlessly extend support for more cryptocurrencies to swap with Monero. It would be very exciting to build that.
+
+You can find the whitepaper that describes the full protocol [here](https://github.com/h4sh3d/xmr-btc-atomic-swap).
+
+A ready-to-use implementation requires a lot of engineering work. Here, my colleagues and I attempt to break down the project into manageable parts, describing the dependencies that have to be fulfilled, and the general roadmap of the project.
+
+## Motivation
+
+Trustless technologies are now emerging, creating the option of refusing to accept counter-party risk. You can make trades with your enemy, as they can't cheat on you. If you don't have to trust, you don't have to know who they are, either.
+
+It is very unlikely that Monero will get banned by all centralized exchanges, but by having an open source atomic swap implementation, such banning mechanism is inefective, as Monero would still be available to anyone who could acquire Bitcoin, which is ubiquitous, and swap the coins online anonymously, trustlessly, with a random peer. Monero will be more robust than ever.
+
+Bitcoin is traceable. This is used to recognize dirty coins, but also for untargeted surveillance and censorship. Bitcoiners, in need of strong privacy, might recognize the utility of a trustless path with low resistance to convert their bitcoin into monero, and become Monero users. 
+
+However, with power comes responsibility, atomic swaps enable users to exchange coins directly with each other. At the same time, if transacted value is significant, honest users MUST carry out their due diligence regarding the origin of the counterparty funds and possibly other anti-money laundering countermeasures, in order to comply with regulations. Trustlessness and no counter-party risk are narrowly defined terms of the atomic-swap literature, that ignores the context whereby the technology is deployed. Bitcoins accumulate dirt in their lifetimes, so swap your monero responsibly, because trustlessly receiving tainted bitcoins is a real counterparty-risk. The counterparties of a swap generate private and blockchain notarized cryptographic proofs of their private agreement, but the court of your jurisdiction might not like that explanation so much. 
+
+The crypto-ecosystem is rapidly moving towards interoperability. Atomic swaps unleash interoperability between Monero and other blockchains. Whether a user needs to open a lighting channel from the monero-bitcoin swap or wants to fund an arbitrary bitcoin contract, the swap protocol exposes the interop socket.
+
+This project will also, as a beneficial side-effect, extend the Monero ecosystem in Rust. Multiple libraries are needed to support the full protocol. Most of them are related to cryptography, for example the "Discrete logarithm equality across groups" algorithm described in the [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note by Sarang Noether (originally proposed by Andrew Poelstra), or directly at the Monero protocol level in the [Monero Rust Library](https://github.com/monero-rs/monero-rs).
+
+Our motivation to build this software is to empower individuals and businesses, who *want* to or *need* to exchange within a strong security and privacy context using P2P, trustless technologies. 
+
+This project has the potential of increasing Monero's liquidity and enabling Monero to get into the hands of more people.
+
+We deem it critical to build this in a manner that fully aligns with the interests of the community. Thus we're reaching out to raise community money, to build this with the community, for the community, enabling the community to preserve its own interests.
+
+### What are we building?
+We aim to build a collection of programs---similar to programs you are familiar with, such as the Monero daemon, wallet CLI, or wallet GUI---that have limited functionality individually but as a collection, serve the functions an end-user requires. One can launch these swap programs to exchange coins with a counterparty. We call those programs: swap clients (CLI or GUI), the swap daemon (like the Monero daemon), and chain-syncers (connected to full nodes). In the default configuration, this will mean opening the swap client and letting it launch and manage all other programs involved.
+
+For example, if you, as an end-user, want to acquire monero and have bitcoin, you'll launch a swap client that connects to a swap daemon, and connects to a counterparty that has monero and is looking to trade them for bitcoin at an agreed upon price. The swap client will give you an address where to move your bitcoin and, at the end of the swap, the swap client will display the monero key-pair to import into your wallet. You now own monero. If at some point the swap is canceled for any reason, your bitcoin will be refunded at the address you chose, making this exchange trustless.
+
+Connecting to a counterparty will require knowledge of their daemon's address, and the amounts traded (i.e. the price and quantity). Creating a platform such as a DEX, allowing people to find each other and "auto" connect with the correct arguments or negotiate the price, is out-of-scope for this project. Industry standards for such interfaces are yet to emerge.
+
+## Overview
+
+R&D Institution: Cryp GmbH
+
+Funding: Monero CCS
+
+Duration: 7 months
+
+Job completion: by Q2 2021
+
+Contributors:
+
+ * h4sh3d
+ * kayabaNerve
+ * lederstrumpf
+ * the charlatan
+ * zkao
+
+Licenses: The license for the code will be decided based on community feedback. Our current preference is LGPL-3.0. The specification will be released under CC-BY-4.0. 
+
+__Expiration date:__
+Funding will remain open until __31.12.2020__. If materially underfunded until __31.12.2020__, we'll either (1) agree with the community to deliver a subset of the deliverables and collect the funds, or (2) discuss how to re-allocate the funds with the community.
+
+## Architecture
+The core project will be built in Rust. Rust's good coverage of cryptographic libraries and blockchain protocols, type safety, and language design makes it a very good candidate for such applications (and the prototype is also written in Rust, for the same reasons).
+
+Here we present an overview of the project's architecture. More details of the individual components will be described in a forthcoming section under [Deliverables](#Libraries-and-Components).
+
+#### The figure represents the general architecture of the swap components and their interactions.
+
+![](https://codimd.s3.shivering-isles.com/demo/uploads/upload_3d490af9aeffe7082babf7087ea404f5.png)
+
+
+#### The following table summarizes different aspects of each component.
+
+|                 | `swap-client`                    | `swap-daemon`                                        | `chain-syncer`     |
+|-----------------|----------------------------------|------------------------------------------------------|--------------------|
+| definition   | a program that controls the daemon and display the current state | a program that executes the core protocol in a state machine | a program that talks with a specific blockchain |
+| cryptographic keys & secrets | private & public    | public only                                          | public only        |
+| client/user  | end-user                         | `swap-client`, counterparty `swap-daemon`                | `swap-daemon`        |
+| availability          | present at the start and to sign | mostly online, channel of communication between parties | always online      |
+| communicates with | `swap-daemon`                      | `swap-client`, `chain-syncer`, counterparty `swap-daemon` | `swap-daemon`, blockchain |
+| transactions    | signs                            | creates all transactions, verifies signatures        | listens for and publishes transactions  |
+| protocol-state  | doesn't understand protocol, but can represent its state              | understands the protocol, but can't sign             | doesn't understand protocol |
+
+
+### Client/daemon segregation rationale
+
+The rationale behind segregating the client and the daemon is not for security reasons at the moment (the client signs the transactions received from the daemon blindly, implying full trust), but for the flexibility and extensibility added.
+
+Other clients can be created: mobile applications (that also run the daemon in background), heavy or light desktop GUIs, or even scripted/automated backends (e.g. in a business environment).
+
+### Future extensibility
+The atomic swap protocol is just the first instantiation of a more generic interface to other systems---we aim to build this construction abstractly enough to allow clean extension [^1] to future protocols.
+
+## Deliverables
+Below is a complete list of our deliverables.
+
+### Specifications
+  * Specification of `swap-lib`:
+Specify the interface and the requirements for adding support for a new chain, for one or both templates (Bitcoin-like and Monero-like).
+  * Specification of `swap-daemon`:
+Specify messages passed between `swap-daemon` and: `swap-client` and `swap-daemon`. These include protocol messages exchanged between swap participants, but also specify the medium of communication of `swap-daemon` and those components.
+  * Specification of `chain-syncer`:
+Specify the functionality and interface `chain-syncer` has to expose in order to permit the `swap-daemon` to carry out swaps. Specify the type of jobs a `chain-syncer` has to implement in order to support executing both templates.
+
+### Libraries and Components
+  * `swap-lib`: includes stateless libraries that implement the core protocol, without runtime, disk, nor network implementation. Knows how to create and verify all the transactions involved in the protocol: it understands and handles the crypto verification, including adaptor signatures and DLEQ proofs across groups, and contains two templates for the pair of exchanging chains (Bitcoin-like and Monero-like). The goal of `swap-lib` is to facilitate integration of the base protocol logic of all pairs of chains that implement the two templates, such that adding a new pair, e.g., Litecoin/Monero, only requires implementing Litecoin for the Bitcoin-like template and an `ltc-chain-syncer` (see below).
+    * `btc-swap-lib`: an implementation for Bitcoin-like template exchanging bitcoin for monero.
+    * `xmr-swap-lib`: an implementation for Monero-like template exchanging monero for bitcoin.
+
+  * `swap-daemon`: implements a daemon, based on `swap-lib`, uses `chain-syncer` as interface to the blockchain world, has the full picture of the state of the cross-chain-swap, as it's aware of the events on both chains and of exchange counterparty protocol messages, it fully understands the protocol, and contains the state machine to execute its respective role in the protocol.
+
+  * `swap-client`: used by the end-user to enter into the protocol, has access to secret keys, uses the `swap-daemon` to execute the protocol, and signs transactions when needed. `swap-client` trusts the daemon completely to execute the protocol on its behalf and to exchange protocol messages with the swap counterparty.
+    * `swap-cli`: end-user CLI client that binds to the daemon for executing swaps and reporting the state of an ongoing swap.
+    * `swap-gui`: minimal end-user GUI client that binds to the daemon for executing swaps and reporting the state of an ongoing swap.
+
+  * `chain-syncer`: connects and synchronizes the protocol universe to the blockchain universe by following its client's commands (`swap-daemon`). `chain-syncer` knows the transactions of interest based on what its client subscribes to and informs the client in case one of its transactions gets reorged away from the main chain. `chain-syncer` must guarantee to be online during the entire execution of the protocol, and carry out actions on behalf of its clients. It has the ability to play a job and respond with events.
+    * `btc-chain-syncer`: a `chain-syncer` connected to a Bitcoin full node, it takes jobs such as listening for transaction confirmation or event-driven transaction broadcast.
+    * `xmr-chain-syncer`: a `chain-syncer` connected to a Monero full node, it takes jobs such as listening for transaction confirmation.
+
+  * `xgroup-dleq-lib`: a cryptographic library implementing the [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note. This library must support at least `secp256k1` and `ed25519` curves. `secp256kfun` will be used at first to speed-up the development and will later be replaced by a fork of `libsecp256k1` and `rust-secp256k1`. `dalek-cryptography` will be used for `ed25519` cryptography.
+
+  * `ecdsa-adaptor-sig`: a cryptographic library implementing ECDSA One-time VES over `secp256k1`. We are looking forward to how ["Add ecdsa_adaptor module"](https://github.com/jonasnick/secp256k1/pull/14) evolves and wait on this to add support in `rust-secp256k1`.
+
+Disclaimer: those cryptographic libraries will require review for being considered as safe-to-use in production.
+
+We're currently in discussions with potential academic collaborators to extend the formal coverage of the protocol and its publication. We're also in the process of publishing a preprint of the swap paper on the Cryptology ePrint Archive.
+
+The code will be released mainly under the `monero-rs` and `swap-rs` Github organisations.
+
+## Dependencies
+
+We describe here a list of cryptographic and protocol dependencies likely needed for achieving a complete implementation (some dependencies are readily available, others will have to be extended or newly developed):
+
+ * Monero library for block parsing and for transaction parsing, manipulation, and verification logic
+ * Bitcoin library for block parsing and for transaction parsing, signing, manipulation and verification logic
+ * RPC and ZMQ libraries for listening to bitcoin and monero nodes; allow reacting and broadcasting transactions depending on the protocol execution
+ * Discrete logarithm equality across `secp256k1` and `ed25519` groups library, as described in [MRL-0010](https://www.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf) technical note
+ * ECDSA One-time VES over `secp256k1` library as described in [One-Time Verifiably Encrypted Signatures A.K.A. Adaptor Signatures](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf), for signing some parts of the bitcoin transactions
+ * ECDSA signing over `secp256k1` library, for signing bitcoin transactions
+
+**Currently available Monero dependencies:**
+  * monero (https://github.com/monero-project/monero)
+  * monero-rs (https://github.com/monero-rs/monero-rs)
+  * monero-rpc-rs (https://github.com/monero-ecosystem/monero-rpc-rs)
+
+**Currently available Bitcoin dependencies:**
+  * bitcoin-core (https://github.com/bitcoin/bitcoin)
+  * rust-bitcoin (https://github.com/rust-bitcoin/rust-bitcoin)
+  * rust-bitcoincore-rpc (https://github.com/rust-bitcoin/rust-bitcoincore-rpc)
+  * libsecp256k1 (https://github.com/bitcoin-core/secp256k1)
+  * rust-secp256k1 (https://github.com/rust-bitcoin/rust-secp256k1)
+  * secp256kfun (https://github.com/LLFourn/secp256kfun); for ECDSA One-time VES over `secp256k1` signing implementation and prototyping DLEQ proofs
+
+**Currently available general dependencies:**
+  * rust-zmq (https://github.com/erickt/rust-zmq)
+  * rust-libp2p (https://github.com/libp2p/rust-libp2p); as an option for daemon peer-to-peer communication
+  * dalek-cryptography (https://github.com/dalek-cryptography); for `ed25519` arithmetic/curve operations
+
+## Milestones
+
+We split the principal milestones (1, 2, and 3) into unordered sub-milestones, each releasing a fraction of the total funds for their principal milestone.
+
+The goal is to share the advance of each individual sub-milestones in biweekly progress reports.
+
+![Milestone structure](https://codimd.s3.shivering-isles.com/demo/uploads/upload_7e18990edf9fa4fbf3ddbe0125e8d105.png)
+
+### Milestone 1 (specs): 20% [6 weeks]
+
+ * **Technical specifications:** a list of specifications that covers all aspects of the protocol, resembling specifications such as BOLT for Lightning network or Cryptonote.
+ 
+The specifications will demarcate which functionality falls in scope of the implementation in Milestone 2, and which functionality will be postponed to Milestone 3.
+ 
+
+#### A. Specification of `swap-daemon`
+Detailed description and specification of the `swap-daemon`, internal and external.
+
+#### A.1 User-facing [35% of M1] [2 weeks]
+* Specify `swap-daemon`'s outer API layer of user interaction (`swap-client`s & counterparty `swap-daemon`) first to guide design of inner dependencies (`swap-lib` & `chain-syncer`) to match desired UX. This includes protocol messages exchanged between swap participants, that is: interactions with the counterparty `swap-daemon`.
+* Specify the API that `swap-cli` and `swap-gui` consume from `swap-daemon`.
+* Specify the networking stack between `swap-daemon` and: `swap-daemon` counterparty and `swap-client`s.
+
+#### A.2 Service internals [16.25% of M1] [1 week]
+Specify links between `swap-daemon` and the other deliverables it requires to facilitate a swap, but that are not user-facing, i.e. `swap-lib` and `chain-syncer`s:
+* Specify the subset of `swap-lib`'s API strictly required for `swap-daemon`'s operation
+* Specify API and network stack for `swap-daemon`'s required calls to `chain-syncer`s
+
+#### B. Specification of `swap-lib` (core protocol)
+Detailed description and specification of all the libraries that, in conjunction, form `swap-lib`, including stateless transaction construction libraries, crypto-libraries and their wrappers, and state-machine libraries for executing the protocol.
+
+#### B.1 External specification of `swap-lib` [16.25% of M1] [1 week]
+* Specify `swap-lib`'s public API to be consumed by `swap-daemon` only.
+Preliminarily, covers `InitTx()`, `VrfyTx()`, `Vrfy()`, and `EncVrfy()` from the whitepaper.
+* Specify `swap-lib`'s public API to be consumed by `swap-client`s only.
+Preliminarily, covers `Sign()`, `EncSign()`, `DecSig()`, `RecKey()`, and `Rec()` from the whitepaper.
+* Specify `swap-lib`'s public API to be consumed by both `swap-daemon` and `swap-client`s.
+
+#### B.2 Internal specification of `swap-lib` [16.25% of M1] [1 week]
+* Specify internal function calls of `swap-lib`.
+* Specify a concrete implementation to support a chain, including all cryptographic primitives that must be supported.
+
+#### C. Specification of `chain-syncer` [16.25% of M1] [1 week]
+* Specify the functionality and interface `chain-syncer` has to expose in order to permit the `swap-daemon` to carry out swaps. Describe what jobs are, and what jobs must be supported.
+* Specify the networking stack between `swap-daemon` and `chain-syncer`s.
+
+A core goal of the spec-writing process is to ensure that the deliverables are compatible and functional in the sum of their parts. This process in Milestone 1 thus aims to identify limitations of the architecture presented in this proposal, which can impact the structure of Milestones 2 and 3. In case changes are consequently required, we will propose them to the community at the completion of Milestone 1, and we will ensure that the same final functionality as set out in this proposal will be delivered.
+
+### Milestone 2 (implementation of core architecture): 45% [14 weeks]
+
+ * **Minimal functionality:** at completion-time of milestone 2, all components for executing atomic swaps successfully are implemented using our libraries as proposed in the presented architecture.
+ * **BETA STATE:** the software released is considered to be beta software and not ready for deployment.
+
+This milestone achieves the initial implementation of all the components (without GUI client) interacting with each other. It implements only the minimally required functionalities specified in the specifications (Milestone 1).
+
+
+#### A. Cryptographic libraries [7.5% of M2] [1 week]
+For milestone 2 we intend to use Lloyd's experimental library for ECSA adaptor signatures (`ecdsa-adaptor-sig`) and DLEQ proofs (`xgroup-dleq-lib`).
+
+We postpone the integration of a production-grade ECDSA adaptor signatures to the end of the project, namely milestone 3, as it is highly complex, and this gives tooling more time to mature. In case Bitcoin incorporates Schnorr signatures soon (BIP 340), ECDSA adaptor signatures may also not be needed and would then be replaced with Schnorr adaptor signatures.
+
+At completion, we provide generic cryptographic libraries that expose a high level API, comparable to how `rust-secp256k1` exposes a high level API for ECDSA signatures over `secp256k1`.
+
+#### A.1 `xgroup-dleq-lib`
+Experimental discrete-log equality across groups library using secp256kfun. At completion, this library enables zk-proving discrete log equality across groups `secp256k1` and `ed25519` for arbitrary private keys.
+
+#### A.2 `ecdsa-adaptor-sig`
+Experimental ecdsa-adaptor signature library using secp256kfun. At completion, this library enables producing and verifying ecdsa-adaptor signatures, and extracting secrets from clear and encrypted signatures.
+
+#### B. `swap-lib` [25% of M2] [4 weeks]
+`swap-lib` is the core for adding support for a new chain, either via the Bitcoin-like template or the Monero-like template. At completion, this library is an interface for enforcing the requirements of `swap-daemon` and `swap-client` for a selected chain, and the requirements for each `chain-syncer` type.
+
+#### B.1 `xmr-swap-lib`
+A concrete implementation of `swap-lib` that allows the creation of a `swap-daemon` and a `swap-client` for exchanging monero for bitcoin.
+
+#### B.2 `btc-swap-lib`
+A concrete implementation of `swap-lib` that allows the creation of a `swap-daemon` and a `swap-client` for exchanging bitcoin for monero.
+
+#### C. `swap-client`s [12.5% of M2] [2 weeks]
+At completion of Milestone 2, we provide only the `swap-cli` client.
+
+#### C.1 `swap-cli`
+A CLI client utilizing `swap-daemon`'s API for executing swaps. At completion, a minimal CLI client for running Bitcoin and Monero swaps will be delivered.
+* `swap-cli` can initialize a `swap-daemon` with parameters for a swap (swap-pair, swap-direction, counterparty daemon address, swap-amount, exchange-rate).
+* `swap-cli` can sign transactions the `swap-daemon` provides.
+* `swap-cli` sends signed transactions back to the `swap-daemon`.
+
+#### D. `swap-daemon` [30% of M2] [4 weeks]
+At completion, `swap-daemon` enables `swap-client` to successfully swap bitcoin for monero. 
+
+It coordinates all aspects of the swap by communicating with `swap-client`, `chain-syncer`s and the counterparty's `swap-daemon`. It exposes an RPC server for client interaction. 
+
+At this stage:
+  - `swap-daemon` understands the semantics of all the public keys, unsigned, signed and partially-signed transactions, hash pre-images, and encrypted signatures involved in the protocol.
+  - has the full picture of the state of the cross-chain-swap, as it's aware of the events on both chains; each `chain-syncer` only has a partial view. `swap-daemon` knows the off-chain events as well.
+  - protocol implemented in 2 varieties: (1) one for executing btc-sender/xmr-receiver protocol (`btc->xmr`) and (2) another for xmr-sender/btc-receiver protocol (`xmr->btc`). In conjunction these 2 protocols cover the full protocol. 
+  - at run-time, each `swap-daemon` instantiates a state-machine of only one of the varieties: either `xmr->btc` or `btc->xmr`.
+  - at run-time, the daemon can start in a master or slave mode. In master mode, `swap-daemon` accepts entering connections, in slave mode `swap-daemon` tries to connect to a counterparty daemon.
+  - reveals a high level API that lets `swap-client`s run the protocol.
+
+#### E. `chain-syncer`s [25% of M2] [3 weeks]
+At completion, `chain-syncer` exposes enough functionality to permit the `swap-daemon` to carry out swaps between Monero and Bitcoin. It does not publish transactions on behalf of its client yet (e.g. `do X once Y`), just listens to transactions of interest and blocks, process them and push events to the `swap-daemon` (i.e. `chain-syncer`'s client). It also exposes functionality for clients to publish transactions to the blockchain, if needed.
+
+All `chain-syncer`s implement the base functionality:
+* interface to `swap-daemon`
+* read transactions (arriving in the mempool, or with a number of confirmations)
+* read new blocks
+* detect block re-orgs
+
+#### E.1 `btc-chain-syncer`
+A bitcoin concrete implementation of the `chain-syncer`.
+In addition to the base functionality, `btc-chain-syncer`:
+* connects to bitcoin full-node
+* broadcasts transactions
+
+#### E.2 `xmr-chain-syncer`
+A monero concrete implementation of the `chain-syncer`.
+In addition to the base functionality, `xmr-chain-syncer`:
+* connects to monero full-node
+
+### Milestone 3 (minimum viable product): 35% [12 weeks]
+
+ * **Full integration of individual components:** the entire functionality as defined in the specs is now implemented.
+ * **MVP STATE:** the software released is considered as stable for a minimum viable product.
+
+At this stage, we replace/finish some components of Milestone 2 with MVP grade components, meaning all features specified in Milestone 1 are implemented.
+
+#### A. Cryptographic libraries
+At completion of this task, cryptographic libraries should benefit from more reviewed and more stable codebases.
+
+#### A.1 `xgroup-dleq-lib` [25% of M3] [3 weeks]
+We upgrade `xgroup-dleq-lib` to use `rust-secp256k1` (fork or mainstream) and dalek. The goal is to implement in C in `libsecp256k1` the high level API needed for cross group discrete logarithm equality proofs with `secp256k1` curve and update `rust-secp256k1` bindings (fork or mainstream).
+
+#### A.2 `ecdsa-adaptor-sig` [25% of M3] [3 weeks]
+We upgrade `ecdsa-adaptor-sig` to use `rust-secp256k1` (fork or mainstream), based of the C implementation in `libsecp256k1` currently in progress [here](https://github.com/jonasnick/secp256k1/pull/14).
+
+#### B. `chain-syncer` [15% of M3] [2 week]
+We upgrade the `chain-syncer`s to enable pattern such as: `do X if Y`. This allows other daemon requirements to be supported, i.e. a daemon can be written such that going offline for a small amount of time is not problematic, allowing e.g. mobile daemons.
+* `swap-daemon` can queue tasks such as `execute refund path at block height X` with a `chain-syncer`.
+
+#### C. `swap-client`s
+We improve `swap-cli` and release a new web-based GUI client, `swap-gui`.
+
+#### C.1 `swap-cli` [10% of M3] [1 week]
+`swap-cli` exposes additional functionality and better UI/UX:
+* during a swap, `swap-daemon` relays to `swap-cli` what actions are currently available to `swap-cli`, and future actions that will become available after `n` blocks.
+* `swap-daemon` pushes updates to `swap-cli`, in lieu of the `swap-cli` pulling from the `swap-daemon`.
+* `swap-cli` can schedule actions to be performed by `chain-syncer`s, as via the upgrade specified in M3.B.
+
+#### C.2 `swap-gui` [15% of M3] [2 weeks]
+A minimal web-based GUI client, `swap-gui`. Cryptographic requirements will be fulfilled with WASM or might be embedded as native libraries on an Electron webapp.
+* `swap-gui` covers the functionality of `swap-cli` as implemented at the end of M2.
+* web-based GUI that interacts with `swap-daemon` API.
+
+#### D. `swap-daemon` [10% of M3] [1 weeks]
+Implements all features defined in the specification for `swap-daemon`.
+
+## Cost
+We ask for 2727 XMR from CCS.
+
+For further information on our crowdfunding, please visit https://cryp.ee/crowdfund or write to us at crowdfund@cryp.ee (PGP fingerprint `A873 CF81 AAFE C016 EC1A  14BB D889 86F7 A3F7 37C4`[^2]).
+
+## Feedback
+Due to the size of this project and the funding required for it, questions, comments, and feedback regarding this request are very welcome.
+
+### Communication channel
+Besides the MR comments on GitLab and the Monero IRC channels such as `#monero-community` and `#monero-research-lab`, we opened the `#monero-swap` IRC channel for crowdfunding questions, project updates, and work management during the development time-frame.
+
+We commit to make ourselves highly available for the community of researchers and developers, such as participating in MRL meetings, sharing progress, incorporating/giving feedback from/to the community in general, and responding to general inquiries, if they fall under our expertise.
+
+[^1]: A plausible extension path towards a generic interface is to initialize the daemon with a Petri net representation of a protocol, together with a set of places that the client is in control of - in lieu of them choosing a role from n-ary options.
+[^2]: Full PGP key for crowdfund@cryp.ee:  
+`-----BEGIN PGP PUBLIC KEY BLOCK-----`  
+`Version: OpenPGP.js v4.10.8`  
+`Comment: https://openpgpjs.org`  
+`xjMEX4G6hRYJKwYBBAHaRw8BAQdAyb5mTWxnbmIqpRExJbZPg6McQK/nTFF0`  
+`kgLd20WRMlbNJWNyb3dkZnVuZEBjcnlwLmVlIDxjcm93ZGZ1bmRAY3J5cC5l`  
+`ZT7CjwQQFgoAIAUCX4G6hQYLCQcIAwIEFQgKAgQWAgEAAhkBAhsDAh4BACEJ`  
+`EF+QaJfwBcaZFiEE55TK0pvlX5ijxFP+X5Bol/AFxpldtgEAlNrZjg5XRDdl`  
+`SmPFZQWvCenIgRXnxe9G4BD529yz5zsA/0/xmq7N19VfpjOecoKl+vyxBBsq`  
+`HiZ6zTNGzeBhr7gEzjgEX4G6hRIKKwYBBAGXVQEFAQEHQL5lk0xlsP59tESA`  
+`h9L8GhCAt5xdOFbYLf7jGyUpjLp3AwEIB8J4BBgWCAAJBQJfgbqFAhsMACEJ`  
+`EF+QaJfwBcaZFiEE55TK0pvlX5ijxFP+X5Bol/AFxpncCwEAm9hTDBjRgOIC`  
+`nZs+2mgmDH0kCAsgwNCLmILfeZ1vbHwBAOwIZgrS74gFKsaeToDoizbF8ecW`  
+`YqxRx7GzcX0NYoUK`  
+`=oDUJ`  
+`-----END PGP PUBLIC KEY BLOCK-----`

h4sh3d-atomic-swap-research.md

+---
+layout: cp
+title: "Monero Atomic Swaps research funding"
+author: h4sh3d
+date: 19 May 2020
+amount: 18
+milestones:
+  - name: Work is done
+    funds: 100% (18 XMR)
+    done: 26 August 2020
+    status: finished
+payouts:
+  - date: 27 August 2020
+    amount: 18
+---
+
+# Monero Atomic Swaps research funding
+
+From [https://github.com/h4sh3d/xmr-btc-atomic-swap](https://github.com/h4sh3d/xmr-btc-atomic-swap):
+
+> In blockchains where hashed timelock contracts are doable atomic swaps are already deployed, but when one blockchain doesn't have this capability it becomes a challenge. This protocol describes how to achieve atomic swaps between Bitcoin and Monero with two transactions per chain without trusting any central authority, servers, nor the other swap participant.
+
+## Motivation:
+
+Two years ago (Dec 2017), I published a draft to swap between Bitcoin and Monero.
+
+In March 2019 I rewrote the protocol in more details, specifying what kind of zero-knowledge proofs were needed to guarantee the "trustlessness" of the protocol and the known limitations of the scheme, funded by my previous employer.
+
+zkao and I presented the protocol at 36C3 in December 2019 ([link here](https://www.youtube.com/watch?v=G-v6hDnzpds)). After discussing it during March and April on #monero-research-lab IRC, andytoshi's idea of using "discrete logarithm equality across groups" that sarang has a write-up [here](https://web.getmonero.org/resources/research-lab/pubs/MRL-0010.pdf), I changed the zero-knowledge requirements by adapting the protocol, but the protocol, thus on-paper complete, was still not implementable as it used an inactive bitcoin op-code: `OP_AND`.
+
+Recently I learned some new cryptographic tricks with ECDSA that should make the protocol complete and implementable with today's tools without requiring hash pre-image zero knowledge proofs.
+
+**This research will update the draft protocol to completely remove hash pre-image zero-knowledge proof requirement.**
+
+So far, I've carried out the latest research on my spare time. I can now use part of my working time to continue. My company has an internal budget for doing research, and because it's my first funding request, it will match the raised funds. Thus I will request 1/2 week of funding from the community, and will spend 1 week working on this project.
+
+## Overview:
+
+R & D Institution: Cryp GmbH (I work and own part of the company)
+
+Funding: Monero CCS
+
+Duration: 40 hours of research (of which 20h paid by community)
+
+Job completion: Within 2 months after successful funding
+
+Contributors:
+
+ * Principal researcher: h4sh3d
+ * Supervisor: zkao
+
+Licences: All work will released under CC-BY-4.0
+
+Expiration date: If not funded or completed until July 31, 2020 funds can be released
+
+## Project Roadmap:
+
+One week of research and writing.
+
+### Deliverable:
+
+ * **Revised version of "Bitcoin--Monero Cross-chain Atomic Swap":** new version with updated cryptographic primitives and protocol variation
+
+## Cost
+
+I ask for the equivalent of 1200 USD from CCS.
+
+Therefore, using a 7-day EMA of 66.21 USD/XMR from Kraken the request total is __18.~~12~~ XMR__.
+
+## Feedback
+
+First CCS, so questions, comments, and feedback regarding this request are very welcome.

hardenedsteel-getmonero-1.md

+---
+layout: cp
+title: Part-time + Flexible Work on getmonero.org (1 Month)
+author: HardenedSteel
+date: 31 July, 2024
+amount: 5
+milestones:
+  - name: Month 1
+    funds: 5 XMR
+    done: 15 September 2024
+    status: finished
+payouts:
+  - date: 27 September 2024
+    amount: 5
+---
+
+
+# Who?
+Hi everyone, I'm HardenedSteel. I've been in Monero ecosystem and contributor for a couple of years. My previous contributions in the Monero ecosystem are:
+
+* Maintenance of getmonero.org[1](https://github.com/monero-project/monero-site/issues?q=involves%3Ahardenedsteel)
+* featherwallet.org[2](https://github.com/feather-wallet/feather-site/issues?q=involves%3Ahardenedsteel)
+* revuo-xmr.com[3](https://github.com/rottenwheel/revuo-weekly/issues?q=involves%3Ahardenedsteel)
+* Helping to newcomers on Reddit[4](https://www.reddit.com/user/HardenedSteelX/), Monero StackExchange[5](https://monero.stackexchange.com/users/12826/hardenedsteel), Monero.Town[6](https://monero.town/u/HardenedSteel) and helping them to onboard Monero ecosystem[7](https://github.com/HardenedSteel/Help4XMR)
+* Translation of Monero.com (and Cake) Wallet[8](https://github.com/cake-tech/cake_wallet/pull/724).
+* and more...
+
+# What?
+I will continue maintaining getmonero.org but with greater level. This will entail reviewing pull requests, fixing issues, adding new content and following social media (such as Reddit and Monero.town) to identify new issues and feature requests for those who do not use GitHub etc.
+
+Furthermore, I will (attempt to) continue contributing to other Monero ecosystems in my spare time.
+
+# Why?
+Many people in Monero community (such as both core and non-core devs and people on social media) complains the website isn't maintained well and there are only a few people working on the site.
+
+# Milestones
+This proposal is only one month since it's my first proposal and requesting 5 XMR for it. Depending on the feedback from the community I'm planning work more than month.
+

hardenedsteel-getmonero-2.md

+---
+layout: cp
+title: Part-time Work on getmonero.org (2 Month)
+author: HardenedSteel
+date: 14 September, 2024
+amount: 10
+milestones:
+  - name: Month 1
+    funds: 5 XMR
+    done: 3 December 2024
+    status: finished
+  - name: Month 2
+    funds: 5 XMR
+    done: 3 December 2024
+    status: finished
+payouts:
+  - date: 13 December 2024
+    amount: 10
+---
+
+# Who?
+Hi again, Its my second proposal I won't copy paste same content to here instead you can reach to my first proposal*.
+
+*https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/481
+
+# What?
+I will continue to maintain getmonero.org and possibly to the docs site (such as migration if it happens) at same pace.
+
+# Milestones
+5 XMR / month. In total 2 months
+
+---
+
+Let me know your concerns or experiences with me or the previous CCS.

haveno-frontend.md

+---
+layout: cp
+title: Haveno frontend development
+author: Haveno
+date: Mar 16, 2022
+amount: 755 XMR
+milestones:
+  - name: Month 0
+    funds: 151 XMR
+    done:
+    status: finished
+  - name: Month 1
+    funds: 151 XMR
+    done:
+    status: finished
+  - name: Month 2
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 151 XMR
+    done:
+    status: unfinished
+  - name: Month 4
+    funds: 151 XMR
+    done:
+    status: unfinished
+payouts:
+  - date: 9 April 2022
+    amount: 151
+  - date: 20 May 2022
+    amount: 151
+---
+
+
+## Proposal closure / Repurposing of funds (3rd Sep, 2024)
+
+- The proposed structure for Haveno is no longer feasible.
+- No progress has been made in 2 years.
+- A developer (kewbit) has stepped forward to work on the project.
+- Due to these reasons, this proposal is deemed void and the remaining 453XMR will be repurposed.
+
+215XMR will be used to fund a [Haveno Multi-Platform Native App For Every OS](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/489) that will meet all the [functional requirements](https://github.com/haveno-dex/haveno-design/blob/master/functional_requirements.md) of a Haveno UI.
+
+The remaining funds will be used for further Haveno front end related work in keeping with the original goals of this proposal (at the communities discretion)
+
+---
+
+Hello again everyone. As promised, after improving Haveno's structure, we come back with a new (much cheaper) CCS proposal.
+
+For a complete picture and all details, [see our initial proposal](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/284), which assumed the old structure with centralized operators.
+
+This is the blog post announcing Haveno's improved structure: https://haveno.exchange/2022/02/02/haveno-structure.html.
+
+## The new structure
+
+For details about Haveno's structure, please read carefully the blog post linked above. For convenience, here is a short summary:
+
+- No more third party entity that will run the exchange. Everything will be managed by non-legal entity for more robustness and decentralization
+
+- All fees paid on Haveno will be sent to 'Engine', a CCS-like structure that will fund Haveno and Monero development. It will work similarly to the CCS managed by the Monero Core Team (MCT), but instead of generous donors, the funds will be provided by the fees sent to Engine by Haveno.
+
+- The funds of Engine will be managed by an entity called 'Engine Council', formed by 5 trusted long term contributors of the dev community, including one member appointed by the Haveno Core Team (HCT) and one member of the MCT[1]. The remaining 3 members will be chosen from a pull of candidates by the Haveno and Monero communities.
+
+- The HCT will request monthly 50% of the funds sent to Engine.
+
+- To avoid liabilities and legal structures, the members of Council will vote anonymously [using ring signatures](https://github.com/monero-project/urs) to ensure plausible deniability.
+
+- Arbitrators will be chosen using Engine and will not be picked by the HCT. This allows to open a market of arbitrators, where Monero and Haveno community members can propose themselves for the role. There will be security mechanisms in place to avoid arbitrators colluding with traders, but that's out of scope for this CCS.
+
+[1] We already contacted the Monero Core Team about this structure and they say they are happy with Haveno's model and are willing to have one of their members join the Engine Council. They point out that this individual should not be interpreted as representing the views of the Core Team directly and if direct MCT input is required, they will discuss internally.
+
+## How much and for what
+
+We are asking for **154k USD in XMR**. The money will be used **entirely to pay for the frontend development of Haveno**. This is the estimated cost to complete the frontend. We are already in contact with a team of three devs, which will start working on Haveno as soon as this CCS is accepted.
+
+The cost is lower than in the past proposal, because the team will develop only the frontend as requested, so extra work (in case of changed or additional requirements) is not included. The HCT will be deeply involved, trying to keep costs as low as possible, but the support of our dev community will be greatly appreciated.
+
+## Milestones and terms
+
+Payments to the frontend team will be every completed sprint. Every sprint will be a task that will take about 2 weeks to complete. For simplicity, we ask the funds to be sent to us every month for 4 months, with the first reward being sent as soon as our proposal is funded. The community will be able to follow the development in the public GitHub repository and on the community channels.
+
+To recap:
+
+- 1st payment: As soon as the proposal is moved to the "In progress" phase.
+- 2nd payment: 1 month after the first payment
+- 3rd payment: 1 month after the second payment
+- 4th payment: 1 month after the third payment
+- 5th payment: 1 month after the 4th payment. Last payment.
+
+The community will be able to follow progresses on Github and on our matrix/irc chatrooms. We hope the development of the frontend will be finished within 4-6 months.
+
+Haveno Core Team  
+[haveno.exchange](https://haveno.exchange)

haveno-multi-platform-native-app-for-every-os.md

+---
+layout: cp
+title: Haveno Multi-Platform Native App for Android, iOS, Windows and Linux.
+author: Kewbit
+date: August 19, 2024
+amount: 215
+milestones:
+  - name: Create the User Interface
+    funds: 75
+    done:
+    status: unfinished
+  - name: Write the Protocol Interface
+    funds: 75
+    done: 13 October 2024
+    status: finished
+  - name: Create the Desktop Connector
+    funds: 15
+    done:
+    status: unfinished
+  - name: Create Multi-Platform Installers for Windows, Linux, Mac, Android and iOS.
+    funds: 50
+    done:
+    status: unfinished
+payouts:
+  - date: 23 October 2024
+    amount: 75
+  - date:
+    amount: 75
+  - date:
+    amount: 15
+  - date:
+    amount: 50
+---
+### Haveno Multi-Platform Native App for Android, iOS, Windows, MacOS and Linux
+
+**Author**: Kewbit  
+**Date**: 19/08/2024
+
+# Proposal termination December 31st, 2024
+
+A contractor presented themselves to the CCS for the sole purpose of creating a Multi-OS Haveno App using a portion of funds from the abandoned Haveno frontend proposal. [1] (of which 378XMR remain)
+
+There has since been a public controversy surrounding this proposal/contractor. [2] [3]    
+
+The CCS itself is devoid of opinion/emotion regarding 'extra curricular' activities. [4]
+
+As per the Community meeting on December 7th [5], the partial payout request was unanimously denied.
+
+During this meeting, Woodser, the lead developer of Haveno suggested [6]:
+> [a] deadline to release the code, in hopes of getting the code for the greater benefit of the project
+
+Whilst the majority voted to close the proposal with immediate effect.
+
+Community trust and sentiment plays a significant role in our Crowdfunding System. For this contractor, it has been **irrevocably and permanently lost**.
+
+On December 10th the contractor was *explicitly informed* [7] to not expect payment outside of milestones 2.
+
+_"Work done as per your proposal is work paid"_: 
+
+* As per the contractors own admission[8] on December 21st via another partial payout request, the work is not done. 
+
+The decision is simple and the contractor is to blame. They:
+* Will not continue working on the proposal until a partial payout is made. (This will not happen again)
+* Demand a decision as soon as possible.    
+
+All deadlines have passed:
+
+* The latest, mentioned by the contractor in their own proposal (*31st December*)
+* The community calling for immediate closure (*December 7th*)
+* One mention of allowing an extra week to complete[9] (*December 14th*).
+
+* Given this, the expert witness review will now focus solely on:
+  1. Validating the legitimacy of the previous Milestone 2 payout (75 XMR)[10].
+  2. Assessing the utility of the existing open source code for future development.
+ 
+If Milestone 2's work meets the proposal requirements and the existing source code is of high quality, despite being incomplete, a new team or contractor can continue the development after a more stringent vetting process if the community wishes to continue this venture.
+
+Should the review expose any shortcomings in the payout review process, these will be addressed moving forward.
+
+[1]: https://ccs.getmonero.org/proposals/haveno-frontend.html
+[2]: https://librejo.monerodevs.org/SyntheticBird/kewbit-drama
+[3]: https://github.com/MAGICGrants/Monero-Fund-Elections/issues/10#issuecomment-2565810794
+[4]: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/334#note_19962
+[5]: https://github.com/monero-project/meta/issues/1120#issuecomment-2525531999
+[6]: https://libera.monerologs.net/monero-community/20241207#c471605
+[7]: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/489#note_27830
+[8]: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/489#note_27825
+[9]: https://libera.monerologs.net/monero-community/20241207#c471632-c471633
+[10]:https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/489#note_26721
+
+---
+
+## Overview
+
+The Haveno Multi-Platform Native App will be an interface for decentralized applications that can connect to the Haveno Daemon, allowing users to conduct transactions in Monero (XMR) using the Haveno decentralized network. Users will be able to buy and sell multiple fiat currencies with their XMR through Haveno. The app will be able through all app stores and installers, or you can build from source.
+
+![Haveno App Montage](https://i.ibb.co/8xvJrPd/Screenshot-20240817-204709-imageonline-co-merged.png "App Montage")
+## Security Considerations
+
+- **Open Source**: All software created will be open-source, and only auditable, open-source libraries will be used. The project will be released under the AGPL 3.0 license upon completion.
+- **Tor Integration**: The app will enforce Tor usage, requiring users to connect via a Tor VPN relay (such as Orbot or InviZible). Without a Tor connection, the app will not proceed past the splash screen.
+- **gRPC Protocol**: The app will connect to Haveno Daemon using the native gRPC HTTP/2 over Tor (not translated from HTTP/1.2 or HTTP/1)
+- **Haveno Integration**: The app seamlessly connect to any Haveno Daemon hosted anywhere (using .onion via Tor)
+- **Censorship Resistance**: By abstracting the VPN relay away from the app itself and requiring Orbot or InviZible, we avoid potential censorship issues. The app will not require VPN-enabled entitlements that need signing, thus preserving its censorship-resistant nature. The app will be available on [F-Droid](https://f-droid.org/en/).
+- **Secure Device Linking**: The app will support secure linking to a running desktop or server instance via a QR code containing a hashed password in the URI of the Onion Link. [Onion Client Authentication](https://support.torproject.org/onionservices/client-auth/) will be available fro advanced users.
+- **Native Libraries**: The app with use native library per OS directly from trusted sources.
+- **Service Segregation**: Each component of the software will run under it's own service on Dekstop versions, you'll be able to manage the services via a System Tray on Windows, Linux and Mac operating systems.
+
+## Features
+
+- Ability to connect to any Haveno network that you want
+- Customize based on your locale
+- Ability to see Haveno network trade offers
+- Start trades, open your own trades
+- Chat with the peer trader
+- Open disputes if a transaction isn't working out and chat with an arbitrator
+- Manage your payment accounts for both crypto & fiat
+- Get notifications when your have new trades or chat messages (local notifications that don't depend on Google's push notification system)
+- Deposit and withdraw from your wallet
+- Beautiful candlestick trading view for Haveno network activity
+- System Tray to manage your Tor & Haveno Daemon services, keep your daemon online without the client open for mobile users.
+- Docker image will be available for advanced users contingent on colaberative efforts between the Haveno DEX team.
+
+## Installers Available As:
+
+- **Linux**: **.AppImage**
+- **Windows**: A windows **.exe** file.
+- **MacOS**: A **.pkg** file or an **.xarchive** file
+- **Android**: A **.apk** or **.aab** file
+- **iOS**: A **.ipa** file or an **.xarchive** file
+
+## Possible Future Plans
+
+- Matrix integration for server-side notifications to the mobile device (this might be nessesary for iOS users to get notifications reliably and timely.)
+- Design the P2P protocol from Haveno in Dart, so that you may not depend on the Haveno Daemon for the app to work (Standalone Mobile App)
+- A redesign of the desktop version of the app to fit the Figma design plan in [haveno-design](https://github.com/haveno-dex/haveno-design/blob/master/haveno_mockups.pdf)
+
+## Purpose
+
+### What the Proposal is About
+
+This proposal aims to bring the Haveno / Monero ecosystem together through Haveno with a user-friendly, multi-platform app that considers security, censorship resistance, and hardware wallet support. I would like to continue adding value to this project so am seeking funds to priorize it beyond the 2 months I scoped out myself.
+
+### Who Will Complete the Proposal
+
+Kewbit (kewbitxmr@protonmail.com)
+
+### Why It Is Important for Monero and the Community
+
+This app is crucial for the Monero community because it promotes a censorship-resistant and decentralised ecosystem. There is great difficulty in finding places to trade XMR due to certain website closures and crackdowns. By intending to make the app available on multiple OS and platforms, including on F-Droid, Play Store, and App Store, we ensure that it reaches a wide audience, including those who prefer non-traditional Android phones using Play Store.
+
+## Milestones and Projected Timeline
+
+- **Create the User Interface**
+  - **Funds**: 75 XMR
+  - **Status**: Started
+
+- **Write the Protocol Interface**
+  - **Funds**: 75 XMR
+  - **Status**: Started
+
+- **Create the Desktop Connector**
+  - **Funds**: 15 XMR
+  - **Status**: Started
+
+- **Create Multi-Platform Installers for Windows, Linux, Mac, Android, and iOS**
+  - **Funds**: 50 XMR
+  - **Status**: Started
+
+## Payouts
+
+- **10/11/2024**: 75 XMR
+- **10/11/2024**: 75 XMR
+- **10/11/2024**: 15 XMR
+- **01/12/2024**: 50 XMR
+
+## Expiration Date
+
+I do not intend for there to be an expiration date. I plan to release the app quickly as I am working on it full-time, even before producing a CCS. I see this as an ongoing project but expect to have a beta absolute latest by 31st December 2024. 
+
+## Alpha Builds
+You can check out the current source and alpha builds.
+
+https://github.com/KewbitXMR/haveno-plus/ (Name of project is subject to change, as is the organisation)
+
+I provider further updates regularly on my blog which you can subscribe to if interested at [Kewbit.org](https://kewbit.org) you can also find [my current public key](https://kewbit.org/public-key/), which I would encourage you to import into your PGP client.
+

hinto-2.md

+---
+layout: cp
+title: hinto-janai full-time work on Cuprate (3 months)
+author: hinto-janai
+date: May 5, 2024
+amount: 264
+milestones:
+  - name: RPC server design
+    funds: 20% (52.8)
+    done: 5 June 2024
+    status: finished
+  - name: JSON RPC interface
+    funds: 40% (105.6)
+    done: 9 August 2024
+    status: finished
+  - name: Binary/other RPC interface + other work
+    funds: 40% (105.6)
+    done: 9 August 2024
+    status: finished
+payouts:
+  - date: 18 June 2024
+    amount: 52.8
+  - date: 12 August 2024
+    amount: 211.2
+---
+
+## What
+[Cuprate](https://github.com/Cuprate/cuprate) is an alternative Monero node implementation, currently worked on by me and [Boog900](https://github.com/boog900).
+
+The next large section that needs work is the RPC server. Another contributor, [yamabiiko](https://github.com/yamabiiko), is also interested in working on the RPC server, although they currently have limited time, so I'll be starting on it alone for now (with much help from Boog900).
+
+## Who
+I'm [hinto-janai](https://github.com/hinto-janai).
+
+Past CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422.
+
+## RPC server
+yamabiiko has started a discussion on the design for the RPC server [here](https://github.com/Cuprate/cuprate/issues/106), and Boog900 has suggested some changes.
+
+The first milestone's time will be spent on:
+- Fleshing out the current proposal or potentially finding better alternatives
+- Preparing an initial design document, similar to [`database/`](https://github.com/Cuprate/cuprate/pull/35)
+
+The current design for the database was spread out across several months, although, the design for the RPC server should take much less time.
+
+After a design is set, the second/third milestone will start on the RPC interface library - the timeline for this is by the end of this CCS. This includes testing, documentation, etc. The current plan is to separate the interface from the inner RPC handler. After the interface is finished, the internal handler(s) will be finished in another CCS (potentially split between contributors).
+
+By the end of this CCS, the initial design document will be polished to reflect the implementation, similar to [here](https://github.com/Cuprate/cuprate/blob/main/database/README.md), and user documentation will also be finished (again, like `database/`).
+
+The resulting design document will be added to [Cuprate's architecture book](#cuprates-architecture-book) (see below).
+
+## Other work
+There's also other work that I believe would be beneficial to start on earlier rather than later.
+
+These will be started on during this CCS:
+
+- Cuprate's architecture book
+- Persistent transaction pool
+- `monero-core` RPC PRs
+- Benchmarking suite
+- Project lints
+
+The persistent transaction pool will be finished within this CCS, the rest will grow alongside the project.
+
+### Cuprate's architecture book
+This is a book similar to [Cuprate's protocol book](https://monero-book.cuprate.org), although it will be for Cuprate's implementation. The RPC design will be documented in this book (along with every other component) as they are implemented. The current [database document](https://github.com/Cuprate/cuprate/blob/main/database/README.md) will be ported to the book as well.
+
+Current rough draft: https://hinto-janai.github.io/cuprate-architecture
+
+Expected included items are:
+- Relational map of components (RPC, DB, block downloader, verifier, etc)
+- Component designs
+- Thread model (when/where/how many threads get spawned? for what purpose?)
+- Resource model (files, sockets, memory usage)
+- Instrumentation (logging, data collection methods)
+- Known inefficiencies/tradeoffs, their reasoning
+
+### Persistent transaction pool
+Considering RPC implementation will take a while, implementing a persistent transaction pool sooner rather than later would be preferred; another option Cuprate has is to create an in-memory only transaction pool, although this would only be a stop-gap and would take more work in the long run, thus this work will be done now.
+
+### `monero-core` RPC PRs
+As I'll be going through all of `monerod`'s RPC methods/objects and [`getmonero.org`](https://www.getmonero.org/resources/developer-guides/daemon-rpc.html) documentation, I will open PRs to `monero-core` or create an issue if I notice any discrepancies.
+
+### Benchmarking suite
+Creating a benchmarking suite for Cuprate's components would allow for collecting and storing information on code execution time. This data can be used later on to detect performance regressions as well as measuring optimizations.
+
+Creating a bespoke benchmarking tool would be a project of its own, so Cuprate is planning to use the [Criterion](https://bheisler.github.io/criterion.rs/book/criterion_rs.html) project.
+
+### Project lints
+Lints cause compiler warnings to become hard errors, blocking compilation. An example: [`serai-dex`](https://github.com/serai-dex/serai/blob/21123590bb600323aa424f64ffaa5d321b1b22ed/Cargo.toml#L135-L184).
+
+Cuprate's CI already fails on warnings (among other pedantic things), although there are many additional lints we could add. Selecting the lints that make sense for Cuprate sets higher code standards for the project. Setting this up and fixing current code should not take too much effort, but it will be drawn out over time.
+
+## Funding
+I am asking for a rate closer to market rates, please read [here](https://gist.github.com/hinto-janai/8ce1d4847f51304aa4d71c3614408d7f).
+
+I am asking for $65 + 0.05 XMR per hour for 480 hours at $130/XMR. This gives 264 XMR.
+
+Recent activity has shown that `monerod` does not handle load well. Furthermore, there is little system-level documentation; changes needed to fix issues like this are more difficult than necessary. I do not believe this has to be repeated.
+
+I believe this is a fair rate for creating well documented and maintainable infrastructure. I am also asking for less hours than before as I don't believe I can continue at my current pace long-term.
\ No newline at end of file

hinto-2023-nov.md

+---
+layout: cp
+title: hinto-janai full-time work on Cuprate (3 months)
+author: hinto-janai
+date: Nov 6, 2023
+amount: 153
+milestones:
+  - name: Internals
+    funds: 33% (51)
+    done: 13 March 2024
+    status: finished
+  - name: API
+    funds: 33% (51)
+    done: 5 May 2024
+    status: finished
+  - name: Integration + 3 months of work
+    funds: 33% (51)
+    done: 5 May 2024
+    status: finished
+payouts:
+  - date: 9 April 2024
+    amount: 51
+  - date: 14 May 2024
+    amount: 102
+---
+
+## What
+[Cuprate](https://github.com/Cuprate/cuprate) is an alternative Monero node implementation, currently solely worked on by [Boog900](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/405).
+
+I've been in contact with Boog and there are many sections within Cuprate that can be worked on in parallel, currently the most pressing section is the database. This work was left unfinished by SyntheticBird45 before they left the project. Boog is currently working on block downloading/verification/consensus with cobbled together database-like functions - this means an actual database layer can be worked on in parallel without any merge conflicts, and can be cleanly slotted in once complete.
+
+This CCS is to support me working on full-time on Cuprate for the next 3 months, specifically on the database implementation.
+
+## Benefitting Monero
+This CCS will fund part of a larger effort to create an alternative Monero node implementation (among other things).
+
+As such, things will initially be slow-going as groundwork is laid. This CCS specifically may not _directly_ benefit `monero-core` immediately, yet it's work that must be completed such that Cuprate _can_ benefit `monero-core` (and Monero) in the future.
+
+## Who
+I'm [hinto-janai](https://github.com/hinto-janai).
+
+Past CCS: https://ccs.getmonero.org/proposals/gupax.html.
+
+## Design
+The design document and active PR is here: https://github.com/Cuprate/cuprate/pull/35 and will be updated as things change.
+
+The main goal is to create a layer that separates the underlying database and the higher-level functions that are called by the other portions of Cuprate, e.g, `get_block()`. The aim here is to allow for easy hot-swapping of databases to test for the various operations Cuprate will be performing. In the end, a single database will be selected after testing, although the layer will continue to exist. 
+
+The database implementations in mind (for now) include:
+- LMDB (via [heed](https://github.com/meilisearch/heed))
+- [sanakirja](https://docs.rs/sanakirja) (a database [similar and originally based off](https://pijul.org/posts/2021-02-06-rethinking-sanakirja) LMDB)
+
+Both of these will be forked and maintained by Cuprate as there are `monerod`-specific things that must be added (e.g output lookup using [sub-keys](https://github.com/monero-project/monero/blob/ac02af92867590ca80b2779a7bbeafa99ff94dcb/src/blockchain_db/lmdb/db_lmdb.cpp#L3447C1-L3449C80)).
+
+The overall design is mostly from Boog900 - I am simply implementing it.
+
+## Future
+There's plenty more work to be done after the database. Boog plans on handling P2P code after his current CCS, which means I could possibly work on these things in the future (in parallel with Boog's work):
+
+- RPC server (e.g. `get_info`)
+- Transaction-pool related (e.g. Dandelion++)
+- Application interface linking everything together (e.g. `./cuprated --option`)
+
+Most likely, the RPC server would be the next thing I would be working on.
+
+And there are things that are planned, but for the very distant future:
+- ZMQ support
+- Tor/i2p support: [Tor is quite feasible today](https://blog.torproject.org/announcing-arti), i2p less so
+- RandomX: Currently, there exists multiple (quite rough) `C/C++ <-> Rust` bindings but as RandomX is in active use (and will most likely be for the foreseeable future) another implementation or more realistically, a maintained "Rust"-like shim on-top would be nice
+- CryptoNight: Same as RandomX but less important as this is only used for legacy purposes
+- P2P encryption (preferably compatible with the proposal for [`monerod`](https://github.com/monero-project/monero/issues/7078))
+
+These points are laid out to showcase what else must/could be done for Cuprate to reach some level of parity with `monerod`.
+
+## Why
+Cuprate has an advantage in that it has an [8+ year old codebase](https://github.com/monero-project/monero) as reference - although we are starting with a blank canvas, we have a finished painting next to us, displaying all the very good, okay, and not-so-good parts.
+
+As such, we can focus on things other than making it work, notably: documentation, maintenance, and correctness.
+
+Other than documenting the [Monero protocol itself](https://monero-book.cuprate.org), we plan to write documentation for internal subsystems such that future Cuprate contributors/maintainers will be able to pick up easily where we left off. What this means for me and this CCS is that I'll be documenting how this database "layer" fits in with the rest of Cuprate, and answer all the "what does this do?", "how does this work?", "why was it done like this?" questions. If I were to continue working on Cuprate past this CCS, i.e. the RPC server, all RPC types would also be documented (and the internals as well) - the same goes for any future subsystems.
+
+Other notable projects following this pattern: [Tor](https://youtu.be/hdFL0kXu440?t=700), [Bitcoin](https://github.com/rust-bitcoin/rust-bitcoin), [Ethereum](https://github.com/rust-ethereum), [Zcash](https://github.com/ZcashFoundation/zebra).
+
+
+## Proposal
+I propose to work for 44 hours/week for 3 months.
+
+By the end of this proposal, Cuprate will have a working database. I believe 3 months is enough time to create and refine an implementation enough for usage.
+
+It is hard to separate large single implementations like this cleanly into goals/timeframes as usually many things get worked on at any given moment - although, there are 3 bigger milestones this CCS has:
+
+1. Internals: implementing the database and functions themselves
+2. API: cleanup of the interface and many other miscellaneous things for external usage
+3. Integration: slotting the database into Cuprate, and at least 3 months of work
+
+Milestone 3 is only to be paid out upon:
+- A complete database has been integrated into Cuprate
+- 3 months of work has been done
+
+This means if the database takes 428~ hours to complete, I will continue to work for 100~ more hours (most likely on the things listed in `Future`) to complete milestone 3.
+
+- Hours: 528
+- Rate: $45 USD/hour
+- XMR: $155 (20-day EMA, Kraken, 2024/01/15)
+- Total: 153 XMR