h4sh3d-atomic-swap-implementation.md

 ---
-layout: wip
+layout: cp
 title: Monero Atomic Swaps implementation funding
 author: h4sh3d et al.
 date: September, 2020
@@ -47,28 +47,28 @@ milestones:
     status: finished
   - name: M3.A.1 xgroup-dleq-lib
     funds: 8.75% (238.6125 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
   - name: M3.A.2 ecdsa-adaptor-sig
     funds: 8.75% (238.6125 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
   - name: M3.B. chain-syncer
     funds: 5.25% (143.1675 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
   - name: M3.C.1 swap-cli
     funds: 3.5% (95.445 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
   - name: M3.C.2 swap-gui
     funds: 5.25% (143.1675 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
   - name: M3.D. swap-daemon
     funds: 3.5% (95.445 XMR)
-    done:
-    status: unfinished
+    done: 16 January 2023
+    status: finished
 payouts:
   - date: 23 April 2021
     amount: 190.89
@@ -76,32 +76,8 @@ payouts:
     amount: 354.51
   - date: 22 December 2021
     amount: 1227.15
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
-  - date:
-    amount:
+  - date: 8 February 2023
+    amount: 954.45
 ---
 
 :warning: *DIFFERENT CCS RULES ARE IN PLACE FOR THIS PROPOSAL! PLEASE READ THE FOLLOWING!* :warning:

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

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-3-months-full-time.md

 ---
-layout: wip
+layout: cp
 title: j-berman full-time development (3 months)
 author: j-berman
 date: August 30, 2021
@@ -15,15 +15,15 @@ milestones:
     status: finished
   - name: Month 3
     funds: 33% (26 Monero)
-    done:
-    status: unfinished
+    done: 4 February 2022
+    status: finished
 payouts:
   - date: 6 October 2021
     amount: 26
   - date: 10 November 2021
     amount: 26
-  - date:
-    amount:
+  - date: 8 February 2022
+    amount: 26
 ---
 
 ## What

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

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: February 7, 2022
+amount: 135
+milestones:
+  - name: Month 1
+    funds: 33% (45 Monero)
+    done: 14 March 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (45 Monero)
+    done: 13 April 2022
+    status: finished
+  - name: Month 3
+    funds: 33% (45 Monero)
+    done: 23 June 2022
+    status: finished
+payouts:
+  - date: 29 July 2022
+    amount: 135
+---
+
+Hi all, I love my new job and very much so hope that my performance has been satisfactory. I'm requesting 135 XMR to continue working on Monero full-time for the next 3 months (2/7/22 - 5/2/22).
+
+On my immediate radar, I'd like to help ensure the upcoming fork goes smoothly. I can take on the following:
+
+- help the ecosystem prepare for view tags:
+	- [monero-lws](https://github.com/vtnerd/monero-lws)
+	- [openmonero](https://github.com/moneroexamples/openmonero)
+	- potentially others if needed
+- help resolve merge conflicts between PR's
+- bump the ring size from 11 to 16 (tiny bit more effort than changing a single constant) (edit: PR for this [here](https://github.com/monero-project/monero/pull/8178))
+- whatever else I have the skills to help on
+
+Beyond the fork, here are some concrete tasks I'd also like to work on:
+
+### [Background wallet sync cache](https://github.com/monero-project/monero/issues/8082)
+
+This is a great idea by @hyc for wallets to continuously scan for a user's transactions in the background. This should make scanning a more pleasurable experience on mobile. The key idea behind the proposal is keeping the view key "hot" on the device, but *not* the spend key. This way wallets can more safely do this background scanning without leaving a spend key exposed.
+
+### Subaddresses in [`monero-lws`](https://github.com/vtnerd/monero-lws)
+
+I proposed a way to implement subaddresses in light wallet servers in [this PR](https://github.com/monero-project/meta/pull/647). I'd like to see this through to completion. To me, completion == there is a well-tested client-server implementation (with tests), where a frontend can interact with your own running `monero-lws` server. Been in communication with various light wallet ecosystem folks to move forward to flesh out the details of the API spec (shoutout to @endogenic, @vtnerd, and @ndorf for their involvement) :)
+
+### Complete monero-lws informal audit if there is demand
+
+If there is demand, I'm happy to complete [this review of monero-lws](https://github.com/vtnerd/monero-lws/pull/29) I started as part of my prior CCS. To be clear, I've read through the whole code base, and stand firm behind my conclusion that it is great software with no obvious backdoors. There are a number of files I left as "TO-DO's" in the review since it was taking up a lot more time than anticipated. Happy to fill it out if people would like.
+
+### Other tasks
+
+I have a running list of stuff I'd like to get to (some rolled over from last CCS):
+
+- complete [these issues](https://github.com/vtnerd/monero-lws/issues/created_by/j-berman) as needed in monero-lws + work through the suggestions shared in [my review](https://github.com/vtnerd/monero-lws/blob/16f1ceaa6a5eb4d9263863068bf57bc8e032a408/docs/review_02.03.22/review_02.03.22.md#suggestions)
+- continue investigating ways to make wallet scanning faster
+- pick up on research into [deterministic binning](https://github.com/monero-project/research-lab/issues/84)
+- [thread safety in the daemon RPC](https://github.com/monero-project/monero/pull/7936)
+- implement a rw lock for the Blockchain class
+- encrypt the wallet cache
+
+## Who
+
+j-berman on github, jberman on Matrix/IRC, and here is my [last CCS](https://ccs.getmonero.org/proposals/j-berman-3-months-full-time.html).
+
+Merged commits: [monero-project/monero](https://github.com/monero-project/monero/pulls?q=is%3Apr+author%3Aj-berman+is%3Aclosed), [openmonero](https://github.com/moneroexamples/openmonero/pulls?q=is%3Apr+author%3Aj-berman)
+
+Open commits: [monero-project](https://github.com/monero-project/monero/pulls/j-berman)
+
+## Proposal
+
+Requesting 135 XMR, which is a 25% raise from last CCS proposal from (0.08 XMR + $24)/hr to (0.1 XMR + $30)/hr, for 480 hours (12 weeks), at $168 / XMR from coingecko. This hourly rate totals to 133.8 XMR for the period (0.1 XMR + $30/$168 XMR = 0.279 XMR/hr * 480 hrs = ~133.8 XMR), which divides into 3 payments of 44.6 XMR. I rounded 44.6 XMR up to 45 XMR to land on a total of 135 XMR (3 * 45 = 135 XMR).
+
+My prior CCS, I ended up working about a month longer than expected without submitting another CCS, since I wanted to see things through to completion as best I could, and prioritize must-do work before spending time wrapping up the prior CCS, and writing this proposal. I'd like to have more flexibility and comfort in making a decision like that, which I feel a higher rate affords.
+
+I will share monthly updates, and will keep track of my hours as before, but likely won't be submitting an hourly time tracking spreadsheet with each update (it feels a little invasive and no one seems to care about it anyway, I probably shouldn't have done it in the first place). I'll also continue attending every #monero-research-lab + #monero-dev meeting I can, and sharing what I work on there when applicable.
+
+Final note: if I run into any bounties that I want to work on in the future (like [view tags](https://bounties.monero.social/posts/28/implement-view-tags-to-decrease-wallet-sync-times-in-monero)), I'd like to work on them as part of my CCS, and pay the bounty out to PR reviewers (and in some cases, to original idea-havers too). I'd like to have flexibility to make decisions on what I think would be most valuable for me to work on, but will always welcome feedback :)

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

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: July 18, 2022
+amount: 187.5 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (62.5 Monero)
+    done: 14 September 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (62.5 Monero)
+    done: 28 October 2022
+    status: finished
+  - name: Month 3
+    funds: 33% (62.5 Monero)
+    done: 28 October 2022
+    status: finished
+payouts:
+  - date: 4 November 2022
+    amount: 187.5
+---
+
+## What
+
+I'd like to continue full-time another 3 months in a similar capacity:
+
+- Continue with PR review (especially on larger time-intensive PR's), including wrapping up [8076](https://github.com/monero-project/monero/pull/8076) (reduce wallet load and refresh time).
+- Patch bugs.
+- Finish the background sync mode that enables scanning for txs without a spend key. My code is [here](https://github.com/j-berman/monero/commit/238ea538f218ad447808c6806386a73bb1ab0fd5) and is functional as is. I approached it cautiously and thoughtfully to ensure it's safe as I went along. I still have some final touches on it + tests to add to wrap it up, [described here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/285#note_15356).
+- Potential tasks:
+	- Start going deeply through Seraphis code, implementing Jamtis features, and working toward completing a handoff from UkoeHB -> core repo. [From @UkoeHB](https://libera.monerologs.net/monero-research-lab/20220713#c120001): "Todos after [he finishes his final poc tasks]: investigate/implement the wallet-side features of Jamtis (RIDs, Polyseed, address authentication), build wallets that use the seraphis library interface for building/handling txs and enotes (full wallet, view-only wallet, multisig full wallet, payment validator), integrate seraphis into the daemon/ledger, ...".
+		- My own opinion on the state of Seraphis/Jamtis: both should undergo deeper review and round(s) of audits from independent parties and earn "rough consensus" before ultimately deployed. It would also be nice to see research into trustless zk-SNARKs move further along to have a better idea of how they could fit alongside Seraphis/Jamtis. Still, I think it would be valuable to start getting more finalized audit-able code prepared, especially code that likely wouldn't be impacted by the latter (such as RIDs, Polyseed, and address authentication).
+	- Work together with @endogenic on factoring wallet2.
+	- Implement subaddresses in `monero-lws` as per [this spec](https://github.com/monero-project/meta/pull/647). At this point, moving this forward feels dependent on others in the light wallet ecosystem and isn't fully in my hands (unless enough people want subaddress support in the server and don't need a client).
+- Whatever seems highest priority to work on to me that I know can add value on that comes along. As of this moment, [PR 7999](https://github.com/monero-project/monero/pull/7999) (a serialization overhaul) is a leading candidate; however, with 7999, there is a chance I'm unable to provide an adequately deep review that the PR requires as my skill level may not be at that point yet. If I do decide to work on 7999, I wouldn't count my hours toward my CCS unless those hours lead to demonstrable value that pushes what the PR aims to solve forward.
+
+## Who
+
+I've identified and patched several privacy issues with varying severity in the Monero ecosystem:
+
+1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. ([source](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. ([source](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+3. `openmonero` was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. ([source](https://github.com/moneroexamples/openmonero/pull/177))
+4. MyMonero doesn't use the updated CLSAG fee calculation which fingerprints MyMonero txs on chain by tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/35))
+5. MyMonero's fee calculation->input selection logic differs ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/36))
+6. `monero-lws` fee masking on the server also caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to `monero-lws` (a fingerprint that is distinct from MyMonero). ([source](https://github.com/vtnerd/monero-lws/pull/31))
+7. In PR review on the upcoming hard fork's changes to the tx fee, identified the introduction of [slightly different fee calculation logic](https://github.com/monero-project/monero/pull/7819#discussion_r804404285) that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.
+
+Most of the above took a significant amount of time to investigate and in some of the cases, patch. Some were really simple to patch, some were difficult but only took a couple lines.
+
+Some other contributions:
+
+- implemented [view tags](https://github.com/monero-project/monero/pull/8061) to speed up wallet scanning.
+- identified and patched daemon reliability issues, especially for users of tor/i2p daemons (moved forward solving long-standing issues [6631](https://github.com/monero-project/monero/issues/6631), [6929](https://github.com/monero-project/monero/issues/6929), and [6938](https://github.com/monero-project/monero/issues/6938)):
+	- [Tor/i2p daemons periodically send a peer list that gets itself dropped](https://github.com/monero-project/monero/pull/8324).
+	- [The daemon periodically drops outgoing tor/i2p connections](https://github.com/monero-project/monero/pull/8330).
+	- [Tx re-relay math was off](https://github.com/monero-project/monero/pull/8326).
+- since Ledger was fairly unresponsive, I implemented the changes for the upcoming hard fork needed to send and receive:
+	- [monero repo](https://github.com/j-berman/monero/commit/cfbd590fd63ff9e0c5ec68c618e2f3fdaf24d241)
+	- [ledger repo](https://github.com/j-berman/app-monero/commit/c1a6eb8bbbc1cc7974ce0938e9d8f920d0ad3ae9)
+- patched a [cryptographic vulnerability in monero-python](https://github.com/monero-ecosystem/monero-python/commit/ece5b9d4cd929ced9539dca839d8a9fda4271663) (identified by kayabaNerve) where a malicious sender can get an honest recipient (who's using `monero-python` to scan for txs) to assume they received an arbitrary amount chosen by the sender (e.g. a 0.00000001 XMR tx could be made to look like 1000 XMR).
+- [identified that the updated fee algorithm didn't implement the expected algorithmic block size increase at consensus](https://github.com/monero-project/monero/pull/7819#discussion_r799064615).
+- implemented view tags in:
+	- [the onion block explorer](https://github.com/moneroexamples/onion-monero-blockchain-explorer/pull/266)
+	- [monero-lws](https://github.com/vtnerd/monero-lws/pull/33)
+	- [openmonero](https://github.com/moneroexamples/openmonero/pull/181)
+
+## Proposal
+
+187.5 XMR. 480 hours, 0.12 XMR/hr + $36/hr, $133/XMR from coingecko.
+
+I'm requesting a raise from my prior CCS because I feel I have demonstrated my contributions are worth a more competitive rate, and can continue to provide (increasing) value to Monero in a full-time capacity.

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

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: November 21, 2022
+amount: 253 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (84.3 Monero)
+    done: 31 December 2022
+    status: finished
+  - name: Month 2
+    funds: 33% (84.3 Monero)
+    done: 21 February 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (84.4 Monero)
+    done: 16 May 2023
+    status: finished
+payouts:
+  - date: 23 February 2023
+    amount: 168.6
+  - date: 21 May 2023
+    amount: 84.4
+---
+
+## What
+
+Continue full-time another 3 months in a similar capacity:
+
+- Prioritize debugging any significant issues that arise, such as [daemon connection issues](https://github.com/monero-project/monero/issues/8520#issuecomment-1310975634), [zmq missing publishing txs submitted to the daemon](https://github.com/monero-project/monero/pull/8427), [recovering multisig wallets from seed](https://github.com/monero-project/monero/issues/8537#issuecomment-1233946415), etc.
+- Complete work stress testing how daemons handle a transaction pool under heavy load to both gauge daemon performance, and to help get [PR 8076 - reduce wallet round trips to the daemon](https://github.com/monero-project/monero/pull/8076) across the finish line after gauging its impact on pool processing performance.
+  - The day leading up to the hard fork this summer, the transaction pool experienced heavier load than usual. Daemons that saw heavy traffic reported issues serving RPC requests. I would like to dig deeper into this.
+- Start working through Seraphis and Jamtis wallet tasks piecemeal, picking up collaboration with @koe, @rbrunner7, and @dangerousfreedom. The first task I've gotten a handle on and have a decently fleshed out view of what work is needed is input selection. I intend to get @koe's naive input selection implementation to production-ready, ensuring it functions as close to the wallet does today. From @koe [here](https://github.com/seraphis-migration/wallet3/issues/8#issue-1368934355): "a real implementation needs many more mechanisms and heuristics (e.g. filter for dust threshold to ignore, filter for origin statuses to permit, randomization and spread to mitigate timing analysis)"
+  - The general plan with Seraphis/Jamtis is to start fresh with new wallet code that avoids the complexity and pitfalls of `wallet2.cpp`, which at the moment is a source of growing technical debt (discussed a bit [here](https://github.com/monero-project/monero/issues/8157)). Considering Seraphis and Jamtis would bring a number of changes to core wallet features (a new address scheme, new balance recovery algorithm, new fee calculation, etc.), the proposed plan currently on the table is to start fresh rather than factor the existing `wallet2.cpp`. Many of the features that users already expect (such as sweeps, tx key recovery, watch-only wallets, etc.) would be maintained, or improved where possible. The implementation of some existing features is still up for discussion, such as [accounts](https://github.com/seraphis-migration/wallet3/issues/21).
+  - I'd like to reiterate this point: Seraphis and Jamtis still need to undergo stringent review both from the community and by independent 3rd parties. At this time, @koe is still working on the technical paper describing the protocol in its current iteration, which will need to undergo review in the future. Further, feedback on the core feature changes is still strongly encouraged and desired.
+- Review PR's.
+
+## Who
+
+I've identified and patched several privacy issues with varying severity in the Monero ecosystem:
+
+1. The reference wallet's decoy selection algorithm didn't select very recent spendable outputs in some cases. ([source](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+2. The reference wallet truncated integers in the decoy selection algorithm, which would have borked the decoy selection algorithm entirely if tx volume were to increase; in the normal case, it marginally weakened the algorithm. ([source](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html))
+3. `openmonero` was still using the old proven weak decoy selection algorithm, also leaving a fingerprintable trail by decoy selection algo. ([source](https://github.com/moneroexamples/openmonero/pull/177))
+4. MyMonero didn't use the updated CLSAG fee calculation which fingerprinted MyMonero txs on chain by tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/35))
+5. MyMonero's fee calculation->input selection logic differed ever-so-slightly from the reference wallet, resulting in a fingerprintable tx fee. ([source](https://github.com/mymonero/mymonero-core-cpp/pull/36))
+6. `monero-lws` fee masking on the server caused ever-so-slightly different fee calculations from the reference wallet, resulting in a fee fingerprintable to `monero-lws` (a fingerprint distinct from MyMonero). ([source](https://github.com/vtnerd/monero-lws/pull/31))
+7. In PR review on the latest hard fork's changes to the tx fee, identified the introduction of [slightly different fee calculation logic](https://github.com/monero-project/monero/pull/7819#discussion_r804404285) that would have caused tx fees to be fingerprintable to either old or new version until the hard fork.
+
+Other contributions:
+
+- Implemented [view tags](https://github.com/monero-project/monero/pull/8061) to speed up wallet scanning.
+- Implemented [background sync](https://github.com/monero-project/monero/pull/8619) initially proposed by @hyc so that wallets can scan for transactions in the background when the user is not active, without the spend key loaded in memory.
+- Identified and patched daemon reliability issues (moved forward solving issues [8520](https://github.com/monero-project/monero/issues/8520), [6631](https://github.com/monero-project/monero/issues/6631), [6929](https://github.com/monero-project/monero/issues/6929), and [6938](https://github.com/monero-project/monero/issues/6938)):
+	- [Tor/i2p daemons periodically send a peer list that gets itself dropped](https://github.com/monero-project/monero/pull/8324).
+	- [The daemon periodically drops outgoing tor/i2p connections](https://github.com/monero-project/monero/pull/8330).
+	- [Tx re-relay math was off](https://github.com/monero-project/monero/pull/8326).
+- Implemented the changes needed for Ledgers to function for the latest hard fork:
+	- [monero repo](https://github.com/j-berman/monero/commit/cfbd590fd63ff9e0c5ec68c618e2f3fdaf24d241)
+	- [ledger repo](https://github.com/j-berman/app-monero/commit/c1a6eb8bbbc1cc7974ce0938e9d8f920d0ad3ae9)
+
+Prior CCS proposals:
+- 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
+
+253 XMR. 480 hours, 0.16 XMR/hr + $48/hr, $131/XMR from coingecko.
+
+I'm requesting a raise from my prior CCS because I feel I have continued to demonstrate my work is worth a competitive market rate.

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

+---
+layout: cp
+title: j-berman full-time development (3 months)
+author: j-berman
+date: July 26, 2023
+amount: 216 Monero
+milestones:
+  - name: Month 1
+    funds: 33% (72 Monero)
+    done: 21 September 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (72 Monero)
+    done: 19 October 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (72 Monero)
+    done: 18 November 2023
+    status: finished
+payouts:
+  - date: 8 November 2023
+    amount: 72
+  - date: 2 December 2023
+    amount: 144
+---
+
+## What
+
+Work full-time 3 months on:
+
+- Continuing Seraphis wallet library work.
+  - My next task is to complete an async wallet scanner implementation using the Seraphis wallet lib that points to `monerod`.
+    - I have a working implementation that can be tested as described [here](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/359#note_21276).
+    - When I point this async scanner on my local machine to a remote `monerod` instance @selsta spun up, I observe a **~40% speed-up in scanning** over the current wallet2 scanner.
+    - The bulk of the remaining work to get it to PR-ready includes:
+      - Explore replacing the existing epee http client lib with a widely used http client lib like libcurl. This avoids needing to rewrite the epee http client lib to safely handle concurrent network requests.
+      - Code cleaning/factoring.
+      - Unit tests.
+  - Once I complete the async scanner, I plan to collaborate with @dangerousfreedom @rbrunner7 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.
+- 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 view, before Monero could actually consider accepting a PR for full chain membership proofs, there is a large amount of work still needed to prove its security and to land on a ready-for-production design. That work is currently proceeding in parallel. I would personally like to proceed with the above implementation work to maximize certainty that the Seraphis upgrade path is compatible with reasonably efficient full chain membership proofs.
+- Miscellaneous Monero work, debug issues, review PR's.
+
+## Who
+
+j-berman on github / jberman on matrix
+
+Past CCS's:
+- 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
+
+216 XMR
+
+480 hours, 0.16 XMR/hr + $48/hr, $166/XMR from coingecko

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

jeffro256-full-time-2023Q3.md

+---
+layout: cp
+title: jeffro256 full-time development 2023Q3
+author: jeffro256
+date: May 30, 2023
+amount: 147
+milestones:
+  - name: Month 1
+    funds: 33% (49.0)
+    done: 3 August 2023
+    status: finished
+  - name: Month 2
+    funds: 33% (49.0)
+    done: 7 September 2023
+    status: finished
+  - name: Month 3
+    funds: 33% (49.0)
+    done: 17 October 2023
+    status: finished
+payouts:
+  - date: 16 August 2023
+    amount: 49
+  - date: 12 September 2023
+    amount: 49
+  - date: 3 November 2023
+    amount: 49
+---
+
+## What
+
+I plan to work full-time to work towards accomplishing:
+1. Implementing Seraphis wallet code with Ukoe, jberman, et al.
+2. Drafting a formal specification for decoy selection and implementing it in a modular, robust, easily-testable way, and then creating a multitude of unit tests, integration tests, and statistical checks for this code.
+3. Reviewing other Monero core PRs, especially those related to Seraphis or @vtnerd's serialization changes.
+
+To expand on point 2, I think the decoy selection code is in need of a makeover. In light of recent, high-impact decoy selection bugs (more info [here](https://www.getmonero.org/2021/09/20/post-mortem-of-decoy-selection-bugs.html) and [here](https://github.com/monero-project/monero/issues/8872)), and whereas ring signatures are generally regarded as the weakest link in Monero's privacy model, I believe a new development initiative needs to take place to replace the decoy selection code. Typically I am against refactoring code "just because", but in this case it is warranted. All of the aforementioned bugs could have been spotted by statistical checks. However, currently, it is rather difficult to test the decoy selection in isolation due to the monolithic design of `wallet2`. In theory, decoy selection code could be written to be rather functional. To over-simplify, we take distribution of enotes on-chain usable for given for true spends, apply arbitrary picker distribution, then request information for selected decoys over RPC, retrying the process if enotes are blackballed or otherwise unsuitable. There are a lot of edge cases to consider, but there isn't any major reason why decoy selection can't be modularized and standarized apart from the rest of the wallet code. This goal also overlaps with point number 1, since this code can be used not only in `wallet2`, but in future versions of core wallets if written correctly.
+
+## 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 [>=48 merged commits](https://github.com/monero-project/monero/graphs/contributors?from=2022-01-25&to=2023-05-30&type=c) thus far. Some more notable contributions:
+
+* Implemented [research issue 109](https://github.com/monero-project/research-lab/issues/109) by [authoring a PR](https://github.com/monero-project/monero/pull/8815) that, when spending coinbase enotes, chooses coinbase enotes as decoys and vice versa.
+* [Implemented](https://github.com/monero-project/monero/pull/8861) a requested wallet transfer feature that enables "fee-included" transactions
+* [Found and fixed](https://github.com/monero-project/monero/pull/8707) an issue which nearly allowed a double spend bug, and could cause double spend bugs in the future if the code was not carefully inspected
+* Helped review [patch](https://github.com/monero-project/monero/pull/8794) and write [disclosure report](https://github.com/monero-project/monero/issues/8872) on recent decoy selection bug.
+
+Previous Proposals:
+- https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319
+
+## Payment
+
+I propose to work 40 hours/week for 3 months so 480 hours total. I'm setting my hourly rate at ~$43/hour, and at a price of $140/XMR (as of June 10th 2023), this makes for a total of 147.4 XMR. The proposal is broken into 3 milestones, one for each "month". These milestones may lag behind schedule if I do not complete 40 hours per calendar week, but in that event, I will not ask for payout until the hours are done.
+