serhack-monero-integrations-part-3.md

@@ -67,4 +67,12 @@ I would like to expand more this section since it is a subject close to my heart
 
 ### Costs
 
-If milestones are not modified, I'll ask 11 XMR (~700 euros) - fixed price.  
\ No newline at end of file
+If milestones are not modified, I'll ask 11 XMR (~700 euros) - fixed price.  
+
+### Proposal transfer
+
+This proposal will be transferred to recanman who will enjoy an exclusivity period of 5 months to show reasonable progress in completing this proposal. They will receive payments for completed milestones directly.
+
+SerHack: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/402#note_22039
+
+>To consider the CCS completed, all the issues mentioned in the CCS must be completed: recanman will need to push changes to monero-integrations repositories and after reviewing the PRs, I'll close the issues.

soloptxmr-mj-endor-2022.md

+---
+layout: wip
+title: SolOptXMR - Solar Optimal mining of XMR
+author: mj
+date: Mar 26, 2022
+amount: 110.55 XMR
+milestones:
+  - name: 1 Initial setup
+    funds: 20.10 XMR
+    done: 29 May 2022
+    status: finished
+  - name: 2 Profitability calculator
+    funds: 16.75 XMR
+    done:
+    status: unfinished
+  - name: 3.1 Measurements mj
+    funds: 20.10 XMR
+    done: 22 July 2022
+    status: finished
+  - name: 3.2 Measurements Endor
+    funds: 16.75 XMR
+    done:
+    status: unfinished
+  - name: 4.1 Automation mj
+    funds: 20.10 XMR
+    done: 24 November 2022
+    status: finished
+  - name: 4.2 Automation Endor
+    funds: 16.75 XMR
+    done:
+    status: unfinished
+payouts:
+  - date: 2 July 2022
+    amount: 20.1
+  - date: 28 December 2022
+    amount: 40.2
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# What
+The goal is to create open-source software that aids people mining Monero with excess solar power in the most profitable way. It will accommodate for issues such as:
+
+- Time of day
+- Weather fluctuations
+- Avoiding depleting batteries below a threshold, that would damage them
+- Avoiding overheating the mining rig
+- Leaving enough power for your daily use
+
+# Intro
+I promised I'd help out in the [Monero Recruitment Matrix Room](https://matrix.to/#/#monero-recruitment:monero.social).
+Although there was just one direct request to me so far, recently I've also pro-actively proposed cooperation to the chat room members. I presented there 2 projects, that are on my mind, and don't require extensive crypto knowledge, typically not available to students. Yet the projects are still useful for Monero specifically. One of the projects that I have on mind is optimization of mining performance on a solar farm, depending on varying inputs. The member Endor ([endorxmr](https://github.com/endorxmr) on GitHub and endor00 on Matrix) signed up for being the main contributor to the project, while I would serve as a mentor: namely coordinator, reviewer and designer. Such a setup will guarantee, that I won't get dragged away too much from the maintenance of Monero, that I signed up for, while at the same time, Endor will be able to continuously have access to my years of experience in automatic control and object oriented design. Endor on the other hand is heavily involved in everything, that’s connected to mining profitability.
+
+Should Endor not make it until the deadline, I guarantee, that I will finalize the project by myself until the coming winter.
+
+Introducing the project: SolOptXMR – Solar Optimal mining of XMR.
+
+# Why
+The following [YT video](https://www.youtube.com/watch?v=7OpM_zKGE4o) is able to bring you more context why this idea has a chance for being a trending subject and is here to stay. The outline of this video is the following:
+Because of high initial, as well as perpetual investments required for producing power from solar collectors in Sahara/Nevada and delivering it to northern states, such an investment, contrived in the previous decade under the name "DESERTEC", turned out to be not the best possible investment. The project's relative profitability decreased across the years even more. The reason is, that the costs of production of solar panels dropped so low, that now it makes more sense to place them exactly where the produced power is most needed, even though the solar irradiation is lesser at these places.
+
+On a sentiment / geopolitical side of things, with the rising prices of heating gas, I expect many people will be wanting to save on their gas costs by switching to electrical heating. Since the majority of such heaters demand high power, ranging from 2kW to 2.5kW and since a given population will typically want to switch them on all at the same time, I predict that we'll be facing a decent wave of blackouts in the coming winter. This has motivated me to build my solar farm. 
+
+If you are an individual who likes to take the matters into your own hands, you might have considered building a small solar farm yourself. Although our system won't assume a given user's setup, my particular farm is configured as an isolated island. This means, that I don't sell my overproduction to the grid for the pennies, that the state offers, but rather use the production for mining and cooking, while the overproduction is temporarily stored in a pair of cheap but reliable car batteries. My farm serves as a perfect test bed for the system, that we're going to design and automate for you. Optimized mining of Monero on such a system amortizes the installation costs over the long run, will help you learn about electricity and motivate you to become more resilient. Further compatible extensions are possible, such as small wind generators as well as bikes with flywheels, that [recover kinetic energy](https://www.youtube.com/watch?v=MBW_2gUSMXc). Such systems are already available on the market, that tends to think ahead of the time, so you don’t have to DIY.
+
+# System description
+
+The dynamics of the system, that tries to optimize the mining efficiency has to take into account the following inputs and goals. Some of them are obvious while others maybe not so much.
+
+- Static astronomic data, that describe the relative movement of the Sun across the sky in various latitudes and times of year - yielding the maximal expected power that can be reached
+- Weather predictions - a cloudy sky can reduce the power output by more than 80%
+- If the predicted power generation is off the measured generation, a warning might be issued to clean the panels
+- Voltage (load state) of the batteries, as well as voltage that reaches the DC->AC transformer, as some of it might be lost in the cables, that are either too long or have accidentally formed an inductor
+- Predicted load state of the batteries on the next day before the Sun rises and the charging starts, as emptying the chemical batteries below 50% tends to damage them  
+- Mining rigs' temperature readouts as it's not worth to meltdown your hardware for those couple of Piconeros being mined.
+- A given computer's hashrate per Watt - use the most efficient ones first, but don't overheat them
+- A given computer's idle power cost - sometimes it will make sense to switch on certain less efficient computers only if there's really way too much power production, and/or the most efficient ones overheat, or it's predicted that they'd overheat soon under the, also predicted, future conditions.
+- Per core efficiency compared against multithreaded efficiency - for CPUs with smaller caches, the efficiency (in this case: hashrate) scales poorly with more threads working at the same time. In such cases it will make sense to spread the mining across longer periods of time on a single core.
+- The owners' power usage habits - taking into account, that you might want to use a low powered, compatible electric heating system at a given time of day, by leaving some energy in the batteries for you to consume, before the predicted event – learned either from your usage habits, or from your manually scheduled input.
+- The owners' setup – whether an isolated solar island is used, output connected to grid (for selling) or supplementing power losses from the grid (buying) or both of the last 2 options.
+
+The control mechanisms of the system would be the following:
+- Downclocking the CPUs - very easy to achieve under Linux with a high precision, thus allowing for a smooth control
+- Restarting the mining with a smaller number of cores
+- Putting computers to sleep and waking them up with Wake On LAN on the next day
+
+While it would be easy enough to control the system via PID controller, and I know a lot about it, such a system would have little prediction power, delivered only by the first differential part of the controller (the D) and only between the current and the previous state. Using a Time Series Analysis and Prediction tool, such as the already available `tsqsim`, will give the system the ability to look ahead into the future (like at least 48 hours ahead) and plan accordingly to maximize the gain per the unit of energy used, while at the same time planning carefully against overheat of the hardware, under-voltage of the DC->AC transformer, leading to an immediate halt of the system, as well as against under-voltage (as in: capacity) of the batteries, which would otherwise quickly damage them.
+
+The inputs to the system will come in a few forms – either assumed, input by the user or measured. The measurements can be easily supplied via smart plugs or measured directly. Ultimately it has to be left to the user to decide how much time to spend on providing additional inputs, that result in improvements of predictions, thus profitability. The goal here is however to keep the measurements optional, not to impose burden on the user.
+
+# Who
+mj – working for Monero since 2 years on the purely technical level. Speeding up compilation and Continuous Integration on GitHub, keeping an eye on overall efficiency, generating [Monero health report](http://cryptog.hopto.org/monero/health/), reviewing technical PRs, helping out new developers. Lately developing Time Series Analysis tool for Monero Research Lab, called `tsqsim`. [Here’s a list](https://github.com/search?q=is%3Apr+author%3Amj-xmr+archived%3Afalse+is%3Aclosed) of all my contributions to Monero and to the supporting software.
+
+Endor – Aerospace Engineering student and a junior Python developer on the side. I already have a few small projects under my belt - one of which related to automation and monitoring of a live system. I've been following the Monero project for over 5 years, learning the ins and outs of cryptocurrency mining and moderating the Supportxmr chat and the Monero Mining room on Matrix (#xmrmine:matrix.org). I am currently developing a comprehensive economic model of mining, and I plan to publish a small paper/series of articles over the next few weeks that will (hopefully) serve as "the ultimate guide to mining" for newcomers and professionals alike. A glimpse into my work can be seen in [this minimalistic script](https://gist.github.com/endorxmr/07364dc54f277abf487574d455d67341), that dynamically calcylates the CPUs mining profitability and compares it across various other CPUs. An example output (though shortened) can be seen below:
+
+```
+python3 mining-profitability.py 
+Difficulty: 354634073114
+Average blocktime @6500 H/s: 631 days, 11:18:08
+Price: 201.98 - XXMRZUSD
+Expected crypto income/s: 1.236e-08
+Expected fiat income/s: 2.496e-06
+Profitability: 38.2%
+Miner efficiency: 100.0 H/s/W
+ROI time: 12577.0 days to recover 750 USD
+Breakeven efficiency @0.1/kWh: 72.3 H/s/W
+Network power consumption @0.1/kWh: 40849693 W
++--------+--------+-------+--------+
+| Period | Profit | Mined | Power  |
++========+========+=======+========+
+| Day    |  0.060 | 0.001 |  0.156 |
+| Week   |  0.417 | 0.007 |  1.092 |
+| Month  |  1.789 | 0.032 |  4.680 |
+| Year   | 21.770 | 0.390 | 56.940 |
++--------+--------+-------+--------+
++-------------------------------+--------+-------+------------+--------+
+|              CPU              | Speed  | Power | Efficiency | Amount |
++===============================+========+=======+============+========+
+| AMD EPYC 7763 (dual)          | 100000 |   750 |    133.333 |  54467 |
+| AMD Ryzen Threadripper 3990X  |  65000 |   600 |    108.333 |  68083 |
+| AMD Ryzen 3600X               |   7500 |    70 |    107.143 | 583568 |
+| Intel Xeon Silver 4216 (dual) |  16157 |   312 |     51.785 | 130929 |
+| Intel Core i7-4720HQ          |   1768 |    45 |     39.289 | 907771 |
++-------------------------------+--------+-------+------------+--------+
+```
+
+# Milestones
+
+## 1 Initial setup
+The initial setup, that is able to use static astronomic data inputs (let’s call it by its name used in the industry: seasonality) and simple weather forecasts (sunny/cloudy/in-between) to make predictions based mostly on user input as to how much power a given computer and its cores consume, taking into account how much power is expected to be consumed in house for other purposes, that have to be treated as of a higher priority. Initially a status message will be displayed about what to do manually to maximize the selected goals. Plots of the inputs and outputs will be displayed, that explain why such a suggestion was presented.
+
+Will be done mostly by mj, since Endor shouldn’t be strained with too many foreign systems, only receive the system’s output signals. This will require about 2 weeks of work full time, that makes:
+- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
+- 96 work hours / 10h in a week = 9.6 weeks spread.
+
+## 2 Profitability calculator
+Profitability calculator, taking into account the power costs, grid’s buy-back prices (if available) and user’s price target, at which to sell the mined coins. Also a very important input will be the time-bound energy availability, delivered through the system from the Milestone 1
+
+This milestone will be done mostly by Endor, due to his experience in the field. I will only support via tips such as obtaining user input and code reviews, design suggestions, etc. I won’t count my pay on this one. This can be started before milestone 1) is finished, on a basis of simple generated sinusoidal signals, that will soon enough be replaced with real data.
+
+Endor’s:
+- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
+- 144 work hours / 15h in a week = 9.6 weeks spread.
+
+
+## 3 Measurements
+3) Support for various kinds of measurements – smart plugs, digital converters, software temperature readouts and even simple image recognition of LCD/LED displays of the DC→AC transformer and MPPT regulator.
+
+Both of us have experience in various parts here and wish to take equal part in this milestone. I’ll create up to two examples of image recognition.
+mj’s:
+- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
+- 96 work hours / 10h in a week = 9.6 weeks spread.
+
+Endor’s:
+- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
+- 144 work hours / 15h in a week = 9.6 weeks spread.
+
+## 4 Automation
+Automation of the system, including remote CPU downclocking, selecting the number of threads, putting computers to sleep, and waking them up via the Wake On LAN technology. We will be promoting privacy oriented and non-controversial software, namely: [p2pool](https://github.com/SChernykh/p2pool) and [xmrig](https://github.com/xmrig/xmrig), accordingly.
+
+Same as above, both of us have experience and ideas here. I already perform such tasks manually (via scripts) on my solar farm, so I know “the feel” of the system. Endor has many great ideas and a lot of expertise for this milestone as well, as this resonates with his prior experience with mining profitability and a variety of mining software + hardware.
+
+mj’s:
+- 6 (Monday-Saturday) * 2 (weeks) * 8 (hours) = 96 work hours
+- 96 work hours / 10h in a week = 9.6 weeks spread.
+
+Endor’s:
+- 6 (Monday-Saturday) * 3 (weeks) * 8 (hours) = 144 work hours
+- 144 work hours / 15h in a week = 9.6 weeks spread.
+
+# Legal & privacy
+The project shall be released under AGPLv3. It will send no telemetry by default, unless the user wishes to have their data uploaded and analyzed. The data will surely serve as a stabilization asset of the project and will be included in the automated system tests as one of many test cases. The complete data set to be sent will always be shown to the user for a review and approval.
+
+As I’m familiar with the EU laws regarding solar panels a bit, I will be providing the users non-legally-binding relevant advice.
+
+Even though I’m not strictly an electrical engineer, I know enough tricks in this field and I understand many nuances about the inner workings of such systems. I know what hardware are compatible with each other and how to calculate the supply and demand of the produced power. Therefore I can provide advice in this field as well, yet again: non-legally-binding.
+
+# Proposal
+As of 12 April, XMR/EUR is at 214.92 EUR.
+
+## mj:
+I will be able to spend about 10 hours / week on the project. An amount so low, that it doesn’t collide with my maintenance assignment, nor Monero Research Laboratory, once I switch there for a while. My rate per hour is 45 EUR. The total number of work hours is: 96 + 96 + 96 = 288. 
+288 [h] * 45 [EUR/h] / 214.92 [XMR/EUR] = 60.3 XMR
+
+## Endor:
+I will be able to spend about 15 hours / week on the project. My rate in my first ever proposal is at 25 EUR / h. The total number of work hours is: 144 + 144 + 144 = 432. 
+432 [h] * 25 [EUR] / 214.92 [XMR/EUR] = 50.25 XMR
+
+Since in this case we are really talking about seasonal data, that doesn’t require a lot of readjustments, further maintenance will not be a burden for any of us. Unless many new features are requested, we will gladly maintain it for you without asking for compensation.
+
+## Summary:
+60.3 + 50.25 = 110.55 XMR is what we're asking for. Thanks in advance!
+
+## Deadline calculation
+A rough deadline calculation based on the spread of the hours and including the tasks that can be done in parallel:
+9.6 [weeks] * 3 / 4.1 [weeks in a month] ~ 7 months.
+This coincides with the promise to finalize the project until winter if all goes well with Endor’s plan. If not, I can take over most of the responsibilities, as there are always ~1-1.5 month breaks between my maintenance proposals.
+
+Cheers!
+
+# Expiration date
+31 Oct, 2022

spirobel_robust_modular_wallet_rpc.md

+---
+layout: cp
+title: Robust and modular wallet-rpc library
+date: Sep 10, 2024
+author: Spirobel
+amount: 100
+milestones:
+  - name: Deved + prepayment for first month
+    funds: 20 XMR
+    done: 9 October 2024
+    status: finished
+  - name: First month
+    funds: 30 XMR
+    done: 23 December 2024
+    status: finished
+  - name: Second month + value commitment
+    funds: 50 XMR
+    done: 19 February 2025
+    status: finished
+payouts:
+  - date: 16 October 2024
+    amount: 20
+  - date: 28 February 2025
+    amount: 80
+---
+
+# Robust and modular wallet-rpc library
+
+## Who
+
+**Spirobel**
+
+References:
+
+#### found and reported a "pay what you want" vulnerability in AcceptXMR
+
+https://x.com/spirobel/status/1672479215512588288
+
+https://github.com/busyboredom/acceptxmr/issues/64
+
+#### open sourced a Patreon like tool for Monero
+
+https://x.com/spirobel/status/1595949928634667008
+
+https://github.com/spirobel/monero-discourse-subscriptions
+
+#### open sourced a merchant focused wallet-rpc
+
+https://x.com/spirobel/status/1596299822516285440
+
+https://github.com/spirobel/monerochan-merchant-rpc
+
+
+#### implemented a Monero Browser wallet extension
+
+https://www.youtube.com/watch?app=desktop&v=4DLcsQ45zoE
+
+Contact: twitter.com/spirobel
+
+## What
+
+Result: A robust and modular wallet-rpc library, implemented in Rust with WebAssembly (WASM) as the primary target. This library aims to provide a flexible foundation for Monero wallet functionality. The deliverable for this proposal will be:
+
+1. the first part of the wallet-rpc library that can sync transactions and works reliably with remote nodes.
+2. A checkout flow built with this library. This is meant to be used, not just to demonstrate the features.
+3. Detailed documentation for the library, the relationship between nodes and wallets during the syncing process and a guide on how to use this to implement monero payment gateways.
+
+### Implementation
+
+list of initial tasks:
+
+- create function to turn address and private viewkey into viewpair
+- create function to scan transaction with sub functions
+- verify that there is no timelock present
+- calculate transaction amount
+- clarify responsibility of burning bug prevention for the caller
+
+- implement transaction fetching and storage
+- implement burning bug prevention in the checkout flow
+- write unit tests, document and publish the library
+- implement UI for the checkout flow
+
+this task list is not exhaustive and subject to change
+
+## Why
+
+As discussed as far back as two years ago: https://github.com/seraphis-migration/strategy/issues/2
+The wallet2 Monero library is a 15k lines CPP file. The official monero repo does not contain a deliverable that is easily linkable from other programs. Every project that is a wallet or contains wallet-like functionality (payment processors, hardware wallets, point of sale terminals) needs to implement its own wrapper to expose a C ABI.
+
+This results in collectively wasted hours and headaches. It increases supply chain risk and makes building things with Monero harder. As a result, projects get more expensive, take longer or don't happen at all.
+
+This library aims to counteract the issues and limitations of wallet2.cpp by directly targeting wasm.
+Using wasm as the main target means that this library is forced to be implemented in a way that meets the expectations outlined here: https://github.com/seraphis-migration/strategy/issues/1
+
+The benefits of this approach:
+
+### 1. It will be easily linkable
+
+WASM is a very constrained target. There is no garbage collection and multi threading. Getting code to run there means having to write it in a way that is easy to interact with from any language and in any environment.
+
+### 2. It will be more robust
+
+The current monero wallet-rpc is at times unresponsive, because its concurrency mixes the responses of the local rpc with the network interacting with the node. More details in the [monero-playground repository](https://github.com/spirobel/monero-playground). The WASM target constraints ensure that this library decouples the concurrency and networking from the wallet code. The result will be more robust.
+
+### 3. It will be more flexible and not tied to any platform / target
+
+Wallet code deals with the most sensitive data. It should not have unnecessary dependencies or bloat. To give a practical example: monero currently vendors a 4000 lines of code [logging library](https://github.com/monero-project/monero/blob/master/external/easylogging%2B%2B/easylogging%2B%2B.cc) that introduces a dependency on signals. The WASM target constraint means that things like that can't and wont be introduced into this library.
+
+## Milestones and Timeline
+
+value commitment:
+
+The 3 deliverables outlined in the **What** section are the promised outcome of this proposal. Any time left over from the time commitment will be used to further advance the road map. The value commitment is due for the milestone of the second month.
+
+time commitment:
+
+- 100 hours per month for two months (100 hours total)
+- Compensation: 50 XMR per month (100 XMR total)
+- Total compensation: 100 XMR
+
+## Future Roadmap
+
+The next step on the road map is to add transaction building and signing functionality to the library and migrate [the browser wallet](https://www.youtube.com/watch?v=4DLcsQ45zoE) to it.
+
+My endgame is to **remove all friction from the privacy enabled web shopping experience**. Currently most **Monero shoppers** have to copy and paste addresses from the tor browser into their wallets. This opens the door to unnecessary opsec failures, as it is easy to get confused and intimidated by long strings of random numbers.
+
+**A core part of staying private and safe online is to compartmentalize identities.** Qubes OS made some advancements in improving the UX of this activity by coloring different windows that are tied to different identities in a unique way.
+
+The reality is, that installing a different operating system is a large ask for the average person. At the same time we need to onboard as many people as possible to these habits, so we can operate safely in the crowd.
+
+The other venue of attack is **using the browser for compartimentalization.** And before anybody complains: no this does not involve untrusted javascript frontend code.
+
+There is a big difference between a browser wallet and web wallet. A web wallet is a flawed experiment that is borderline custodial, as it runs wallet code inside the context of a website. This is not to be confused with a browser wallet.
+**A browser wallet runs trusted code as a compartmentalized, constrained program inside of a sandbox.**
+
+There is a massive opportunity here to reduce friction by making it easy to separate online identities. The TOR browser currently enables the use of one separate TOR circuit for each tab. **Imagine we have one monero address per tab that is used for login and to send and receive payments.** It makes it much harder to mess up.
+
+One last concern that comes up is that there might be zero day exploits in the browser, as it exposes a potentially larger attack surface. This can be mitigated by making the wallet a multisignature wallet and **using a second device like an android phone or a monero seedsigner to authorize every transaction.**
+This means two devices need to be compromised to capture funds, which is unlikely.

staff91-Translation and review of GUI Wallet, monero-site, Monero Means Money (subtitles) and Sound Money, Safe Mode (subtitles) to Italian.md

+---
+layout: cp
+title: Translation and review of GUI Wallet, monero-site, Monero Means Money (subtitles) and Sound Money, Safe Mode (subtitles) to Italian.
+author: staff91
+date: November 18, 2020
+amount: 28
+milestones:
+  - name: Milestone 1 - Completion of GUI Wallet, monero-site Translation and review to Italian
+    funds: 4 XMR
+    done: 
+    status: unfinished
+  - name: Milestone 2 - Completion of Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) Translation and review to Italian
+    funds: 24 XMR
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+## Proposal Closure
+
+The remaining funds (28 XMR) have been donated to the General Fund.
+
+---
+
+# About this Proposal
+
+Translation and review of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/), [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/), [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) to Italian.
+
+Review of translation made by others (if any) of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/), [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/), [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/) for free to Italian.
+
+# About the Translators
+
+## staff91
+  
+  Hello my name is Stavros Kilonis and I was a member of the RChain Cooperative Bounties Program. I am a translator and a developer. Created the Italian website and translated everything for the bounties to Italian.
+
+### Links
+
+- [Monero Project Translations (Weblate)](https://translate.getmonero.org/user/staff91/)
+- [GitHub](https://github.com/staff91)
+- [Monero's GitLab](https://repo.getmonero.org/staff91)
+
+## Chris-Arv  
+  
+  I have worked with staff91 in the past for the same projects.
+
+### Links
+
+- [Monero Project Translations (Weblate)](https://translate.getmonero.org/user/Chris-Arv/)
+- [GitHub](https://github.com/Chris-Arv)
+- [Monero's GitLab](https://repo.getmonero.org/Chris-Arv)
+
+
+# Milestones and Projected Timeline
+
+## Milestone 1 - Completion of GUI Wallet, monero-site Translation and Review to Italian
+
+Complete translation of the [GUI Wallet](https://translate.getmonero.org/projects/monero/gui-wallet/) and [monero-site](https://translate.getmonero.org/projects/getmonero/monero-site/).
+
+Comprises of 4909 words, which equals to 4 XMR.
+
+Timeline: 20/11/2020 - 30/11/2020
+
+## Milestone 2 - Completion of Monero Means Money (subtitles), Sound Money, Safe Mode (subtitles) Translation and Review to Italian
+
+Complete translation of the [Monero Means Money (subtitles)](https://translate.getmonero.org/projects/community/monero-means-money/) and [Sound Money, Safe Mode (subtitles)](https://translate.getmonero.org/projects/community/sound-money-safe-mode-subtitles/).
+
+Comprises of 24093 words, which equals to 24 XMR.
+
+Timeline: 01/12/2020 - 15/12/2020
+
+**Proposal Expiration Date**: 30/11/2020
\ No newline at end of file

syntheticbird_cuprate_arti_2_months.md

+---
+layout: wip
+title: SyntheticBird Cuprate Arti integration and development (2 months)
+author: SyntheticBird
+date: March 9, 2025
+amount: 52.5
+milestones:
+  - name: April
+    funds: 50% (26 XMR)
+    done:
+    status: unfinished
+  - name: May and completion of Arti integration
+    funds: 50% (26.5 XMR)
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+# Who
+
+I am [SyntheticBird](https://github.com/SyntheticBird45), Cuprate contributor.
+
+# What
+
+Cuprate is currently in alpha version and a lot of features are planned on the roadmap up to beta phase. One of the features present on this roadmap, and that was [originally presented when announcing Cuprate](https://github.com/Cuprate/cuprate/blob/fc9b077d946fe8b7746c45ae8b299a87b2014cbf/readme.md?plain=1#L57), is native support for Tor network. This CCS proposal intend to fulfill this milestone.
+
+I will work for an estimated 2 months, from April to end of May, on Cuprate with the goal of implementing native Tor support into `cuprated` through the `arti-client` crate and other miscellaneous improvements.
+At the end of this CCS, testers will be able to:
+- Bootstrap Tor network within Cuprate or use Tor system daemon.
+- Use Tor for outbound clearnet connections.
+- Natively connect to onion monero nodes.
+- Generate an onion service for accepting inbound Tor connections.
+
+# Tasks
+
+The planned set of tasks to complete can be found at this Github gist: https://gist.github.com/SyntheticBird45/4c554d3c1e7ae6f8d237d7dd49c2d2f0
+
+It is subject to change but overall the required work can be separated into 3 categories:
+
+### 1. Alternative network integration into P2P components.
+
+Currently, Some P2P components have limited support for alternative network rules. This will require modifying `AddressBook`, `Connector`, `HandshakeBuilder`, `cuprate-dandelion` crate and `cuprated`'s dandelion implementation, and others to be *anonymization-network-aware*. After this work, we will define a new `NetworkZone` called `Tor` to connect to onion monero nodes.
+
+### 2. Implementation of Arti and Tor Daemon support
+
+Implementing `arti-client` inside `cuprated` and `cuprate-p2p{-*}`. Configurations, initialization, bootstrapping and launching onion services if requested. System tor daemon will also be supported.
+
+### 3. Documentation
+
+Update [Architectural book](https://architecture.cuprate.org) and [User book](https://user.cuprate.org/)
+
+# Additional work
+
+In the event that all guaranteed items are completed before the 2 months, I will spend my remaining time assisting (Issues, PRs and Reviews) on whatever is agreed is highest priority, or working on the following items:
+
+- Custom Allocator support (Performance improvements for Musl based linux distributions and potentially minor improvements on other OSs)
+- SOCKS5 proxy support for p2p
+- Fjall database integration
+- Related documentation
+
+# Milestones
+
+### 1. First month
+
+26 XMR
+
+### 2. Second Month and completion of main tasks
+
+26.5 XMR
+
+# Licensing
+
+All the works completed under this CCS will be delivered to the [`Cuprate/cuprate.git`](https://github.com/Cuprate/cuprate) github repository. This work will follow the current repository licensing:
+- All work inside `/binaries` is licensed under `AGPL-3.0-only`.
+- The rest of the root and crates are licensed under `MIT`.
+
+For more information about the Cuprate github organization, please [visit the organization page](https://github.com/Cuprate)
+
+# Funding
+
+I will be working 30 hours per week during 8 weeks at 45\$/hr - 205\$/XMR.
+30×8=240 | 240×45=10800 | 10800÷205=52.5
+
+Total: 52.5 XMR

thecharlatan-vps-1.md

 ---
-layout: wip
+layout: cp
 title: "TheCharlatan: VPS funding for reproducible gui builds"
 author: TheCharlatan
 date: 22 January 2020

tipxmr.live.md

+---
+layout: cp
+title: "tipxmr.live - a non-custodial livestream donation service for OBS"
+author: AlexAnarcho and hundehausen
+date: September 16, 2020
+amount: 72
+milestones:
+  - name: Milestone 1 - Basic setup of webpack with monero javascript and react
+    funds: 2% (1.44 XMR)
+    done: 17 March 2022
+    status: completed
+  - name: Milestone 2 - Working Prototype with implemented WASM wallet and front-end mockups
+    funds: 48% (34.56 XMR)
+    done: 21 December 2024
+    status: completed
+  - name: Milestone 3 - Finished product and launch of serivce
+    funds: 50% (36 XMR)
+    done: 21 December 2024
+    status: completed
+payouts:
+  - date: 17 March 2022
+    amount: 1.44
+  - date: 12 February 2025
+    amount: 70.56
+---
+
+## Proposal deprecation / Repurposing of funds (21st Dec, 2024)
+
+AlexAnarcho and hundehausen shared a [candid update](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/524#note_27732) regarding progress of TipXMR. Exerpt below:
+
+>We were young and naive and thought "how hard can it be to code this up" - harder than we thought it turned out.         
+>
+>We had very high standards, trying to use WASM wallets on the client-side where no info is leaked to the hoster of the TipXMR service, but this lead to a high barrier - which in turn lead to us never shipping anything   
+>
+>[...]    
+>
+>We are okay to deprecate the TipXMR CCS proposal and pass our collected funds on to this XMRChat proposal.
+
+The remaining funds from:
+
+* Milestone 2 - Working Prototype with implemented WASM wallet and front-end mockups (34.56XMR)
+* Milestone 3 - Finished product and launch of serivce (36XMR)
+
+Will be rewarded to https://xmrchat.com/ - [source](https://github.com/sa8ab/xmrchat)
+
+Who instead of implementing a WASM wallet to not share view keys with the service host have performed the following tasks deemed to be of the same value/importance:
+
+* Integrated monero-lws to handle multiple streamer view-keys.
+* extra misc. features such as a personal donation page with comments attatched.    
+
+# CCS Proposal: tipxmr.live - a non-custodial livestream donation service for OBS
+
+
+## Exec Summary
+
+[Tipxmr.live](https://github.com/hundehausen/tipxmr) aims to be a non-custodial service for streamers to accept and display Monero donations in their livestreams.
+
+Much like the existing solutions, this allows for an interactive experience for viewers and an easy way to monetize for the streamer.
+
+For this we use a browser based Monero WASM wallet and OBS.
+
+
+## The Problem we want to solve
+
+Censorship on the internet is an ongoing issue. Big platforms like YouTube and Twitch wield godlike power when it comes to their users. Not only do they impose barriers to entry, they also deplatform at whim and destroy years of work take away steady income streams. Content creators either have to conform and self censor or change their occupation.
+
+Furthermore, streaming platforms take big chunks of the streamers income, for example Twitch Bits. Some platforms take as much as 40% of the streamers donations (Chaturbate).
+
+Tipxmr.live fixes this.
+
+### Advantages of our solution
+
+With tipxmr.live we enable streamers to recieve income independent of a given platform. For this we employ Monero natively in the browser. Donors send XMR directly to the streamer without tipxmr.live as a custodian.
+
+Being build upon the Monero project, we inherit many benefits of the privacy coin we all love.
+
+Streamers are not required to have access to the banking system, all they need is provided for free on the internet (i.e. Monero and OBS).
+
+Moreover, streamers do not have to hand over personal information such as location, real identity and more. This opens the door for marginalized groups to recieve income, even if the doors to the tradional system is barred.
+
+
+## Who we are
+
+We are two Monero enthusiasts that have been following the project since the beginning of 2017. Our values are privacy, sound money and individual souvereignty. Crypto in general and Monero in particular fulfill these values and are the tool of the future.
+
+In the beginning of 2018 we created the [MoneroMumble Podcast](https://moneromumble.de/), a german-speaking, monthly podcast/roundtable to inform and engage the German community about developments concerning Monero. The roundtables take place on the second Sunday of every month on Jitsi and are livestreamed to YouTube.
+
+It was in this setting that the idea of a livestream donation program based on Monero was born. Tipxmr.live is therefore aiming to fulfill our need and we are our own customers.
+
+Grischa, aka hundehausen, has contributed many times to the Monero community, most recently with an [infographic about the workings of a Monero wallet](https://reddit.com/r/Monero/comments/gy0m1u/i_made_an_infographic_on_how_a_monero_wallet_is/). Grischa also wrote his bachelor thesis on the thought of "Monero as a currency for the masses" (thesis in German).
+
+Alex, aka AlexAnarcho, has been involved in the early days of the Monero Outreach and is a well-known outspoken advocate for Monero in the German community. Alex has been working for various cryptocurrency magazines such as the BeInCrypto and BTC-ECHO. In August he quit his full-time job at BeInCrypto to dedicate himself to tipxmr.live.
+
+[mghny](https://github.com/mghny) - who chooses to remain pseudonymous - has been a professional software-engineer for 5 years and has been coding for 8 years. They have been involved with tipxmr.live since the very beginning and keeps an eye on architecture, code and many more technical aspects. It cannot be overstated how beneficial an experienced engineer is in a project like ours, since it reduces complexity and makes the code easily reusable by other developers.
+
+
+## What is your project
+
+Since our [original idea and prototype](https://github.com/hundehausen/obs-monero-donations), the implementation has significantly evolved. The most obvious issue with the prototype was that it required a broad technical understanding. You can try it out by cloning the repo and seeing first-hand how cumbersome this process is. After cloning the repo you have to set up either a VPS or self-host and use portforwarding. Then you have to install monero, run an RPC, buy a domain, issue a SSL-certificate and so forth. In short, a process that no ordinary person would go through.
+
+But we don't want to be the only people enjoying the benefits of Monero. We want to make it accessible to _everybody_ - even non techy people. Therefore we went back to the drawing board and came up with a way that is intuitive yet non-custodial and as safe as possible.
+
+The current vision only requires [OBS](https://obsproject.com/), which is not only the biggest streaming software but also open source. In this we are platform agnostic and our users can use YouTube, Twitch, any other streaming platform or even host the stream themselves.
+
+
+### How it works
+
+The biggest issue in the beginning was how to make this whole thing non-custodial AND easy to use. Thanks to the awesome [monero-javascript library of woodser](https://github.com/monero-ecosystem/monero-javascript) that now includes a Monero WASM wallet, we are able to offer just that. WASM or WebAssembly basically means that you are running a full Monero wallet _in your browser_. You are the only one controlling the keys, they never leave your system. _But_ we are able to create a nice userinterface, a dashboard with settings, and much more.
+
+Of course the details are of no concern to the normal user. The streamer simply navigates to tipxmr.live, clicks to create a new account and the WASM wallet will generate a XMR seed on the clients machine. The streamer writes down the seed and chooses a username.
+
+Then the streamer can log in using only their seed. We have a small database running on our server that checks the hash of the seed and logs the user in if it checks out. The streamer is then shown a dashboard where they have an overview of their usage. The dashboard also includes a wallet section where they can send/recieve XMR (for instance if they want to withdraw to a cold storage). Last but not least the streamer can change some settings, i.e. how donations should be displayed etc.
+
+Every steamer has their own animation URL that they can point an OBS browser source to. Donation messages are displayed there, so if the browser source in OBS is active, they will overlay over the stream.
+
+For donors the whole process is very easy as well: The streamer simply displays his donation URL (tipxmr.live/$username). Depending on the streamers configuration a donor can enter a message and their name. Once they hit "submit" the donors browser will query the streamers browser over our backend for a subaddress. Once the subaddress is payed the animation site of the streamer is refreshed and the message is displayed.
+
+Donors are shown the subaddress with XMR URI and the corresponding QR code to pay either via desktop or mobile wallet.
+
+Donations are accepted on a 0-conf basis, meaning they will be queued up to display once they are seen in the mempool.
+
+It is surprising _how easy paying with Monero actually is_. Much easier than paying with PayPal or a bank. Also, _way more private_ and cheaper.
+
+
+
+### Other awesome stuff
+
+Since monero is an internet-based technology, there are many cool things we can do. Here is a few thoughts:
+
+-   allow the streamer to specify a "second price". I.e. if the second costs 0.00043 XMR the donor can select how many seconds he wants his message to stay visible and then will be given a specific amount of XMR to donate
+-   allow the streamer to set a cost per character in the message, same procedure as with the second price for the donor
+-   upload custom sounds to be played when recieving a message
+-   allow donors to send gifs with their message, and demand a minimum amount for this feature from the donor
+-   have a funding goal that gets added to with every donation
+-   and much more...
+
+
+## How our projects benefits the Monero community
+
+-   Tipxmr.live strives to give one more usecase to Monero and do so natively without having to use another cryptocurrency.
+-   We enable streamers to _earn_ XMR - the best way to aquire Monero. Furthermore, like Dr. Daniel Kim always talks about tipxmr.live is a usecase for the squeaqy clean guy. In short a way to use Monero that has nothing to do with illegal activity. This lends legitimacy to Monero as a medium of exchange and gives one more example in the narrative for our fight to privacy.
+-   Community led streams such as Monero Coffee Chat, Monero Space, Monero Mumble and many more will have an easy way to monitize to cover costs and increase enagement from the community.
+-   Monero has low fees and pretty good privacy. However, the privacy increases with every transaction on the blockchain and makes a blackball attack much harder. Since all our donations are on-chain, we increase the number of decoys for everybody. Notice that we as a service do not store any on-chain information such as TX-Id. Don't believe us? Check the code.
+-   We are one of the first, if not the first project to make use of the Monero javascript WASM wallet, as such we serve as an example project for implementation that many others can copy and look to. This is actually a big deal for everybody that knows some webdevelopment but is not savy enough to configure Webpack with monero javascript and say, Reactjs. Been there, done that - you are welcome!
+-   All of our code is open source, of course. This means that you do not have to use tipxmr.live, you can fork the repo and setup your own service. We also encourage everybody to look through the codebase and raise issues when needed.
+- We aim for a high developer friendlyness so others can take our implementation and change it to their needs. The implementation of the WASM Wallet should be a good example for others.
+-   To sum it up, we increase the possiblities in the Monero universe for streamers, average users and developers.
+
+
+## What has been done so far
+
+Since we are very passionate about Monero and the idea, we already have a GitHub repo with some code in it. We started on this late August 2020 and have been working on it full time (70-80 hours per week in total). We can see that there is still much work to be done and in order to get some feedback and support ourselves we turn to the Community Crowdfunding System.
+
+
+## What we ask for
+
+We ask for 72 XMR (approx. 5400 EUR) in total. So far we have invested more than 250 hours and will take another 150 hours to complete the minimum viable product.
+
+The cost for this project is considerabely lower than it would be if we were not bleeding heart fans of Monero and our idea. We want to see the Monero Project grow and enable more usecases.
+
+The first two milestones will cover the work we have already done. Which is mainly setting up the Webpack configuration for Monero javascript and React. And then implementing functions of Monero javascript with the WASM wallet, backend to allow communication between streamer and client (using socket.io) and writing of wallet functions (i.e. sync, getSubaddress etc.).
+
+The third milestone is when the project is finished and the service will officially launch. This will happen within the year 2020.
+
+We will also provide a server to host the website, our own full node and proxy to solve to [CORS issue](https://github.com/monero-project/monero/issues/5172). 
+
+We also contemplate expanding on tipxmr.live and generating income that way. But please keep in mind that we are 100% open source and anybody can copy our idea and hard work.
+
+
+## Future Plans
+
+To be absolutely clear: Tipxmr.live will be a paid service!
+
+We host the website and allow streamers to have a comfortable experience in recieving live donations. To cover costs and to protect against spam of accounts, we will charge a small, flat fee (probably 1 USD worth of XMR per month) for our base model. From our experience with livestream donations this fee is negleable, since most streams will earn far more than the fee.
+
+We are also thinking of a higher fee for premium tier that allows for more customizations. The premium account will hopefully make our innovative business model sustainable and keep us improving the project.
+

tobtoht-2024Q1.md

+---
+layout: cp
+title: "tobtoht full-time feather + core development (3 months)"
+author: tobtoht
+date: 1 Jan 2024
+amount: 170
+milestones:
+  - name: 240 hours
+    funds: 50% (85)
+    done: 14 March 2024
+    status: finished
+  - name: 240 hours
+    funds: 50% (85)
+    done: 20 August 2024
+    status: finished
+payouts:
+  - date: 9 April 2024
+    amount: 85
+  - date: 4 September 2024
+    amount: 85
+---
+
+### What
+
+- work on issues/ideas reported by users
+- work on tasks listed on the [ideas](https://featherwallet.org/ideas/) page and [MAINTENANCE.md](https://github.com/feather-wallet/feather/blob/master/MAINTENANCE.md)
+- upstream useful patches to monero core
+- test and review pull requests (GUI/core)
+- help out where I can
+
+My primary focus for Q1 2024 is practical multisig UX.
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS: https://ccs.getmonero.org/proposals/tobtoht-feather-dev-2023-3.html
+
+### Proposal
+
+Work for 480 hours at a rate of €45/h + 0.05 XMR/h. At €148 / XMR (14 day EMA) this makes 170 XMR.

tobtoht-2024Q3.md

+---
+layout: cp
+title: "tobtoht full-time feather + core development (3 months)"
+author: tobtoht
+date: 20 Aug 2024
+amount: 179
+milestones:
+  - name: 240 hours
+    funds: 50% (89.5)
+    done: 8 Octoboer 2024
+    status: finished
+  - name: 240 hours
+    funds: 50% (89.5)
+    done: 20 December 2024
+    status: finished
+payouts:
+  - date: 15 October 2024
+    amount: 89.5
+  - date: 13 January 2025
+    amount: 89.5
+---
+
+### What
+
+- work on issues/ideas reported by users
+- [maintain](https://github.com/feather-wallet/feather/blob/master/MAINTENANCE.md) and [improve](https://featherwallet.org/ideas/) feather
+- upstream useful patches to monero core
+- test and review pull requests (GUI/core)
+- help out where I can
+
+My primary focus for this period will be [reproducible/bootstrappable fcmp++ builds](https://github.com/monero-project/monero/pull/9440) (core) and finishing work on [multisig support](https://github.com/feather-wallet/feather/commit/f944b6e6f78a29abe910b8f1d5d88b7c783553d6) (feather).
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/428
+
+### Proposal
+
+Work for 480 hours at a rate of €45/h + 0.05 XMR/h. At €139 / XMR (14 day EMA) this makes 179 XMR.
\ No newline at end of file

tobtoht-2025Q1.md

+---
+layout: wip
+title: "tobtoht full-time feather + core development (3 months)"
+author: tobtoht
+date: December 20, 2024
+amount: 150
+milestones:
+  - name: 240 hours
+    funds: 50% (75)
+    done: 2 February 2025
+    status: finished
+  - name: 240 hours
+    funds: 50% (75)
+    done:
+    status: unfinished
+payouts:
+  - date: 24 February 2025
+    amount: 75
+  - date:
+    amount:
+---
+
+### What
+
+- work on issues/ideas reported by users
+- [maintain](https://github.com/feather-wallet/feather/blob/master/MAINTENANCE.md) and [improve](https://featherwallet.org/ideas/) feather
+- [help maintain](https://github.com/monero-project/monero/pulls?q=is%3Apr+label%3A%22build+system%22+author%3Atobtoht) monero core's build system and CI
+- test and review pull requests (GUI/core)
+- upstream useful patches to monero core
+- help out where I can
+
+I want to start off the year by clearing out a good chunk of the small-to-medium size issue/feature backlog for Feather. At the same time, making sure [pending build system PRs](https://github.com/monero-project/monero/issues/9631) for Monero core get reviewed and merged, particularly everything we need for FCMP++. 
+
+After that, I want to continue efforts to add multisig support to Feather by evaluating kaya's FROST-inspired multisig implementation as a more robust replacement for wallet2's implementation. A related [audit](https://ccs.getmonero.org/proposals/monero-serai-wallet-audit.html) is expected to conclude in March.
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/492
+
+### Proposal
+
+Work for 480 hours at a rate of €50/h + 0.05 XMR/h. At €190 / XMR (14 day EMA) this makes 150 XMR.

tobtoht-feather-dev-2021-2.md

+---
+layout: cp
+title: "Continued Feather Wallet development (3 months)"
+author: tobtoht
+date: 12 May 2021
+amount: 91.5
+milestones:
+  - name: First month 
+    funds: 33% (30.5 XMR)
+    done: 16 June 2021
+    status: finished
+  - name: Second month
+    funds: 33% (30.5 XMR)
+    done: 11 July 2021
+    status: finished
+  - name: Third month
+    funds: 33% (30.5 XMR)
+    done: 30 October 2021
+    status: finished
+payouts:
+  - date: 21 June 2021
+    amount: 30.5
+  - date: 11 July 2021
+    amount: 30.5
+  - date: 1 November 2021
+    amount: 30.5
+---
+
+### What
+
+This CCS proposal is for 3 months of full time Feather Wallet development.
+
+The goal for this proposal is to get Feather out of Beta and release the 1.0 version.
+
+### Background
+
+See the previous [CCS proposal](https://ccs.getmonero.org/proposals/tobtoht_feather_dev_q1_2021.html).
+
+### What I want to work on
+
+To ensure the first major release is as stable, robust, and reliable as possible I will be mainly focussing my efforts on polishing the existing feature set (and extending it where needed).
+
+- Fix bugs and issues as they arrise
+- Further improve the UI/UX (layout, actionable error messages, etc)
+- Improve documentation and user guides
+- Add more compile flags for minimal/alternative builds: (no-Tor, no-Websocket, etc)
+- Refactor parts of the codebase
+- Allow compiling on more architectures
+- Extensive QA testing on all supported platforms
+- Commission a redesigned logo
+- Upstream changes to libwalletqt / wallet_api
+- Improve the setup procedure (Windows installer, Debian package on PPA, mac DMG)
+- More advanced coin control: manual input selection and individual output labeling
+- Extend hardware wallet support to include Trezor devices
+- Allow opening multiple wallets at once
+
+Once the is more clarity surrounding Triptych-compatible multisig (see [1](https://repo.getmonero.org/monero-project/ccs-proposals/-/blob/master/cypherstack-sarang-triptych-research.md), [2](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/225#note_10903)) I will continue working on integrating multisig into Feather.
+
+As always I will rely heavily on user feedback to determine where to put my focus.
+
+### Who
+
+Hi, I'm tobtoht. Creator of xmrguide and maintainer of Feather Wallet.
+I have been an active contributor to the Monero ecosystem since April 2018.
+
+Some of the things I have worked on are:
+
+- Created and maintained guides to set up Monero on Tails and Whonix ([xmrguide](http://xmrguide42y34onq.onion/), [reddit](https://old.reddit.com/r/Monero/comments/h8pbc2/))
+- Made miscellaneous contributors to the GUI (most notably Tails support)
+- Maintained a [list](http://xmrguide42y34onq.onion/remote_nodes) of .onion remote nodes with their status
+- Co-created Feather Wallet with dsc
+
+### Proposal
+
+40 hours per week at 45 USD/hour for 3 months (mid May to mid August) for a total of 91.5 XMR. At a rate of $236/XMR.
+
+Progress will be reported in #feather on OFTC. Monthly updates will be posted to /r/FeatherWallet in the form on release changelogs.
+
+Feedback and comments are welcome.
+
+**To donators**: In the week since I made this proposal there has been some very significant volatility, making it difficult to establish a "fair" XMR/USD price. As such I had to adjust the quoted price down several times because the difference had grown larger than my risk tolerance. I have currently settled on ${current_price} + 20%, in the expectation that the price will recover a bit after such a steep decline.
+
+To ensure I can sustain myself in the coming months AND the community gets its money's worth, I will extend the time spent on this proposal in case there is significant price appreciation over the next three months, like I did with my previous CCS (1.5 months overtime).

tobtoht-feather-dev-2021-3.md

+---
+layout: cp
+title: "Continued Feather Wallet development (3 months)"
+author: tobtoht
+date: 1 Nov 2021
+amount: 93
+milestones:
+  - name: First month 
+    funds: 33% (31 XMR)
+    done: 8 July 2022
+    status: finished
+  - name: Second month
+    funds: 33% (31 XMR)
+    done: 8 July 2022
+    status: finished
+  - name: Third month
+    funds: 33% (31 XMR)
+    done: 8 July 2022
+    status: finished
+payouts:
+  - date: 16 July 2022
+    amount: 93
+---
+
+### What
+
+This CCS proposal is for 3 months of full time Feather Wallet development.
+
+Non-exhaustive list of things I want to work on / towards or experiment with:
+
+- Prepare for next network upgrade
+- Translations
+- Persistent payment requests
+- Recurring payments
+- Reproducibe macOS builds
+- More transaction types (e.g. multi-destination transactions with manual input selection)
+- Improved wallet_api thread safety
+- Move to Qt6
+- Improving UI and documentation
+- Fix bugs and issues as they arrise
+
+I'll also:
+
+- Work on upstreaming patches to core
+- Help review pull requests on core / GUI where needed
+
+As always I will rely heavily on user feedback to determine where to put my focus.
+
+### Who
+
+Hi, I'm tobtoht. Creator of xmrguide and maintainer of Feather Wallet.
+I have been an active contributor to the Monero ecosystem since April 2018.
+
+Some of the things I have worked on are:
+
+- Worked on Feather Wallet full-time for ~1.5 years
+- Created and maintained guides to set up Monero on Tails and Whonix ([xmrguide](https://xmrguide.org), [reddit](https://old.reddit.com/r/Monero/comments/h8pbc2/))
+- Made miscellaneous contributors to the GUI (most notably Tails support)
+- Maintained a [list](http://xmrguide.org/remote_nodes) of .onion remote nodes with their status
+
+### Proposal
+
+Work 40 hours per week over the next 3 months (Nov, Dec, Jan) at a rate of 45 EUR/hour. At €232 / XMR (14 day EMA) this makes 93 XMR.
+
+Progress will be reported in #feather on OFTC. Updates will be posted to /r/FeatherWallet in the form on release changelogs.

tobtoht-feather-dev-2022-1.md

+---
+layout: cp
+title: "Continued Feather Wallet development (3 months)"
+author: tobtoht
+date: 20 Jul 2022
+amount: 162
+milestones:
+  - name: First month 
+    funds: 33% (54 XMR)
+    done: 9 January 2023
+    status: finished
+  - name: Second month
+    funds: 33% (54 XMR)
+    done: 9 January 2023
+    status: finished
+  - name: Third month
+    funds: 33% (54 XMR)
+    done: 13 Februrary 2023
+    status: finished
+payouts:
+  - date: 9 January 2023
+    amount: 108
+  - date: 16 February 2023
+    amount: 54
+---
+
+### What
+
+This CCS proposal is for 3 months of full time Feather Wallet development.
+
+Non-exhaustive list of things I want to work on/towards or experiment with:
+
+- Bootstrappable builds
+  - Leverage [Guix](https://github.com/bitcoin/bitcoin/tree/master/contrib/guix) to produce cross-compiled, reproducible, [bootstrappable](https://bootstrappable.org/) builds for all target platforms and operating systems. Most of the work for this is already [done](https://github.com/feather-wallet/feather/pull/20). This has the added benefit of greatly speeding up release engineering, allowing for quicker release cycles.
+
+- Offline transaction signing using animated QR codes
+  - Export/import outputs, key images and transactions using animated QR Codes based on Blockchain Common's [Uniform Resources](https://github.com/BlockchainCommons/bc-ur).
+  - Work with the [Keystone](https://keyst.one/) team to add support for Monero and integrate with Feather.
+
+- Multi-node syncing (experiment)
+  - Syncing a month worth of blocks now requires more than 300 MB of data. Wallet synchronization (when connected to a remote node) is often limited by one of two things: your download speed or a node's upload speed (for mobile devices your CPU might play a role too). Multi-node syncing will experimentally determine the fastest nodes from your node list and automatically gather blocks from the highest performing nodes to utilize as much of your available bandwidth as possible. If you are on a fast internet connection this can result in dramatically faster syncing.
+
+- Allow skipping synchronization
+  - POV: You just opened your wallet on Tails after leaving it unopened for 3 months. You proceed to wait an hour or more for your wallet to synchronize knowing that there has been no activity. An advanced option to skip synchronization will eliminate the wait and allow you to send transactions almost immediately.
+
+- Improve Tor support and add support for more anonymity networks
+  - Add support for Tor bridges and stream isolation
+  - Switch the Tor client implementation to [Arti](https://blog.torproject.org/announcing-arti/) (when it is ready)
+  - Remove the hard dependency on Tor and allow Feather to be used without anonymity networks
+  - Modularize the anonymity network code to make it possible to integrate other networks like I2P and [Nym](https://github.com/nymtech/nym).
+
+- Mining interface overhaul (+ P2Pool support)
+  - The Mining tab is a bit crude. Mining is [not trivial](https://docs.featherwallet.org/guides/mining-setup) to set-up for new users, and it lacks configurability for advanced users. It's currently not possible to mine without having a wallet open. I want to move the Mining tab to a utility that can be accessed via the taskbar icon. Users should be able to quickly setup P2Pool, solo and pool mining. Feather will be able to run in the background and allow users configure scheduled mining, as well as provide a dashboard where users can check their mining stats and make changes to the configuration.
+
+- Improve packaging for Linux distributions
+  - Make Feather available as a Flatpak, Debian package, and maintain a working -bin package on the AUR. I also want to work on documentation that will help maintainers package Feather for their distribution.
+
+- Support more ways of spending Monero
+  - The libwallet interface lacks support for various advanced ways of spending Monero. The current Feather release added manual input selection. More is still desired, such as multi-destination sweeps or spends with an alternative change address.
+
+- Improved documenatation
+  - I'm already quite happy with the [documentation](https://docs.featherwallet.org/) in it's current state, but there is still room for improvement. A search feature is lacking and some parts could be improved with screenshots. Other parts can be rewritten to improve clarity and a glossary would be a welcome addition. I also want to add a section that goes in depth about threat-modeling to help users make more informed decisions about how they should use and configure the program to address their specific privacy or security concerns.
+
+- Fix bugs and issues as they arise
+
+I'll also work on reviewing contributions to CLI / GUI where I can and work on upstreaming patches to core.
+
+As always I will heavily prioritize user feedback when deciding what to focus on.
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS proposals:
+
+- https://ccs.getmonero.org/proposals/tobtoht-feather-dev-2021-3.html
+- https://ccs.getmonero.org/proposals/tobtoht-feather-dev-2021-2.html
+- https://ccs.getmonero.org/proposals/tobtoht_feather_dev_q1_2021.html
+- https://ccs.getmonero.org/proposals/feather-2020.html
+
+### Proposal
+
+Work 40 hours per week over the next 3 months at a rate of €45 / hour. At €133 / XMR (14 day EMA) this makes 162 XMR.

tobtoht-feather-dev-2023-1.md

+---
+layout: cp
+title: "Continued Feather Wallet development (3 months)"
+author: tobtoht
+date: 15 Feb 2022
+amount: 142
+milestones:
+  - name: First month 
+    funds: 33% (47 XMR)
+    done: 17 April 2023
+    status: finished
+  - name: Second month
+    funds: 33% (47 XMR)
+    done: 5 June 2023
+    status: finished
+  - name: Third month
+    funds: 33% (48 XMR)
+    done: 20 July 2023
+    status: finished
+payouts:
+  - date: 10 May 2023
+    amount: 47
+  - date: 9 June 2023
+    amount: 47
+  - date: 26 July 2023
+    amount: 48
+---
+
+This proposal is for 3 months of full time Feather Wallet development.
+
+### What
+
+- work on issues/ideas reported by users
+- work on tasks listed on the [ideas](https://featherwallet.org/ideas/) page
+- upstream useful patches to monero core
+- test and review pull requests (GUI/core)
+- help out where I can
+
+As always, I heavily prioritize user feedback when deciding what to focus on.
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS: https://ccs.getmonero.org/proposals/tobtoht-feather-dev-2022-1.html
+
+Progress updates are posted to #feather:monero.social and /r/FeatherWallet.
+
+### Proposal:
+
+Work for 40 hours per week for the next 3 months at a rate of €45/h. At €152 / XMR (14 day EMA) this makes 142 XMR.

tobtoht-feather-dev-2023-3.md

+---
+layout: cp
+title: "Continued Feather Wallet development (3 months)"
+author: tobtoht
+date: 20 Jul 2023
+amount: 146
+milestones:
+  - name: First month 
+    funds: 33% (48.6 XMR)
+    done: 19 October 2023
+    status: finished
+  - name: Second month
+    funds: 33% (48.6 XMR)
+    done: 9 December 2023
+    status: finished
+  - name: Third month
+    funds: 33% (48.7 XMR)
+    done: 2 January 2024
+    status: finished
+payouts:
+  - date: 5 November 2023
+    amount: 48.6
+  - date: 5 January 2024
+    amount: 97.3
+---
+
+
+This proposal is for 3 months of full time Feather Wallet development.
+
+### What
+
+- work on issues/ideas reported by users
+- work on tasks listed on the [ideas](https://featherwallet.org/ideas/) page and [MAINTENANCE.md](https://github.com/feather-wallet/feather/blob/master/MAINTENANCE.md)
+- upstream useful patches to monero core
+- test and review pull requests (GUI/core)
+- help out where I can
+
+As always, I heavily prioritize user feedback when deciding what to focus on.
+
+### Who
+
+Hi, I'm tobtoht. I am an active contributor to the Monero ecosystem since April 2018. Currently, I maintain Feather Wallet and contribute to the core codebase.
+
+Previous CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/376
+
+Progress updates are posted to #feather:monero.social and /r/FeatherWallet.
+
+### Proposal:
+
+Work for 40 hours per week for the next 3 months at a rate of €45/h. At €148 / XMR (14 day EMA) this makes 146 XMR.

tobtoht_feather_dev_q1_2021.md

+---
+layout: cp
+title: "Continued Feather Wallet development (Q1 2021)"
+author: tobtoht
+date: 4 January 2021
+amount: 150
+milestones:
+  - name: First month 
+    funds: 33% (50 XMR)
+    done: 8 February 2021
+    status: finished
+  - name: Second month
+    funds: 33% (50 XMR)
+    done: 24 March 2021
+    status: finished
+  - name: Third month
+    funds: 33% (50 XMR)
+    done: 5 May 2021
+    status: finished
+payouts:
+  - date: 11 February 2021
+    amount: 50
+  - date: 24 March 2021
+    amount: 42.5
+  - date: 29 March 2021
+    amount: 15
+  - date: 6 May 2021
+    amount: 42.5
+---
+
+### What
+
+This CCS proposal is for 3 months of full time Feather Wallet development.
+
+The goal of this proposal is to:
+
+- Reach feature-parity with the GUI (this mostly concerns hardware wallet support)
+- Further advance the Monero desktop wallet space by implementing new (and experimental) features.
+
+### Background
+
+- Feather was [announced](https://old.reddit.com/r/Monero/comments/idujx0/feather_free_opensource_monero_desktop_wallet/) on Aug 21 2020. 
+- A CCS [proposal](https://ccs.getmonero.org/proposals/feather-2020.html) funding the initial stages of development was accepted on September 1. 
+- The first alpha builds became [available](https://old.reddit.com/r/Monero/comments/j8kn8e/feather_a_brand_new_monero_gui_desktop_wallet/) on Oct 10. 
+- During the alpha time was spent on:
+    - Troubleshooting teething problems
+    - Bugfixes and performance improvements
+    - Getting the websites and build infrastructure up and running
+- The first beta builds were [announced](https://old.reddit.com/r/FeatherWallet/comments/kdmj3b/feather_beta2_released/) on Dec 15.
+    - The beta introduced signed release binaries.
+    - The focus for the beta was to fix the remaining UI/UX issues before adding new features. This is now mostly complete.
+    - A total of 211 pull requests (171 made by me) were submitted to the repository since the alpha release.
+- Some features that were added between the previous CCS proposal and now are: Windows support, view-only wallets, offline transaction signing, advanced transaction overview ([image](https://featherwallet.org/theme/img/feather_send_advanced.png)), transaction rebroadcasting, XMRig integration and reproducible Linux builds. Reproducible builds are mostly thanks to work done by Xiphon on the GUI.
+
+### What I want to work on
+
+- Hardware wallet support (most requested feature, so this is definitely happening now)
+- More exchange integrations (among which LocalMonero)
+- More advanced coin control features: manual input selection and individual output labeling
+- An in-wallet troubleshooting wizard that detects and suggests fixes for common issues ([example](https://git.wownero.com/feather/feather/issues/144))
+- Easy to use 2/2, 2/3 multisig (work on the message transportation layer and UI/UX design can commence before it is clear what changes Triptych/Arcturus will bring to multisig)
+- Qr scanner (scan addresses with laptop camera/webcam)
+- Multi destination transactions
+- Debian package
+- Sync over clearnet, construct & broadcast transactions over Tor
+- Approach the Tails team to discuss potential inclusion of Feather Wallet by default
+- Further UI/UX improvements (including more actionable error messages, better UI feedback)
+- Upstreaming of changes to libwalletqt / wallet_api
+- (Separate from Feather): Monero Daemon as a system service ([more info](https://git.wownero.com/feather/feather-meta/issues/3))
+
+This is a non-exhaustive list of some of the things I want to work on during the proposal.
+I expect the majority of the items on this list to be completed at the end of the 3-month period (with the exception of multisig, which will likely take longer).
+As always I will rely heavily on user feedback to determine where to put my focus.
+
+### Why contribute to Feather development?
+
+- It is an excellent testing grounds for features that may later be implemented in the official GUI (14 word seeds, coin control, multisig, etc)
+- There is more room to experiment with UI/UX and features and see what works before committing to it in a reference wallet.
+- Some users cite its simplicity, focus on user experience, quick setup, addition of power user features and similarity to Electrum as reasons they prefer it over the GUI
+- Feather will remain open source and licensed under BSD-3.
+
+### Who
+
+Hi, I'm tobtoht. Creator of xmrguide and maintainer of Feather Wallet.
+I have been an active contributor to the Monero ecosystem since April 2018.
+
+Some of the things I have worked on are:
+
+- Created and maintained guides to set up Monero on Tails and Whonix ([xmrguide](http://xmrguide42y34onq.onion/), [reddit](https://old.reddit.com/r/Monero/comments/h8pbc2/))
+- Made miscellaneous contributors to the GUI (most notably Tails support)
+- Maintained a [list](http://xmrguide42y34onq.onion/remote_nodes) of .onion remote nodes with their status
+- Created various Python [scripts](http://xmrguide42y34onq.onion/scripts) to convert from/to Monero using third party exchangers
+- Co-created Feather Wallet with dsc
+
+### Proposal
+
+40 hours per week at 45 USD/hour for a total of 150 XMR. The XMR/USD rate is based on current exchange rate of $144 XMR/USD.
+
+This will cover January/February/March. Any hours left over will bleed into April.
+
+Progress will be reported in #feather on OFTC. Bi-monthly updates will be posted to /r/FeatherWallet in the form on release changelogs.
+
+Feedback and comments are welcome.

txstreet-2021.md

+---
+layout: cp
+title: Add Monero to TxStreet
+author: txstreet
+date: March 10, 2021
+amount: 38
+milestones:
+  - name: Monero street complete and live
+    funds: 20
+    done: 20 April 2021
+    status: finished
+  - name: Advertising for 3 months
+    funds: 4.5
+    done: 2021
+    status: unfinished
+  - name: Advertising for 6 months
+    funds: 4.5
+    done: 2021
+    status: unfinished
+  - name: Advertising for 9 months
+    funds: 4.5
+    done: 24 October 2022
+    status: finished
+  - name: Advertising for 12 months
+    funds: 4.5
+    done: 24 October 2022
+    status: finished
+payouts:
+  - date: 22 April 2021
+    amount: 20
+  - date: 16 January 2022
+    amount: 9
+  - date: 4 November 2022
+    amount: 9
+---
+​
+Hello! My name is Tom and I run txstreet.com. (Proof - http://out.txstreet.com/getmonero). I was recommended the CCS by a member of the Monero community to fund the addition of Monero to TxStreet. Because the website remains closed source for now, this proposal will be framed as an advertising campaign.
+​
+
+I have reduced the funding to the minimum amount of what I think is necessary for Monero to remain operational on the website. I do not want to make any profit off of the CCS.
+​
+# What is TxStreet?
+TxStreet.com is a live cryptocurrency transaction visualizer featuring Bitcoin, Ethereum and Bitcoin Cash. When a new transaction is broadcasted to a cryptocurrency, a person appears and attempts to board a bus. If the transaction has a high enough fee, they will board the first bus and be ready to be included in the next mined block. If there are too many transactions to be included in the next block, and the transaction didn't pay a high enough fee, the person will either wait in line or board a different bus. Consecutive buses will appear when there are enough transactions to fill them.
+​
+
+TxStreet has become popular in other crypto communites, here are some examples of people talking about it:
+- https://twitter.com/VitalikButerin/status/1299892964160749570
+- https://twitter.com/peter_szilagyi/status/1287699988882087938
+- https://twitter.com/rogerkver/status/1362183459377188867
+​
+
+Traffic estimate is 200k - 300k unique visitors per month based off of fathom showing 110k UV in the last month and cloudflare showing 650k UV in the last month. Fathom can be blocked client side by adblockers and cloudflare includes traffic from bots, which is why there is a large discrepancy.
+
+Twitter - https://twitter.com/txstreetCom
+​
+# How Monero will be presented
+Monero will have it's own street just like the other supported coins.
+​
+Live stats that will be shown:
+- Broadcasted Tx/Sec (Past 5 mins)
+- Confirmed Tx/Sec (Past hour)
+- Mempool Size (Bytes)
+- Mempool Count
+- Median Fee (USD)
+- Median Fee (Atomic units per byte)
+- Bytes/Second (Past 5 mins)
+- Ciruclating Supply
+- Price (USD)
+- Last Block
+- Median Txs Per Block (Past Hour)
+- Blockchain Size
+- Difficulty
+- Block Size Limit (Current)
+- Median Block Size (Past Hour)
+- Average Block Time (Past 250 Blocks)
+- Market Cap (USD)
+- 24 Hour Volume (USD)
+​
+
+The coins that TxStreet currently supports have no privacy by default, so it is possible to parse the data from transactions and categorize them into "houses". Since Monero has strong privacy and all of the information from each transaction is hidden (besides fee, size etc.), there will be no need for the houses and that section can be removed completely. Or if the community prefers, it can be replaced with something else.
+​
+
+To further convey the message of privacy, every "person" (transaction) will be an identical sprite. I have been suggested "Monero Memeball" or "Isabella Monero Girl" for the sprite. Initially I wanted to do a black trench coat, but was informed that there is a stigma towards that. The final decision will be "Monero Memeball" unless the community has feedback on this.
+Monero Memeball: https://i.imgur.com/WgsAgXm.jpg
+​
+
+When completed, the Monero street will be viewable here: https://txstreet.com/v/xmr
+Alongside bitcoin, it will be viewable here: https://txstreet.com/v/xmr-btc
+​
+
+To get to the Monero street, users can click the dropdown in the top left/right of other streets. For the first month, a large notification will show once for each user saying "New Street! View Monero".
+​
+# Cost breakdown
+​
+## Milestone 1 - Monero street complete and live
+20 XMR. I estimate it will take 1-2 months to complete. 
+​
+## Milestones 2-5 - Additional 3 months of advertising
+2.5 XMR  for server costs. ($120/month base estimate)
+
+2 XMR for maintenance.
+​
+
+This proposal is for 1 year of advertising. After 1 year, another proposal will be submitted for additional funding. If funding is not met, the operational costs of the Monero street will have to be paid for by me and the Monero street will be subject to removal if I can't cover those costs.

unstoppableswap-gui-2.md

+---
+layout: cp
+title: "XMR BTC Atomic Swaps Desktop GUI - Continued development for 4 months"
+author: binarybaron
+date: 26 May, 2022
+amount: 232
+milestones:
+  - name: July
+    funds: 58
+    done: 10 August 2022
+    status: finished
+  - name: August
+    funds: 58
+    done: 2 November 2022
+    status: finished
+  - name: September
+    funds: 58
+    done: 9 December 2022
+    status: finished
+  - name: October
+    funds: 58
+    done: 16 January 2023
+    status: finished
+payouts:
+  - date: 23 August 2022
+    amount: 58
+  - date: 4 November 2022
+    amount: 58
+  - date: 20 December 2022
+    amount: 58
+  - date: 23 January 2023
+    amount: 58
+---
+
+![](https://user-images.githubusercontent.com/86064887/152649852-4c8c6c3f-0568-4347-89d1-c291c17f2d30.png)
+![](https://user-images.githubusercontent.com/86064887/152678743-b86f395e-01dc-43c5-ba71-b27962a4a6ba.png)
+![](https://user-images.githubusercontent.com/86064887/152649633-9ae29f79-8041-476c-be45-ef3441f4dee1.png)
+
+We've successfully completed all of the goals we set for ourselves in our [first CCS proposal](https://ccs.getmonero.org/proposals/binarybaron-unstoppableswap.html). The prototype of the GUI we wanted to develop is fully functional (on testnet) and it will soon replace the now obsolete web interface ([UnstoppableSwap.net](https://unstoppableswap.net)).
+Based on the community response to both of our status updates ([reddit post 1](https://www.reddit.com/r/Monero/comments/slvy2a/making_atomic_swaps_accessible_to_all/), [reddit post 2](https://www.reddit.com/r/Monero/comments/uawipv/atomic_swap_gui_demo_on_mainnet_unstoppableswap/)), we felt that there is a strong desire in the community for us to continue development.
+
+Over the course of 7 months we have:
+
+- Made over **175 commits** to the [UnstoppableSwap GUI repository](https://github.com/UnstoppableSwap/unstoppableswap-gui/commits/main) and developed an initial working prototype.
+    - [Demo video of mainnet swap](https://www.youtube.com/watch?v=8XLGSsggnP0)
+    - [Demo video of decentralized peer discover](https://www.youtube.com/watch?v=MvUsjU67jf0)
+- I’ve become one of the three unpaid volunteers maintaining the [xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap/) repository after the comit guys (original developers who developed the first MVP) have moved on to other projects. I’ve submitted and merged [12 Pull Requests](https://github.com/comit-network/xmr-btc-swap/pulls?q=is%3Apr+is%3Amerged+author%3Abinarybaron+) over the last months and reviewed some more.
+
+### Proposal:
+
+We are excited to keep working on Atomic Swaps. There are still loads of things needed to make it accessible and easy to use for everyone. Therefore we'd like to continue spending our time working on the FOSS GUI for BTC<>XMR Atomic Swaps. It is being built around the *[swap-cli](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)* and will empower even non-technical people to swap their BTC for XMR in a safe, decentralized and trustless manner. We are asking for 232 XMR for continued development for 4 months. At the end of each month 37 XMR will be paid out. We will work approximately 25 hours per week for 4 months straight which amounts to 400 hours of labour. Our hourly rate is 66 USD which amounts to 232 XMR at a current price of 112 XMR/USD
+
+### Who:
+I am binarybaron, the creator of UnstoppableSwap.net and Monero enthusiast. I was excited about Atomic Swaps from the very beginning, tested the first versions (MVP developed by COMIT guys) and contributed to the project early on. When the first testnet swap provider came online, I realized that we would need a better user interface and a platform to compare different swap providers. I decided to start building UnstoppableSwap.net. To my surprise, the interest was much greater than I could have ever predicted. In the first week alone, the website was visited more than 150,000 times. 
+Once I realized that a website was not enough due to the technical requirements, I started working on a desktop app. Soon after, I submitted my first CCS, which was quickly funded, and developed the first working prototype of the desktop user interface.
+
+### **What:**
+
+1. Development of the graphical user interface (*[GUI](https://github.com/UnstoppableSwap/unstoppableswap-gui)*)
+    1. **Auto Update**. For this to work we’ll need to code sign the releases on Mac OS using a paid certificate. The *GUI* will download and install the new version on startup if a new release is available. 
+    2. **Educate users on the rules of the swap protocol.** There are some simple but important rules all users need to follow to avoid loosing funds. Most importantly the functionality of the cancel and refund timelocks must be understood. If users are not fully aware on how to act in certain scenarios, **they risk loosing funds**. We’re not yet sure how to proceed on this. Some ideas are outlined below:
+        1. Quiz at first start-up to make sure the user understands what rules he needs to follow
+        2. Refer to official documentation of the *[swap-cli](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)* and the GUI
+        3. Refer to blog posts, videos and other online resources by the community
+    3. **Allow manual cancel & refund of swaps.** Although the *[swap-cli](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)* should refund swaps automatically in most cases, there are some edge cases where the user is required to cancel & refund manually. This is currently not possible in the GUI. Enabling the user to easily do this in the GUI is a must.
+    4. **Unit and Integration tests.** Although the *GUI* is relatively stable, it has pretty low test coverage. We need to create a lot more unit and possibly integration tests to cover all edge cases. Especially critical code like the internal finite state machine needs extensive test coverage.
+    5. **New Icon**. The current icon was only meant to be a placeholder and wasn’t intended to be final. We’ll either commision someone to make a new one or ask the community for input.
+    6. **Performance improvements.** We need to investigate what the performance bottlenecks of the *GUI* are. The most obvious ones at the moment are:
+        1. Inefficient SQL queries being used for querying the swap database
+        2. Overly-cautious file reads of the swap database
+        3. Unnecessary re-renders of React components
+        4. Blocking code being run in the main thread leading to freezing of the whole application
+    7. **General improvement of the GUI**. Fixing bugs, responding to issues, writing documentation and implementing new features as they come to mind.
+    8. **Switch the GUI from Testnet to Mainnet.** The GUI is currently Testnet only. Once we feel it is stable enough overall we’ll switch it over to Mainnet.
+2. **Development and maintenance of the API that enables clients to easily discover swap providers.** A swap provider is a peer you can connect with to exchange your BTC for XMR. ****Our API indexes them and provides additional data such as their uptime and their age. This API is publicly accessible and can be used by other services (e.g orangefren.com). We provide an HTTP(s) and a WebSocket (socket.io) endpoint which will be documented on UnstoppableSwap.net.
+3. **Development and maintenance of the UnstoppableSwap.net site.** It was the first initial prototype for a user interface for Atomic Swaps. It used to be a very stripped down version of the GUI and allowed users to more easily initiate a swap using the *[swap-cli](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)* by displaying them with a command they could copy and paste. This was not ideal, as it gave the impression of being user-friendly, but could be quite confusing and risky to use. The site will be converted into a simple download page for the *GUI* (similar to bisq.network)
+4. **Maintenance of rendezvous point.** There are currently three major ways for users to discover swap providers (peers they can swap their Bitcoin for Monero with). This proposal also includes the maintenance of the rendezvous point we run.
+    1. Word-of-mouth: The community can share the address of swap providers online (e.g on Reddit, IRC, Matrix..)
+    2. Centralized peer discovery via UnstoppableSwap API: We actively maintain a database of swap providers which can be used by anyone to retrieve a list of swap providers
+    3. Rendezvous point: The [rendezvous](https://github.com/libp2p/specs/blob/master/rendezvous/README.md) protocol is a lightweight mechanism for generalized peer discovery. It allows for the discovery of peers in a decentralized fashion. We operate a community rendezvous point through which swap providers can make themselves known to users, and through which users can find swap providers with whom they want to swap.(`/dns4/discover.unstoppableswap.net/tcp/8888/p2p/12D3KooWA6cnqJpVnreBVnoro8midDL9Lpzmg8oJPoAGi7YYaamE`)
+5. **Reviewing, merging and possibly submitting Pull Requests to the [xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap/) repository.**
+    1. This proposal is mainly for continued development of the GUI and not for maintenance of the xmr-btc-swap project. **Time spent on the [repository](https://github.com/comit-network/xmr-btc-swap/) will at most be 5% of the total time spent on this proposal.**
+    2. Most of the Pull Requests we’ll submit will be related to making the *[swap-cli](https://github.com/comit-network/xmr-btc-swap/blob/master/docs/cli/README.md)* compatible with the *GUI*
+    
+
+If funded we'll provide monthly updates in the CCS comment section.

utxobr-monero-k8s-operator.md

+---
+layout: wip
+title: Monero Kubernetes Operator
+author: Ciro S. Costa (utxobr)
+date: May 3, 2021
+amount: 22.86
+milestones:
+  - name: Proof of concept
+    funds: 0
+    done: 02 May 2021
+    status: finished
+  - name: Prototype refactoring, installation improvements and docs
+    funds: 2.47
+    done:
+    status: unfinished
+  - name: Support annonimity networks
+    funds: 3.71
+    done:
+    status: unfinished
+  - name: Improve observability of nodes
+    funds: 3.71
+    done:
+    status: unfinished
+payouts:
+  - date:
+    amount:
+  - date:
+    amount:
+  - date:
+    amount:
+---
+
+
+## Brief Intro
+
+My name is Ciro S. Costa (https://github.com/cirocosta,
+https://twitter.com/utxobr), I'm currently a staff engineer, having previously
+being a core contributor to https://concourse-ci.org.
+
+Monero-wise, I've been mostly focused on the networking side of it, having
+implemented the basics of Levin's handshake in Go
+(https://github.com/cirocosta/go-monero) with full support for the
+Portablestorage format, which lets me create some interesting reports on node
+distribution (see https://twitter.com/utxobr/status/1386458317405540360) by
+crawling the P2P network.
+
+
+## Problem
+
+_**tl;dr**: there's no good solution for running a large number of monero
+nodes_
+
+For those with more than a machine or two to run Monero nodes (or even miners),
+there's not a good solution out there for having those up and running in an
+easy to upgrade fashion.
+
+It's great that folks like Seth provide wonderful guides on how to run Monero
+nodes (see https://sethsimmons.me/guides/run-a-monero-node-advanced/), and that
+within the functional tests in the codebase we can tell how to run regtest, but
+none of that helps with running a larger-scale setup.
+
+
+## Proposal
+
+_**tl;dr**: extend the Kubernetes API via its common extension system to provide
+semantics that make deploying clusters of monero nodes or miners with ease. See
+proof of concept at https://github.com/cirocosta/monero-operator_
+
+Kubernetes (see [what is kubernetes]) provides us with this vendor-neutral API
+for expressing what the desired state should be, and then behind the scenes,
+having that state achieved (and maintained) through the use of small
+programs whose whole job is to deal with going from current state to desired state.
+
+Aside from being offered by pretty much every cloud provider (and many VPS
+offerings out there too) and still remaining not vendor-specific, its API is
+open for extension, which we can leverage to provide extra functionality that
+it didn't have before.
+
+By extending the Kubernetes API via the use of [Custom Resources], we're able
+to provide a new semantics for the users of those clusters so that we simplify
+*a lot* running, say a few Monero nodes all configured the same across
+different machines
+
+
+```yaml
+kind: MoneroNodeSet
+apiVersion: utxo.com.br/v1alpha1
+metadata:
+  name: nodes
+spec:
+  replicas: 3
+  hardAntiAffinity: true
+  monerod:
+    image: utxobr/monerod:v0.17.2.0     # if testing a release candidate,  then
+    args:                               # just bump the image and the operator
+      - --public                        # will take care of rolling out, preserving
+      - --enable-dns-blocklist          # the data already synced.
+      - --enforce-dns-checkpointing
+      - --out-peers=1024
+      - --in-peers=1024
+      - --limit-rate=128000
+```
+
+which could be very useful for businesses like CakeWallet that run sets of full
+nodes (or literally anyone wanting to run highly-available monerod
+deployments), but it can be also useful for folks doing research like me,
+wanting to roll out a regtest network with many peers:
+
+```yaml
+kind: MoneroNetwork
+apiVersion: utxo.com.br/v1alpha1
+metadata:
+  name: regtest
+spec:
+  replicas: 20
+
+  template:
+    spec:
+      monerod:
+        args:                           # each replica has these args
+          - --regtest                   # plus `--add-exclusive-node`
+          - --fixed-difficulty=1        # pointing just at the other
+                                        # peers, forming a closed net
+```
+
+_(^ which under the hood gets materialized in the form of `monerod` instances
+pointing one at each other, with volumes attached and everything you'd want for
+a real setup.)_
+
+Naturally, we can do the same for miners, for instance, we can get to run 10
+replicas of `xmrig` against a pool like so:
+
+```yaml
+kind: MoneroMiningNodeSet
+apiVersion: utxo.com.br/v1alpha1
+metadata:
+  name: miners
+spec:
+  replicas: 10
+  hardAntiAffinity: true
+
+  xmrig:
+    args:
+      - -o
+      - cryptonote.social:5556
+      - -u
+      - 891B5keCnwXN14hA9FoAzGFtaWmcuLjTDT5aRTp65juBLkbNpEhLNfgcBn6aWdGuBqBnSThqMPsGRjWVQadCrhoAT6CnSL3.node-$(id)
+      - --tls
+```
+
+and then, if we regret chosing that pool, all it takes is patching the object
+and under the hood, our extension to Kubernetes takes care of rolling the
+updates out.
+
+_(aside: couple this with [horizontal pod autoscaler (HPA)] and you don't even
+need to pre-provision any underlying machines - if your provider supports HPA -
+as by making use of proper resource reservation, asking for extra replicas
+would trigger the creation of new machines)._
+
+
+[what is kubernetes]: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes
+[Custom Resources]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources
+[horizontal pod autoscaler (HPA)]: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
+[OpenMetrics]: https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md
+[Prometheus]: https://prometheus.io/
+
+
+## The scope
+
+I currently have a working proof of concept
+(https://github.com/cirocosta/monero-operator) that implements those three
+custom resources mentioned above (`MoneroMiningNodeSet`, `MoneroNodeSet`, and
+`MoneroNetwork`).
+
+This CCS would cover:
+
+1. boosting the confidence in the codebase by providing more tests to cover
+   edge cases glanced over while building the prototype, as well as improving
+   installation and documentation as a whole
+
+2. adding support for Tor and I2P so that nodes and networks can be deployed on
+  annonimity networks with a line or two in the yaml while still running the
+  services with high availability
+
+3. improving the observability of the deployed `monerod` instances introducing a
+  sidecar to expose `monerod` metrics for any [OpenMetrics] consumer (like
+  [Prometheus])
+
+
+As a result, the community will end up with:
+
+- a Kubernetes extension that lets anyone deploy highly-available `monerod`
+  (and miners) on any Kubernetes-enabled platform
+
+- a Go package that they can rely on for interacting with `monerod`
+
+
+## The structure, milestones, and price.
+
+Working on this during my personal hours, I plan to do the work a few hours a
+day on the side (with a few healthy periods of break) until completion.
+
+The proposal is structured to be paid along with the delivery of the three points above:
+
+1. confidence in the codebase + installation/doc guides: ~10Hr
+2. support for Tor and I2P for full nodes and whole networks: ~15Hr
+3. observability of `monerod`: ~15Hr
+
+Assuming a rate of 100$/hr and a current rate of 404 USD/xmr (May 3rd, 2021):
+
+| deliverable | hours | usd | xmr |
+|-----|------|-----|-----|
+| 1 | 10 | $ 1000 | XMR 2.47 |
+| 2 | 15 | $ 1500 | XMR 3.71 |
+| 3 | 15 | $ 1500 | XMR 3.71 |
+

v1docq47-monerokon-and-monerotopia-voiceover-and-working-on-xmr.ru.md

+---
+layout: cp
+title: v1docq47 - monerokon and monerotopia voiceover and working on xmr.ru
+author: v1docq47
+date: March 31, 2023
+amount: 42.8
+milestones:
+  - name: October
+    funds: 16.66% (7.13 XMR)
+    done: October 31, 2022
+    status: finished
+  - name: November
+    funds: 16.66% (7.13 XMR)
+    done: November 30, 2022
+    status: finished
+  - name: December
+    funds: 16.66% (7.13 XMR)
+    done: December 31, 2022
+    status: finished
+  - name: January
+    funds: 16.66% (7.13 XMR)
+    done: January 31, 2023
+    status: finished
+  - name: February
+    funds: 16.66% (7.13 XMR)
+    done: February 28, 2023
+    status: finished
+  - name: March
+    funds: 16.66% (7.13 XMR)
+    done: March 31, 2023
+    status: finished
+payouts:
+  - date: 4 November 2022
+    amount: 7.13
+  - date: 9 December 2022
+    amount: 7.13
+  - date: 5 January 2023
+    amount: 7.13
+  - date: 2 February 2023
+    amount: 7.13
+  - date: 6 March 2023
+    amount: 7.13
+  - date: 3 April 2023
+    amount: 7.13
+---
+
+_Note: Overfunding of 0.050719957895 XMR from this proposal has been awarded to [v1docq47 2024](https://ccs.getmonero.org/proposals/v1docq47-monerotopia-2024-voiceovers-and-working-on-xmr.ru.html)_
+
+# Introduction
+
+Due to [disallow on posting new CCS to translate](https://github.com/monero-project/meta/issues/732) on ccs.getmonero.org, I redid [my previous CCS proposal](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/329) and removed the translate part of the work.
+
+# Who I Am?
+
+I am [v1docq47](https://github.com/v1docq47), active contributor [Monero Localization](https://translate.getmonero.org/user/v1docq47/) and [Monero Outreach](https://github.com/monero-ecosystem/outreach-docs/pulls?q=is%3Apr+is%3Aclosed+v1docq47) workgroups.  
+[More than 5 years](https://github.com/pulls?q=is%3Apr+author%3Av1docq47+archived%3Afalse+is%3Aclosed+sort%3Acreated-asc) I have been translating into Russian. Also, I am a [moderator, designer and developer](https://github.com/xmr-ru/xmr_ru/commits/main) of the largest news and information website about Monero in the Russian-speaking segment - [XMR.RU](https://xmr.ru/) and [Unofficial Russian technical documentation for Monero](https://wiki.xmr.ru/).  
+Also I and my wife doing Russian voiceover and creating various videos about Monero for [Monero Russian Community YouTube channel](https://www.youtube.com/channel/UChZc5PLsbP5zeFrmOYMKGmA).
+
+## Shortlist of my previous localization works on Russian
+- [Mastering Monero](https://github.com/monerobook/monerobook/pull/81)
+- [Zero to Monero - Second Edition](https://github.com/UkoeHB/Monero-RCT-report/pull/9)
+- [Monero Reserch Lab bulletins and pappers](https://github.com/xmr-ru/monero-research-lab-translations/tree/main/publications/bulletins)
+- [Critical Decentralisation Cluster (36c3) transcriptions (RUS + ENG)](https://github.com/v1docq47/monero-cdc-36c3-transcriptions)
+- [Monerotopia 2022 transcriptions (RUS + ENG)](https://github.com/v1docq47/monerotopia-2022-transcriptions)
+- [Breaking Monero](https://github.com/monero-ecosystem/outreach-docs/tree/master/monero-outreach-docs/translations/ru/transcriptions/breaking_monero)
+- [Monero Cheatsheet (The Salmon Series)](https://www.bybaro.it/Moh3po/)
+- [and more...](https://github.com/pulls?q=is%3Apr+author%3Av1docq47+archived%3Afalse+is%3Aclosed)
+
+## Shortlist of my previous videos / voiceover for Monero Russian Community YouTube channel
+- [Monero News (Weekly) playlist | 172 video](https://www.youtube.com/watch?v=ixUamqRd3nc&list=PLQyX7h187qnQWtCN6brBXsB9QLEuaJWQO)
+- [Monero News (Quarterly) playlist | 7 video](https://www.youtube.com/watch?v=XZD-b2gq9dQ&list=PLQyX7h187qnTrEQo1n1_-lxR5tk0qlRKo)
+- [What is Monero playlist | 3 video](https://www.youtube.com/watch?v=FOsHxWG5jNs&list=PLQyX7h187qnTqq4_-EAnp4HZk9eJpMvZK)
+- [Monero Konferenco 2019 playlist | 18 video](https://www.youtube.com/watch?v=56Tr03HzGJ8&list=PLQyX7h187qnSZG_PTYtO57_z_nFOlWWEM)
+
+## My other projects
+- [Unofficial Russian technical documentation for Monero](https://wiki.xmr.ru/)
+- [XMR.RU on Hugo](https://github.com/xmr-ru/xmr_ru)
+
+## Shortlist my previous localization CCS reports
+- [April + May 2022](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/280#note_16701)
+- [February + March 2022](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/280#note_15637)
+- [December 2021 + January 2022](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/240#note_14349)
+- [October + November 2021](https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/240#note_11803)
+
+# What?
+
+Voiceover Monerokon 2022 and Monerotopia 2022 and creation information / news / tutorials video for YouTube channel and working on XMR.RU.
+
+A shortlist of planned works for the new period:
+- [Monerotopia 2022 on Russian (voiceover + transcriptions) | 13 video](https://trello.com/c/wDSM28Ip/5-monerotopia-2022-on-russian-voiceover)
+- [Monero Konferenco 2022 on Russian (voiceover + transcriptions) | 14 video](https://trello.com/c/voUReLOW/1-monero-konferenco-2022-on-russian-voiceover)
+- [Monero News (Quarterly) | 2 video](https://trello.com/c/SOflUox4/2-monero-news-quarterly)
+- [Monero News (Weekly) | 21 video](https://trello.com/c/RHet1Snz/4-monero-news-weekly)
+- [Monero tutorials | 8 video](https://trello.com/c/84t97TjC/6-monero-tutorials)
+- [Monero on XMR.RU](https://xmr.ru/)
+
+A full list of planned works is available at the link (Trello board) - https://trello.com/b/14d76On9/october-2022-march-2023
+
+It should be noted that this is not a complete list of the planned work. When I have free time, I deal with some additional items that may not be included in this list of work.
+
+# How much and Payouts
+
+Any kind of work must be paid, especially work which is pleasured for you and your viewer / reader.  
+Payment on first days of every month during 6 months for my upcoming work.  
+10$ per hour (~28 hours a week or ~112 hours a month).
+Monero median monthly price on Kraken ~157$ (15.08.2022 - 15.09.2022).
+
+## In total
+
+42.8 XMR for 6 month works.  
+7.13 XMR per month starting from october.