gupax.md

 ---
-layout: wip
+layout: cp
 title: "Gupax: GUI for P2Pool+XMRig"
 author: hinto
 date: 10 October 2022
@@ -11,13 +11,13 @@ milestones:
     status: finished
   - name: 1 year of maintenance
     funds: 20% (20 XMR)
-    done:
-    status: unfinished
+    done: 28 December 2023
+    status: finished
 payouts:
   - date: 22 December 2022
     amount: 80
-  - date:
-    amount:
+  - date: 9 January 2024
+    amount: 20
 ---
 
 ![banner.png](https://github.com/hinto-janaiyo/gupax/raw/main/images/png/banner.png)

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: wip
+layout: cp
 title: Haveno frontend development
 author: Haveno
 date: Mar 16, 2022
@@ -32,6 +32,20 @@ payouts:
     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.

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

hinto-3.md

+---
+layout: cp
+title: hinto-janai full-time work on Cuprate (3 months)
+author: hinto-janai
+date: August 9, 2024
+amount: 221
+milestones:
+  - name: JSON RPC handlers
+    funds: 40% (88.4)
+    done: 25 December 2024
+    status: finished
+  - name: Binary/other RPC handlers
+    funds: 40% (88.4)
+    done: 25 December 2024
+    status: finished
+  - name: Other work
+    funds: 20% (44.2)
+    done: 4 November 2024
+    status: finished
+payouts:
+  - date: 12 November 2024
+    amount: 44.2
+  - date: 21 January 2024
+    amount: 176.8
+---
+
+## What
+[Cuprate](https://github.com/Cuprate/cuprate) is an alternative Monero node implementation.
+
+The next section that needs work is the RPC handlers. The design, interface, routing, types, and (de)serialization were completed in my previous CCS, see here:
+- Past CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
+- RPC interface tracking issue: https://github.com/Cuprate/cuprate/issues/183
+- RPC book: https://architecture.cuprate.org/rpc/intro.html
+
+This CCS is for the handlers, i.e. the functions that turn requests into responses.
+
+Once the handlers are complete, Cuprate will have a working RPC stack that [mostly](https://architecture.cuprate.org/rpc/differences/intro.html) mirrors `monerod`.
+
+## Who
+I'm [hinto-janai](https://github.com/hinto-janai).
+
+## RPC handlers
+The 1st/2nd milestones are for the RPC handlers. This is the majority of the work.
+
+This includes:
+- JSON RPC handlers (methods behind `/json_rpc`)
+- Binary RPC handlers (binary endpoints, e.g. `/get_blocks.bin`)
+- Other handlers (other JSON endpoints, e.g. `/get_height`)
+
+The RPC handlers will most likely be in its own library/section, built on-top of the RPC libraries Cuprate has so far. The current RPC interface library ([`cuprate-rpc-interface`](https://github.com/Cuprate/cuprate/tree/main/rpc/interface)) allows for custom handlers, as in, the mapping of `request` -> `response` can be customized. The handler created in this CCS will be a standard implementation that (mostly) follows `monerod`'s behavior, i.e. request comes in, get some data from the database and such, return a response. Although, other implementations are possible, such as an RPC handler that caches blocks, as mentioned in [this meeting](https://github.com/monero-project/meta/issues/996#issuecomment-2086710102).
+
+Testing, [crate (library) documentation](https://doc.cuprate.org), and [architecture book](https://architecture.cuprate.org) sections will also be written.
+
+### Binary strings
+There are a few RPC methods that require further discussion before implementation in Cuprate, see the [binary strings proposal](https://github.com/monero-project/monero/issues/9422).
+
+If the above proposal finds consensus on future `monerod` behavior, this CCS will implement that behavior.
+
+If more time is required for the proposal, the related endpoints/methods will be left in a semi-unfinished state until behavior is agreed upon, where after Cuprate will implement that behavior.
+
+If the proposal does not move forward, Cuprate is planning to fallback to implementing `monerod`'s current behavior.
+
+## Other work
+The 3rd milestone is for any miscellaneous work that needs to be done for Cuprate, but also, these 2 concrete things:
+- Lints
+- Benchmarking
+
+I'd like to focus on these as:
+- If they're always pushed to the side, they'll never get done
+- I believe it's important to establish these early on in the project
+
+I started integrating lints & benchmarks into Cuprate last CCS, this CCS will finish integrating them for all the libraries I've written so far, and [other libraries](https://architecture.cuprate.org/appendix/crates.html) if time allows.
+
+The issues tracking the progress of these two can be found here:
+- https://github.com/Cuprate/cuprate/issues/207 (lints)
+- https://github.com/Cuprate/cuprate/issues/208 (benchmarks)
+
+## Funding
+I am asking for $65 + 0.05 XMR per hour for 480 hours at $158/XMR. This gives 221 XMR.

hinto-4.md

+---
+layout: wip
+title: hinto-janai full-time work (3 months)
+author: hinto-janai
+date: February 7, 2025
+amount: 186
+milestones:
+  - name: Month 1
+    funds: 62 XMR
+    done:
+    status: unfinished
+  - name: Month 2
+    funds: 62 XMR
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 62 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+Work full-time for 480 hours on:
+- Cuprate
+  - Alpha release cycle [1](https://github.com/Cuprate/cuprate/issues/371) [2](https://github.com/Cuprate/cuprate/issues/374)
+  - User book [1](https://user.cuprate.org) [2](https://github.com/Cuprate/cuprate/pull/165) [3](https://hinto-janai.github.io/cuprate-user-book)
+  - Project roadmap Q1/Q2 goals [1](https://github.com/Cuprate/cuprate/issues/376) [2](https://github.com/Cuprate/cuprate/pull/369) [3](https://github.com/Cuprate/cuprate/pull/370)
+  - Misc. review work
+- Monero
+  - FCMP++ related review [1](https://github.com/monero-project/monero/pull/9440) [2](https://github.com/monero-project/monero/pull/9436) [3](https://github.com/monero-project/monero/issues/9422#issuecomment-2504037485)
+
+Cuprate is preparing its first alpha release, with a 4-week cycle. A progress report for 2024 is [here](https://www.reddit.com/r/Monero/comments/1ij2sw6/cuprate_2024_progress_report), the roadmap for 2025 is [here](https://github.com/Cuprate/cuprate/issues/376). I will be buying/renting a variety of hardware for testing/development and will post receipts for all hardware acquired at the time of exchange within this CCS.
+
+If developer resources becomes a bottleneck for FCMP++ activation on `monerod`, I will switch priority when/where possible. This was discussed [here](https://github.com/monero-project/meta/issues/1137). Otherwise, I will continue working on Cuprate Q1/Q2 goals noted in the project roadmap, specifically: user book, release cycle, RPC integration [1](https://github.com/Cuprate/cuprate/issues/379).
+
+## Who
+[hinto-janai](https://github.com/hinto-janai)
+
+Previous proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/422
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/484
+
+## Funding
+186 XMR. 
+
+$65 + 0.1 XMR per hour for 480 hours at $225/XMR.

j-berman-3months-full-time-6.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: December 18, 2023
+amount:  211 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (70.3 Monero)
+    done: 23 February 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (70.3 Monero)
+    done: 4 April 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (70.4 Monero)
+    done: 1 May 2024
+    status: finished
+payouts:
+  - date: 4 March 2024
+    amount: 70.3
+  - date: 9 April 2024
+    amount: 70.3
+  - date: 14 May 2024
+    amount: 70.4
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Continuing Seraphis wallet library work.
+  - Complete the async wallet scanner implementation using the Seraphis wallet lib.
+    - When I pointed this async scanner on my local machine to a remote `monerod` instance @selsta spun up, I observed a **~40% speed-up in scanning** over the current wallet2 scanner.
+    - Link to the draft PR that details all remaining TODO's in the PR description: https://github.com/UkoeHB/monero/pull/23
+    - This CCS proposal will not be complete until I complete all major TODO's from the PR linked above, and deliver a final version of the async scanner PR for review.
+  - Once I complete the async scanner, I plan to collaborate further with @jeffro256 @rbrunner7 @dangerousfreedom and the no-wallet-left-behind working group to work on whatever is next highest priority to get the Seraphis wallet lib ready for production.
+- Continue work integrating [full chain membership proofs](https://github.com/kayabaNerve/full-chain-membership-proofs/) into the Seraphis library (and therefore demonstrate how to integrate them into the core Monero repo). The goal is to construct and verify Seraphis transactions using full chain membership proofs, including a suite of unit tests and benchmarks.
+  - In my last CCS, I got an initial setup working to call full chain membership proof code written in Rust from a Monero repo C++ performance test. This was step 1-of-many toward the goal of constructing a full chain membership proof in a transaction using the Seraphis wallet lib.
+- Miscellaneous Monero work, debug issues, review PR's.
+  - Highest on my list right now is to review @vtnerd's p2p encryption implementation (source: https://github.com/monero-project/monero/pull/8996).
+
+## Who
+
+j-berman on github / jberman on matrix
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+211 XMR
+
+480 hours, 0.16 XMR/hr + $48/hr, $172/XMR from coingecko

j-berman-3months-full-time-7.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: May 2, 2024
+amount:  376 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (125.3 Monero)
+    done: 25 May 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (125.3 Monero)
+    done: 10 July 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (125.4 Monero)
+    done: 16 August 2024
+    status: finished
+payouts:
+  - date: 17 June 2024
+    amount: 125.3
+  - date: 17 July 2024
+    amount: 125.3
+  - date: 30 August 2024
+    amount: 125.4
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Integrating [full-chain-membership proofs](https://ccs.getmonero.org/proposals/fcmp++-development.html) into Monero under RingCT.
+  - As part of this CCS, I will submit PR's to the core Monero repository that do the following:
+    - Implements the tree in C++ described in section 6.1 ([paper](https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf), [reference commit](https://github.com/kayabaNerve/fcmp-ringct/blob/221e8c0e155d5fe526080c6e56c6418e0433177d/fcmp%2B%2B.pdf))
+      - Implements the `grow` and `trim` algorithms (sections 6.1.1 and 6.1.2)
+    - Implements tree initialization with existing cryptonote outputs on boot (section 6.2.1)
+    - Implements growing the tree as the node syncs (section 6.2.2 and 6.2.3)
+    - Implements the transaction class containing FCMP's (part of sections 6.3 - 6.6)
+      - I will probably extend `cryptonote::transaction` to do this.
+  - The following tasks from the rest of section 6 are necessary to complete the integration; I'm happy to divide and conquer if someone wants to work on this as well:
+    - Implement transaction construction with FCMP's (sections 6.3 - 6.6)
+      - A pre-requisite for this is implementing the transaction class above.
+    - Implement transaction verification (section 6.7)
+    - Implement RPC route to return a path for outputs (section 6.9)
+    - Implement unifying the distribution of {coinbase, pre-RCT, RCT} outputs and use it to select decoys paths (section 6.10)
+    - Implement changes for multisig (section 6.11)
+- Continuing Seraphis wallet library work.
+  - My next task on this front is to bring the Serpahis lib async scanner into the current wallet API.
+    - To be clear, this is not implementing the Seraphis upgrade; it is bringing the Seraphis wallet **library**, which supports scanning today's blockchain, into the core Monero repository. This would speed up wallet scanning **today**, and is part of an effort to deprecate wallet2 and its technical debt, and replace it with the Seraphis lib ([source](https://github.com/seraphis-migration/wallet3/issues/64#issuecomment-2067030930)).
+    - The async scanner is currently under review ([source](https://github.com/UkoeHB/monero/pull/23))
+    - In the latest round of benchmarks, I observed scanning speed-ups of 50-60% with a clearnet remote node, 40-45% with a tor node, 25-35% with a local node, all running the **current chain** (not Seraphis).
+    - To be usable in the wallet API today, the following still needs to be implemented (I'm also happy to divide and conquer here):
+      - Pre-RCT index handling (needs [source](https://github.com/UkoeHB/monero/pull/23))
+      - A mutable subaddress lookahead ([source](https://github.com/UkoeHB/monero/pull/23#issuecomment-2036086371))
+      - Pool scanning ([source](https://github.com/UkoeHB/monero/issues/41))
+      - A clean way to save tx metadata ([source](https://github.com/UkoeHB/monero/issues/48))
+- Complete p2p SSL review ([source](https://github.com/monero-project/monero/pull/8996)).
+- Misc. review, debugging, etc.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+376 XMR
+
+480 hours, 0.25 XMR/hr + $65/hr, $122/XMR from coingecko
+
+I'm requesting a siginificant raise from my past CCS (0.16 XMR/hr -> 0.25 XMR/hr, $48/hr -> $65/hr) because I believe I have demonstrated improved performance, and believe the recent donations to CCS proposals demonstrate the community is capable of paying strong Monero contributors market / above-market rates. I believe paying market / above-market rates for strong contributors is a stronger strategy for Monero to attract and retain strong talent.

j-berman-3months-full-time-8.md

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: August 26, 2024
+amount:  317 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (105 Monero)
+    done: 14 October 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (106 Monero)
+    done: 11 November 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (106 Monero)
+    done: 12 December 2024
+    status: finished
+payouts:
+  - date: 20 October 2024
+    amount: 105
+  - date: 19 November 2024
+    amount: 106
+  - date: 12 January 2025
+    amount: 106
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Integrating full-chain membership proofs++ into Monero under RingCT.
+  - As part of this CCS, I will prioritize and guarantee completion of the following in this PR: https://github.com/monero-project/monero/pull/9436
+    1. Trim the tree on reorgs and when popping blocks.
+    2. Key image migration.
+    3. Optimize tree building where possible.
+        - Multithreaded output conversion to leaves.
+        - Multithreaded hashing.
+        - Batched inversion.
+    4. Construct fcmp++ transactions.
+        - I anticipate updating `cryptonote::construct_tx_and_get_tx_key` for this, and not touching wallet2 in this proposal.
+        - By the end of this proposal, there will be a modular function wallets can use to construct fcmp++ txs, but I may not have an end-to-end functioning wallet that can construct fcmp++ txs implemented by the end of this proposal.
+    5. Verify fcmp++ transactions.
+    6. Consensus changes for fcmp++.
+        - New unlock time logic.
+        - Allowing new fcmp++ RCT type.
+        - Implement a grace period for current tx types in the pool at the fork to make it into the chain.
+        - Misc. necessary changes.
+  - Work together with @dangerousfreedom on full wallet scanning.
+  - The remaining integration tasks that I would also work on if time permits and someone else doesn't:
+    - Construct fcmp++ transactions in a fully functional wallet.
+      - Pre-requisites: modular function to construct fcmp++ transactions and full wallet scanning.
+    - Implement the RPC route for light wallets to query for paths in the curve trees tree.
+    - Wallet changes for background syncing.
+    - Multisig.
+- Continuing Seraphis wallet library work.
+  - Making it clear up front: I anticipate not making much progress on the Seraphis wallet library work in this CCS. I plan to prioritize fcmp++. If time permits, I would work on bringing the Seraphis wallet library to production.
+  - To be clear, working on the Seraphis wallet library is not implementing the Seraphis upgrade; it is bringing the Seraphis wallet library, which supports scanning today's blockchain, into the core Monero repository. This would speed up wallet scanning today, and is part of an effort to deprecate wallet2 and its technical debt, and replace it with the Seraphis lib ([source](https://github.com/seraphis-migration/wallet3/issues/64#issuecomment-2067030930)).
+  - Next I plan to resolve merge conflicts in the current open PR's, and open all piecemeal PR's to the core Monero release branch to prepare Monero daemons/wallets and reduce the size and scope of the async scanner PR.
+- Misc. review, debugging, etc.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-7.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+317 XMR
+
+480 hours, 0.25 XMR/hr + $65/hr, $158/XMR from coingecko

j-berman-3months-full-time-9.md

+---
+layout: wip
+title: j-berman full-time development (4 months)
+author: j-berman
+date: December 16, 2024
+amount: 360 Monero
+milestones:
+  - name: Month 1
+    funds: 25% (90 Monero)
+    done: 21 January 2025
+    status: finished
+  - name: Month 2
+    funds: 25% (90 Monero)
+    done: 24 February 2025
+    status: finished
+  - name: Month 3
+    funds: 25% (90 Monero)
+    done:
+    status: unfinished
+  - name: Month 4
+    funds: 25% (90 Monero)
+    done:
+    status: unfinished
+payouts:
+  - date: 4 February 2025
+    amount: 90
+  - date: 19 March 2025
+    amount: 90
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+Work full-time 4 months on:
+
+- Work towards a test network that includes Full-Chain Membership Proofs++.
+  - Continue optimizing building the FCMP++ curve tree to improve sync time both in the daemon and wallet.
+  - Construct FCMP++ transactions via the CLI/RPC/GUI.
+  - Verify FCMP++ transactions in the daemon.
+  - Implement all consensus changes needed for FCMP++.
+    - New unlock time logic.
+    - Allowing new FCMP++ RCT type.
+    - Implement a grace period for current tx types in the pool at the fork to make it into the chain.
+    - Misc. necessary changes.
+  - Update the cold wallet <> hot wallet integration and background syncing for FCMP++.
+- Misc. high priority tasks as they arise.
+
+## Who
+
+j-berman on github / jberman on matrix / IRC
+
+My open PR for the WIP FCMP++ integration: https://github.com/monero-project/monero/pull/9436
+
+My branch that includes the wallet sync integration: https://github.com/j-berman/monero/commits/fcmp%2B%2B-tree-sync-dev/
+
+Past CCS's:
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-8.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-7.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-6.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-5.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-4.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-3.html
+- https://ccs.getmonero.org/proposals/j-berman-3months-full-time-2.html
+- https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html
+
+## Proposal
+
+360 XMR
+
+640 hours, 0.25 XMR/hr + $65/hr, $208/XMR from coingecko

jeffro256-full-time-2023Q4.md

+---
+layout: cp
+title: jeffro256 full-time development 2023Q4
+author: jeffro256
+date: Oct 25, 2023
+amount: 147
+milestones:
+  - name: Month 1
+    funds: 33% (47.0)
+    done: 28 December 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (47.0)
+    done: 29 January 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (47.0)
+    done:
+    status: unfinished
+payouts:
+  - date: 6 January 2024
+    amount: 47.8
+  - date: 23 February 2024
+    amount: 46.2
+  - date: 4 March 2024
+    amount: 53
+---
+
+## What
+
+I plan to work full-time to work towards implementing the Jamtis changes discussed by tevador, myself, and others, [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4665372#gistcomment-4665372), [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4692457#gistcomment-4692457), [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4706509#gistcomment-4706509), and [here](https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4708912#gistcomment-4708912). In summary, I will work to implement flexible-sized view tags, light wallet privacy protections, the simplified key derivation structure, and auxiliary enote records, all together. I have already began work on this, which you can see on [this branch](https://github.com/jeffro256/monero/tree/jamtis_lw_take_2).
+
+I also want to begin work on the new wallet after these Jamtis changes are implemented and reviewed. There are many new wallet types enabled by Jamtis, and much thought is needed to be put into the design so that the code stays easily maintainable and robust. I want to spend a lot of time in the design phase for the wallet so we end up in a better scenario than we are in with `wallet2`. 
+
+## Who
+
+I have been contributing to the Monero core repository for [over a year](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [>=69 merged commits](https://github.com/monero-project/monero/graphs/contributors?from=2022-01-25&to=2023-05-30&type=c) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- I [wrote a library](https://github.com/seraphis-migration/monero/pull/4) that is able to load and store into the `wallet2` format without a dependency on `wallet2`. The way it is written allows for very robust conversion, even for hardware wallets, without the hardware being present. It is much more modular than the current `wallet` loading/storing code, and thus should be helpful in the Seraphis migration.
+- I found a solution to some of the privacy problems with Jamtis light wallets and [opened a PR](https://github.com/UkoeHB/monero/pull/15) to fix those issues. I also discussed further changes on the linked Jamtis gist, and will continue to refine Jamtis.
+- I [wrote documentation](https://github.com/monero-project/monero/pull/9024) for Monero decoy selection, as well as an easy-to-read, testable, modular Python script.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so 480 hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at $44/hr, and at a market price of 150 USD/XMR, that makes for a total of 141 XMR.

jeffro256-full-time-2024Q2.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q2
+author: jeffro256
+date: Feb 27, 2024
+amount: 171
+milestones:
+  - name: Month 1
+    funds: 33% (57.0)
+    done: 7 April 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (57.0)
+    done: 12 May 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (57.0)
+    done: 13 June 2024
+    status: finished
+payouts:
+  - date: 9 April 2024
+    amount: 57
+  - date: 18 May 2024
+    amount: 57
+  - date: 18 June 2024
+    amount: 57
+---
+
+## What
+
+I plan to continue work full-time moving towards a Seraphis testnet (and wallet if I have time). These next dev cycles will likely be spent on writing production-ready serialization code, adding support for validating Seraphis transactions to the Cryptonote core, adding database backing support for these transactions, etc (generally weaving the Seraphis library into the core codebase in a way that makes it active). I have already began expanding Seraphis transaction support by beginning work on a transaction class and paired serialization code which will let us capture all possible Monero-compatible transaction forms and handle them in the codebase (expanded on below). 
+
+## Who
+
+I have been contributing to the Monero core repository for [just over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [57 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- Polished [Jamtis changes draft PR](https://github.com/UkoeHB/monero/pull/26) and wrote up changes to the "Implementing Seraphis" paper, which were [approved by @UkoeHB](https://github.com/UkoeHB/Seraphis/pull/6).
+- Began work on creating a [transaction type](https://github.com/jeffro256/monero/tree/monero_tx_variant) that encapsulates all past and Seraphis future transaction forms: cryptonote v1, v2, coinbase, Seraphis squashed, coinbase, with serialization that is backwards compatible. Along this same line, I wrote a [PR](https://github.com/monero-project/monero/pull/9174) that would help the LMDB backend code transition to Seraphis transactions.
+- Wrote a [PR](https://github.com/monero-project/monero/pull/9135) that reduces hard disk usage for nodes.
+- Reviewed @j-berman's [background sync PR](https://github.com/monero-project/monero/pull/8619).
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so `40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521` hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 45 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 136.88 USD/XMR, that makes for a total of 171 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-02-23 to 2024-03-07 (day of writing).

jeffro256-full-time-2024Q3.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q3
+author: jeffro256
+date: June 14, 2024
+amount: 146
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done: 16 July 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (49.0)
+    done: 11 August 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (49.0)
+    done: 14 September 2024
+    status: finished
+payouts:
+  - date: 17 July 2024
+    amount: 48
+  - date: 14 August 2024
+    amount: 49
+  - date: 27 September 2024
+    amount: 49
+---
+
+## What
+
+In the last three months, the likely direction of the future of the Monero protocol changed
+drastically with all the work done to bring FCMPs to RingCT. At my last CCS proposal, I
+proposed that I would be working on the Seraphis wallet and consensus integrations. Then
+I shifted gears to implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#).
+I propose to refine this codebase and produce and LWS-client demo, in order to have these
+set of features complete before the FCMP++ upgrade, assuming all goes well. This codebase
+can currently construct `cryptonote::transaction`s with Jamtis info encode in the `extra` field,
+and then successfully scan that data. Here is a non-exhaustive list of points that need
+work with this library:
+
+- Legacy address integration and testing
+- Optimization: post-primary-view-tag scanning is about 20% slower than expected
+- Testing against actual FCMP++ composition proofs
+- Multi-threaded compute
+- A live, over-the-wire LWS demo for evaluating the filter-assist/hidden enote trade-offs
+
+I would also like to work on replacing `wallet2` internals with the Seraphis library 'legacy handling'
+code, as discussed at this Github issue: https://github.com/seraphis-migration/wallet3/issues/64. A few people
+are already working on it, but it will need a lot of manpower to bring it to fruition.
+
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [68 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Some more notable contributions from this last quarter:
+
+- Implemented [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96#) into the Seraphis library [here](https://github.com/jeffro256/monero/tree/jamtis_rct). This branch provides support for storing Jamtis scanning data into `tx_extra`, and performs a unit test where a pruned transaction is constructed addressed to Jamtis payment proposals, and then successfully scanned for both plain and self-send enote types. The way this branch was written merges the code paths for doing Jamtis on RingCT and Seraphis together. It could use some cleaning up, and the Seraphis multisig tests need to be updated, but otherwise all Seraphis tests are passing.
+- Some other Seraphis stuff including a unified transaction format for Cryptonote, RingCT, and Squashed-Seraphis transactions.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so `40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521` hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 46 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 163.97 USD/XMR, that makes for a total of 146.2 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-06-01 to 2024-06-14 (day of writing), same as last quarter.

jeffro256-full-time-2024Q4.md

+---
+layout: cp
+title: jeffro256 full-time development 2024Q4
+author: jeffro256
+date: September 16, 2024
+amount: 144
+milestones:
+  - name: Month 1
+    funds: 33% (48.0)
+    done: 9 November 2024
+    status: finished
+  - name: Month 2
+    funds: 33% (48.0)
+    done: 12 December 2024
+    status: finished
+  - name: Month 3
+    funds: 33% (48.0)
+    done: 14 January 2025
+    status: finished
+payouts:
+  - date: 12 November 2024
+    amount: 48
+  - date: 12 January 2025
+    amount: 48
+  - date: 23 January 2025
+    amount: 48
+---
+
+## What
+
+The last quarter I began implementing [Jamtis-RCT](https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96), as written by tevador. However, with the FCMP++ integration PR opened against master, and upon discussion of the general health of wallet development in the broader ecosystem, it became readily apparent that the way to move forward is to initially support existing Monero addresses in a way that would be indistinguishable on-chain from Jamtis-RCT, adding full Jamtis-RCT support later. As such, I formulated the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md), which expanded upon the legacy address section in tevador's original Jamtis-RCT proposal. I contacted and conducted meetings with auditors in regards to auditing this spec, which culminated in several proposals. I also implemented transaction scanning code and transaction construction code for Carrot. I would like to continue this work for the next few months ahead of the hardfork. The main things to work on for Carrot at this point are 1) persistent enote stores for both legacy and Carrot scan types together, 2) integration into the main wallet codepaths, 3) hardware device support, and 4) picking and organizing an auditor to move forward with. Ideally, there should also come a point in the near future where the implementation is reviewed against the audited specification. I wish the development of Carrot generally to be swift, in order not to impede the release date of the FCMP++ consensus protocol. It should be noted that if the current addressing protocol is not modified, then users' transactions will *not* be afforded conditional forward secrecy. This would mean that a potential future adversary with the ability to solve the decisional Diffie-Helman problem (e.g. a usable quantum computer) would be able to retroactively reveal the transaction graph without any obfuscation. Carrot, like Jamtis-RCT, leverages the forward secrecy property of FCMP++ while also tackling other issues like the burning bug, Janus attacks, etc. If all goes well, the adoption of Carrot will seamlessly move Monero users into the full realization of the privacy and security that the FCMP++ proving system has to offer. 
+
+To recap, here is a list of things I will attempt to work on this quarter, in rough order of execution:
+
+- Finalize Carrot spec audit
+- Implement Carrot enote store
+- Implement Carrot hardware device support
+- Integrate Carrot into main wallet codepaths
+- Begin soliciting Carrot implementation audit
+
+P.S. To all the generous supporters of my previous proposals, I apologize that the direction of my work has shifted so significantly and so frequently in the past. So many developments have occurred within the last year that it makes my head spin, which in the end will no doubt be a good thing. So while a lot of previous goals have been abandoned, and a lot of previous work put on ice indefinitely, things seem to be finally solidifying towards a forseeable, readily-achieveable outcome in regards to the upcoming hardfork, thanks to many hard-working contributors. Hopefully, all of the work for this quarter will actually see the light of day in the short to medium term. Thanks for your patience. I am very grateful for it.
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [76 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far, with many open PRs. I also began working on the Seraphis migration project, so you can see some of my contributions [here](https://github.com/seraphis-migration/monero/pulls?q=is%3Apr+author%3Ajeffro256) and [here](https://github.com/UkoeHB/monero/pulls?q=is%3Apr+author%3Ajeffro256). Additionally, as I mentioned, last quarter I wrote up the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md) for formal auditing, which will be the main addressing protocol post-FCMP++ if all goes according to plan.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/467
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so `40 (hours/week) * 3 (months) * weeks_per_month = 40 (hours/week) * 3 (months) * (365 / 12 / 7) (weeks/month) = 521` hours total on-paper, though I usually work more than that. The proposal is broken into 3 milestones, one for each month. I am setting my hourly rate at 47 USD/hour (+1 USD/hour higher than last quarter), and at a market price of 170.37 USD/XMR, that makes for a total of 143.7 XMR. Price was calculated as 14-day simple average of opening prices on [CoinGecko](https://www.coingecko.com/en/coins/monero/historical_data) from 2024-09-04 to 2024-09-17 (day of writing), same as last quarter.
+

jeffro256-full-time-2025Q1.md

+---
+layout: wip
+title: jeffro256 full-time development 2025Q1
+author: jeffro256
+date: January 27, 2025
+amount: 114
+milestones:
+  - name: Month 1
+    funds: 33% (38.0)
+    done: 18 February 2025
+    status: finished
+  - name: Month 2
+    funds: 33% (38.0)
+    done:
+    status: unfinished
+  - name: Month 3
+    funds: 33% (38.0)
+    done:
+    status: unfinished
+payouts:
+  - date: 24 February 2025
+    amount: 38
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## What
+
+The last quarter I implemented the core cryptography for [Carrot](https://github.com/jeffro256/carrot/blob/master/carrot.md). I will note that preliminary performance tests put Carrot scanning at about 30% faster on CPU usage versus scanning today, mostly thanks to the use of the X25519 ECDH library [mx25519](https:://github.com/tevador/mx25519). I also implemented pruned `cryptonote::transaction` [construction and scanning](https://github.com/monero-project/monero/pull/9697) for Carrot. The FCMP++ integration and Carrot integration are finally meeting ends and are almost ready for hot path integration. This next quarter, I want to continue this work to get a testnet out ASAP.
+
+To recap, here is a list of things I will attempt to work on this quarter, in rough order of execution:
+
+- Integrate Carrot scanning/transaction construction into main wallet codepaths
+- Provide support to existing hardware wallet manufacturors on how to securely support Carrot outputs
+- Use benchmarkings and static analysis to inform MRL decisions on transaction weight discussions etc
+- Begin soliciting Carrot core implementation audits
+- Provide Rust implementation of Carrot for Serai/Cuprate
+- Solicit help for multisig implementations of Carrot
+- Help out with the FCMP++ integration wherever I can
+
+## Who
+
+I have been contributing to the Monero core repository for [over two years](https://github.com/monero-project/monero/pulls?page=2&q=is%3Apr+author%3Ajeffro256) with a total of [84 merged commits to master](https://github.com/monero-project/monero/commits?author=jeffro256) thus far, with many open PRs. Over the last few months, I wrote up the [Carrot specification](https://github.com/jeffro256/carrot/blob/master/carrot.md), organized []auditing](https://github.com/cypherstack/carrot-audit), for which the  community graciously funded, and [began](https://github.com/monero-project/monero/pull/9559) [implementing](https://github.com/monero-project/monero/pull/9697) it. Carrot will be the main supported addressing protocol post-FCMP++ if all goes according to plan. I also worked on the Seraphis migration project in 2023/2024.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/390
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/421
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/436
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/467
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/504
+
+## Payment
+
+I propose to work for 3 months at a rate of 38 XMR per month.
+

kayabaNerve-fcmp-retroactive.md

+---
+layout: cp
+title: Retroactive funding for work on full-chain membership proofs
+author: Luke Parker (kayabaNerve)
+date: July 24, 2023
+amount: 310 XMR
+milestones:
+  - name: Implementation of Bulletproofs+
+    funds: 150 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Implementation of Curve Trees
+    funds: 100 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Application of elliptic curve divisors for multiple times faster proofs
+    funds: 50 XMR
+    done: 23 June 2023
+    status: finished
+  - name: Implementation of COPZ's efficient cross-group discrete log equality proof
+    funds: 10 XMR
+    done: 23 June 2023
+    status: finished
+payouts:
+  - date: 21 March 2024
+    amount: 310
+---
+
+Prior to Monerokon, I spent a month and a half working on full chain membership proofs for Monero. This is the product of
+
+- Discussions from https://github.com/monero-project/research-lab/issues/100
+- Curve trees, as the fundamental idea https://eprint.iacr.org/2022/756
+- Eagen's application of Elliptic Curve divisors https://eprint.iacr.org/2022/596
+- COPZ's discrete log equality proof, letting us move to a curve cycle https://eprint.iacr.org/2022/1593
+
+Having finished the work, which was considerable, I would like to fundraise for retroactive funding given the expenses occurred to me. Not only did I put off my own work for the significant amount of time spent on this, I made the decision to bring j-berman in at a rate we had prior established for their work on my own project.
+
+To explain the work, it's an implementation of a membership proof _compatible with Seraphis_ which is efficient enough to feasibly support up to 777 million outputs. For more than 777 million outputs, proof time would increase ~50%, yet the chain would continue.
+
+While this work isn't complete, it has asserted its existence as a viable path to proceed down.
+
+# What Has Been Done
+
+- An implementation of Bulletproofs+, designed to be clearly understandable and efficient.
+
+A new implementation was written despite Monero already having a deployed implementation. This was due to Monero's implementation only supporting aggregate range proofs and being so tailored for them, it being infeasible to expand to include support for arithmetic circuits (the proof Curve Trees uses).
+
+It is not yet ready for production for a few reasons.
+
+1) It panics on invalid inputs, instead of returning errors.
+2) It hasn't been externally reviewed/audited.
+3) A design criteria to support curve trees is a vector commitment scheme (VCS). Bulletproofs+ does not support vector commitments, and I had to shim in my own scheme to compensate which is not viable for production.
+
+This will be discussed below.
+
+- An implementation of Curve Trees, or at least, the idea of Curve Trees.
+
+Curve Trees describes a n-ary Merkle Tree where the hash function is a Pedersen hash. Since a Pedersen hash hashes from scalars to a group element, and the variables in an arithmetic circuit are scalars, Curve Trees uses a pair of Bulletproofs over a curve cycle, each layer of the tree represented by the complimentary proof. This ensures the output of the hash is always a native variable. My implementation is similar, yet instead of using the scalar multiplication algorithm provided in its paper, Eagen's application of Elliptic Curve divisors is used. This is multiple times more performant.
+
+Additionally, my work was done over Bulletproofs+, not Bulletproofs, for minor efficiency gains. Post-deciding which arithmetic circuit proof to use, it was learned Curve Trees requires a VCS. Bulletproofs+ does not have a VCS posited, while Bulletproofs has one posited yet not proven. While work could be done to prove the VCS posited for BPs instead of developing a new scheme for BPs+, this would be detrimental in the long term.
+
+To explain why, BPs defines a "inner-product" argument. BPs+, "weighted inner-product". BPs++, "norm". BPs++ argues its "norm" argument can be equivalent to BPs+'s "weighted inner-product", implying future development of a VCS around BPs++ would be best done from a VCS around BPs+. Since it is a goal to move to BPs++ for efficiency, not just for arithmetic circuits (this work) yet also Monero's range proofs (which BPs++ already has funding to be reviewed for), this was kept in mind.
+
+As part of my work, I reached out to Firo, with researcher Aram Jivanyan and contracting researcher Aaron Feickert (sarangnoether) from Cypher Stack. I requested their collaboration in this effort, with current discussions being around them working on developing and proving a VCS. While no guarantees have been made, the answer to if a scheme for BPs+'s WIP argument is possible was estimated to be on the scale of weeks, not months. Accordingly, I'd personally evaluate it within timelines _and long-term fruitful_ to continue with BPs+ and not revert to BPs. If a BPs+ VCS is infeasible, then the work falls back to proving the VCS posited for BPs, which has passed first glances.
+
+- An implementation of Elliptic Curve divisor calculation and checks
+
+Elliptic curve divisors can be used to offer proof-of-knowledge of discrete logarithms which are several times more efficient than in-circuit elliptic curve additions. I implemented the calculation of divisors, checks for them (in and out of circuit), achieving a roughly 3x reduction in DLog PoK circuit size than the Curve Trees DLog PoK circuit. This circuit is most of the overall circuit, and circuit size does directly relate to proof verification time.
+
+- An implementation of COPZ's discrete logarithm equality proof
+
+Since Curve Trees effectively requires a curve cycle, Monero would have to move to one. This proof lets Monero move to a curve cycle at a marginal cost (a one-time 160-byte proof per-output).
+
+# What's Next
+
+A series of tasks can be defined.
+
+1) Proving and implementing a proper VCS scheme
+
+This is currently in progress, and doesn't actively require the Monero project. In the future, it may require our involvement, and if so, we can discuss it then.
+
+2) Proving/formally verifying Curve Trees
+
+I agree more certainty behind Curve Trees is needed. I do not believe we should halt development efforts until we are fully certain, given the amount of evidence before us and alternative paths ahead of us for any road blocks we may face. Already happening is the development of a VCS scheme, with proofs. Once that happens, letting us formally define our Curve Trees instantiation, we can continue obtaining certainty. All of this can be done in parallel to this work's completion.
+
+3) Polishing the above work
+
+This will be tackled by future CCSs. I am planning one, and j-berman has already submitted a CCS which part of is experimentally integrating Curve Trees into Monero (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/401). I have also discussed with multiple developers in the ecosystem getting their involvement.
+
+To be perfectly clear, in no uncertain terms, this CCS does not provide funding for nor guarantee any continued development. It is solely a representation of gratitude and acknowledgement for work already performed, and organization provided.
+
+4) Auditing
+
+Auditing can only occur once the academia, and the code, is completed.
+
+5) The Monero project deciding whether or not to move to a curve cycle
+
+I cannot truly comment here as I do not speak for the Monero community.
+
+My personal thoughts on moving to a curve cycle can be found here: https://gist.github.com/kayabaNerve/97441ad851dc6e4d2a0b699f58a004f2
+
+Relevant MRL issues are https://github.com/monero-project/research-lab/issues/100 and https://github.com/monero-project/research-lab/issues/110.
+
+While this isn't the place to decide if a curve cycle is necessary, or if one will be adopted, it is important to note a curve cycle isn't technically required. It's optimal, and somewhat expected, yet we can hash Ed25519 points into a cycle (at additional cost). Accordingly, this work is relevant even if we don't move to a curve cycle.
+
+6) The Monero project deciding whether or not to integrate this work
+
+In order for the community to decide if this work should be integrated, it must be evaluated. Evaluation requires this work being viable for integration, which won't happen until it's complete. For now, I restate
+
+> While this work isn't complete, it has asserted its existence as a viable path to proceed down.
+
+And accordingly justify not only its historical funding, yet future funding.
+
+# Why Historical Funding
+
+The CCS has a distaste for historical/retroactive funding, which I understand. Personally, I do not accept payment for a job until it is done. While the milestone system offers that, I still must promise and obligate myself to doing the work by the fact I created a CCS and succesfully raised funds. I do not appreciate those obligations when I was unsure of my capabilities to produce not just a membership proof, yet a membership proof viable to continue with which was worth fundraising for. Before I wrote an implementation of BPs+, designed a higher-level arithmetic circuit framework, learned enough math to implement Elliptic Curve divisors, engaged with multiple other parties, and implemented Curve Trees, I was unsure this would become meaningful to Monero. It was on a scale I had never worked with before, and far too much work to ever be certain about before it is done and actual metrics can be assigned. Accordingly, I would never have felt comfortable with funding beforehand.
+
+I also wished to avoid debate about the legitimacy of atttempting this work. This work, as currently implemented, with its current performance, commentary, and understandings, establishes itself as viable. Before it existed, it could not establish itself as viable. By waiting, I removed discussions about if it would be viable by now providing a proof it is.
+
+While this work was done with limited visibility, I did contact parties as soon as they became relevant. Prior mentioned was a collaboration with Firo, yet I also reached out to Liam Eagen (author of BPs++ and a proof applying Elliptic Curve divisors), narodnik, and j-berman as beneficial.
+
+# Funds Breakdown
+
+The amount quoted is roughly 50,000 USD. Given the amount of work produced, and time spent, I believe this to be fair.
+
+This is inclusive of my obligation to j-berman ($3,600) who:
+
+- Reduced the multiplications performed, savings tens of percent off verification time
+- Investigated a new algorithm for further reducing multiplicatios, which would also be applicable to Monero's current BP+ implementation
+
+And my desire to thank Eagen for their contributions with $5,000. Eagen's application of divisors drastically increased the performance of this work. Also notable is narodnik who provided an initial Python reference for divisor construction and evaluation, yet they have declined to be so thanked.
+
+With all of this in mind, and given the extended hours I generally work, my hourly rate would be roughly 100 USD.
+
+# Resolution
+
+If this proposal is not funded within two months, it will be closed regardless of status. All raised funds will be directed towards the already completed milestones, even if only partially funded. Whatever amount raised will close this CCS, and be considered as complete funding for these milestones.

maintaining-flatpak-package.md

@@ -11,23 +11,23 @@ milestones:
     status: unfinished
   - name: 3 month maintenance
     funds: 1.63
-    done:
-    status: unfinished
+    done: 2 April 2024
+    status: finished
   - name: 3 month maintenance
     funds: 1.63
-    done:
-    status: unfinished
+    done: 2 April 2024
+    status: finished
   - name: 3 month maintenance
     funds: 1.63
-    done:
-    status: unfinished
+    done: 2 April 2024
+    status: finished
   - name: 3 month maintenance
     funds: 1.63
-    done:
-    status: unfinished
+    done: 2 April 2024
+    status: finished
 payouts:
-  - date:
-    amount: 
+  - date: 9 April 2024
+    amount:  6.52
   - date:
     amount: 
   - date: