NCFP-2: Ongoing development incentives (3rd-party)

Author: @jimtalksdata

Background: Nyzo has benefited immensely from a distributed, decentralized development group comprising both the core developers and many others that have contributed important security and usability fixes to the project. Before the institution of the cycle account fund (, these issues have been funded directly by generous donations from the development team (Example of bounty payments: As the custodians of the cycle fund, the mesh as a whole should be obligated to fund continuing development.

Update 2019-11-14: Due to feedback from multiple users, development incentives and expenses for the core Nyzo Dev Team will be separated into NCFP-3 (Development Incentives and Operating Expenses for the Nyzo Dev Team, legacy) and NCFP-4 (Recurring Development Incentives and Operating Expenses for the Nyzo Dev Team). NCFP-2 will be intended for 3rd-party development of the Nyzo blockchain. For those matters, please comment on the appropriate topics.

Proposal: This will be a recurring proposal. Subproposals will be designated NCFP-2.1, NCFP-2.2, etc.)

The proposal would work roughly as follows:

Submission phase: Anyone is able to submit completed development work for consideration of funding. Projects are listed without consideration of funding amount. This phase will typically take a few weeks. Recurrent funding for an existing project (e.g. the core dev team) will be indicated as such.

Funding phase: All submissions for the previous phase are locked. New submissions of course can be made, but will go into the next NCFP-2.x subproposal.

Submissions for the previous phase will be assigned bounty values following discussion on, using the guidelines originally proposed by @nyzo. These guidelines should be subject to change after community discussion (ed: where?) if the underlying token fluctuates significantly in value.

If you find bugs and report them to us, we will reward you with coins through our bounty program. The reward for stability issues starts at ∩10,000, and the reward for security issues starts at ∩50,000. Rewards increase according to the severity of issues and quality of the report. We reserve the right to determine reward amounts, and our judgment on reward amounts is final. We also reserve the right to change minimum reward amounts or discontinue this program at any time without advance notice. There is no pre-determined limit on the amount of an individual reward, but all rewards over ∩100,000 will be announced when the first payment is made and divided into weekly payments of no more than ∩100,000 each (∩100,000 is 0.1% of all coins in the system, so it is a lot of coins).

In short, stability issues and features should be funded starting at ∩10,000, and security issues at ∩50,000. For critical security issues, responsible disclosure will be used. The rules for responsible disclosure will roughly parallel those of BitPay (, namely:

  • Adhere to the Responsible Disclosure Policy above
  • Do not attempt to gain access to another user’s account or information (use your own test accounts)
  • Report only original and previously undisclosed bugs
  • Do not disclose a bug publicly before it has been fixed
  • Do not use scanners or automated tools to find bugs
  • Do not attempt non-technical attacks such as social engineering, phishing, or physical attacks against our employees, users, or infrastructure
  • Do not attack the reliability or integrity of our services (e.g, no DDoS attacks, blackhat SEO techniques, spamming, or similar questionable acts)

Similarly, certain classes of bugs are excluded from the bounty program, namely:

  • Software packages not produced by the @nyzo core team
  • Domains hosted by third parties
  • Nyzo-branded services operated by third parties
  • Nyzo projects outside the scope of the nyzo github (
  • Nyzo domains or services operated by third parties (e.g. merchants, exchanges, etc.)

Critical security issues should not be posted in this forum, and instead should be directly disclosed to @nyzo or a forum/discord moderator. Upon the sole discretion of @nyzo or a forum/discord moderator, disclosure of the issue will be permitted on as appropriate.

At the end of this phase, transactions from the cycle account to accounts designated by accounts held by developers will be made. Using an Agent would be optional.

Voting phase: All submissions and funding amounts are locked, and cycle transactions have been sent (anyone can do this, but generally it’s probably preferable for community members with more experience to set up the transactions). A suitable block height is chosen. The mesh votes on the proposal.

Chief risks and mitigation: To be completed for subproposals.

Certification: Posting of this proposal on should be considered as authoritative. Subproposals will be certified separately.


1 Like

NCFP-2.1: Development incentives for October 2019

Author note: Since this is the very first one, I’m not sure how it will work exactly. I’ll go ahead and list reasonable bounty) amounts also, but I definitely do not have authority on setting any of these amounts. Also, personally I feel that this proposal is currently more concrete than NCFP-1 since no annoying exchange rate risk is involved, and we could try passing this one first.


A: @Angainor:
NyzoSpace - BIP39 HD Wallet
NyzoStrings - NyzoString Library
Rationale: A reference quality implementation of Nyzostrings, and associated HD wallet that is SLIP-compatible. This would be very important for further adoption of Nyzo on cross-platform solutions.
Proposed amount: 20,000 nyzo
Address: id__87vo1ihVrKMFD4bSXHU2D4ZRQKzsZpqCAkP8_PML9Ljzru.zFwbi

B: @YanDevDe:
nyzoVerifier - nyzoVerifier with RPC support
Convert public identifier to image
Rationale: RPC implementation is crucial for increasing exchange integration of Nyzo.
Proposed amount: 20,000 nyzo
Address: id__87v7G1WX91GrzT-30uHMQz4VSZaWRgrouzI0Hx651AXLJHrxP0sZ

C: @NyzoSy - Vanozy: Vanity address generator for NyzoStrings
Rationale: This project is a useful implementation of @Angainor’s NyzoStrings project.
Proposed amount: TBD
Address: abd7fede35a84b10-8a36e6dc361d9b32-ca84d149f6eb85b4-a4e63015278d4c9f

D: @Nyzo - The development team
Will be moved to NCFP-3 and NCFP-4.

E: @Moco - MocoMaco/ThreeDotsIo
Nyzo Mobile Wallet for Android and iOS (multilingual)
Rationale: Nyzo mobile wallet runs on an app on your phone and it is useful because it can be used anywhere, also it is simpler than web wallet. This type of wallet is essential for further adoption of Nyzo.
Proposed amount: 30,000 nyzo
Address: id__88UT5xYF0PY5eN2utfiaVSqTq36V9Tg3PS.eurTw5k_QYnHKVtQG

Author note 2: I envision voting to work something like this:

  1. All proposals are numbered A,B,C … during the submission phase
  2. Funding phase involves a CSV list of the proposal and amount. Each member that wishes to comment can submit a list like this:

To leave out a particular proposal, omit the line or enter “0” for the amount.
3. The median or geometric mean (ed: which would people prefer) of each proposed item would serve as the final funding amount (ed: what about Sybil resistance and ballot stuffing? Have additional requirements?).

1 Like

NCFP-2.2: Development incentives for November 2019

A: @Moco:
Nyzo Mobile Wallet for Android and iOS (multilingual)
Rationale: Nyzo mobile wallet runs on an app on your phone and it is useful because it can be used anywhere, also it is simpler than web wallet. This type of wallet is essential for further adoption of Nyzo.
Proposed amount: 30,000 nyzo

1 Like

Great. If there aren’t any more by the end of this week. I guess we can move on to the funding phase for 2.1.

1 Like

My votes below. Use any particular number you want, and don’t rely on mines.

D(DevTeam), Will be moved to NCFP-3 and NCFP-4.

Since voting had yet to start, we can put Moco in 2.1.


I find the suggested incentives to be quite high (I already was of this opinion regarding the earlier (bug-) bounties). Even at current Nyzo prices, they are close to typical Upwork salaries for this kind of work and waaay above the typical bounties on, say, GetGitcoin. My belief is that in this early phase of Nyzo, working for the project should be a mixture of goodwill, doing it for one’s own portfolio, belief in the project’s future, and direct monetary reward. I also think that we should try to make the dev fund last 4 to 5 years rather than 2.

So, my suggestion is roughly one 3rd of the above, except for the core devs, for which I don’t understand why they should receive the lowest monthly reward of all parties.


It’s important to understand that I in no way want to talk down the worth of these contributions for Nyzo, I just think that from an overall project perspective we are not yet at a point where we can pay out close to real-world salaries.


Although I agree we need to be rational with the funds, contributing during this early phase of the project is very valuable and these compensations can be viewed as a cumulative for the work done so far. Respecting the minimum of 10k I vote for these incentives, noting that we can use the forum to plan the range of future incentives:

1 Like



D: Nyzo Dev Team: 500,000.

Based on extensive feedback and some confusion about item D in NCFP2.1, that particular item will probably be removed from the cycle transaction (for now). Instead, NCFP-3 (Development Incentives and Operating Expenses for the Nyzo Dev Team, legacy) and NCFP-4 (Recurring Development Incentives and Operating Expenses for the Nyzo Dev Team) will be created to address the multiple points raised by users. You may continue to comment about this item here, or the respective topics when they are created.




Voting will close this coming weekend. Again for D, all discussion should move to NCFP-3 once it is up.

This isn’t easy to gauge but I think this is fair.
I’m basing these numbers on how many hours I estimate the developers took.
A multiplyier based on value to community, responsibilities.
Then, multiplied by a (IMO) healthy day rate and a converiosn of 1 Nyzo = $0.20

A couple of points

  • What is opininion on giving project owners a little fund to tip contributors?
  • And, I would like to thank the community, core, and the developer contributors for making Nyzo a welcoming community be part of and a very exciting project to follow :smiley:



Hard to give an opinion since we are involved.


Would it be easier to appoint a receiver of the funds that the community considers a trusted escrow, such as @Showerhead or @Snipe? There would be an additional transaction, so recipients may have to get 0.25% less, plus any sort of tip to the receiver for their services.


This works for me, can do this free of charge

1 Like

Final amounts for voting phase

Angainor	YanDevDe	NyzoSy	Moco
20000	20000	10000	30000
7500	7500	4000	10000
20000	20000	10000	30000
4000	3000	3000	5000
11500	8000	3500	30500
11500	9000	3500	16000

AVERAGE 12416.66667 11250 5666.666667 20250

Transaction of 49707.29167 (+0.25%) will be sent to @Snipe after the implementation of NTTP-3. I will announce the cycle transaction details here.

I would also like to initiate discussion for this month’s security bounties here:

1 Like

For transparency, I will receive the aforementioned amount of 49707.29167 + 0.25% if the cycle transaction gets approved by the cycle.

My escrow identifier is id__86wcW-8qW8J-a7RpS6TdJZvTK-JWRVDBBmeFi8YAhS_zvQI2~WFr

From which will be sent:

  • 12416.66667 to Angainor - id__87vo1ihVrKMFD4bSXHU2D4ZRQKzsZpqCAkP8_PML9Ljzru.zFwbi
  • 11250 to YanDevDe - id__87v7G1WX91GrzT-30uHMQz4VSZaWRgrouzI0Hx651AXLJHrxP0sZ
  • 5666.666667 to NyzoSy - abd7fede35a84b10-8a36e6dc361d9b32-ca84d149f6eb85b4-a4e63015278d4c9f
  • 20250 to Moco - id__88UT5xYF0PY5eN2utfiaVSqTq36V9Tg3PS.eurTw5k_QYnHKVtQG

That concludes the full scope of this escrow operation.


Thanks Snipe. The above transaction will be created at a convenient time for me after 2020-04-02 03:06:40.000 UTC (activation of NTTP-3).

NCFP 2.2: Security bounties for Feb-March 2020

I would like to also initiate discussion for the security bounties in v572 and v574:

V572 addressed a bug concerning potential attacks on verifier stability of the NodeManager code. Two members independent reported this bug. Proper exploitation of this bug could result in cycle stall, tremendous hassle for operators of verifiers, and loss of verification positions in the cycle.

The following addresses were provided for claim of this bounty:


V574 addressed problems of trusted message verification. Proper exploitation of this bug would impair a sentinel’s tracking of the blockchain by providing incorrect information.

The following addresses were provided for claim of this bounty:


On previous awards:

The NicknameManager issue, addressed in version 500, resulted in a ∩75,000 bounty. The signature-buffer issue, addressed in version 503, resulted in a ∩225,000 bounty. The TIME_WAIT issue, addressed in version 539, resulted in a ∩30,000 bounty.

The OWASP risk framework was used to assign severity. An example is provided by Stellar:

Based on this risk matrix, the previously awarded bounties were calculated as follows:

NicknameManager issue: Medium (medium impact/medium likelihood)
Last transaction:
qTrade price on 2019-03-06: 5699 sats/n
75000 n x 5699 sats/n = 4.27BTC ~ 4

Signature buffer issue: High (medium impact/high likelihood)
Last transaction:
qTrade price on 2019-04-05: 3438 sats/n
225000 n x 3438 sats/n = 7.73BTC ~ 8

TIME_WAIT: Low (low impact/medium likelihood)
Last transaction:
qTrade price on 2019-08-01: 3169 sats/n
30000 x 3169 = 0.95 BTC ~ 1

Nyzo previously mentioned that an issue in the “critical” category would be something akin to a double spend type of attack that would result in compromise of the core protocol, and that such an issue would be eligible for “perhaps 10 or 20 million”:

My assessment of severity is as follows (feel free to discuss):

V572: medium (medium severity/medium likelihood)

  • Cycle stalls are inconvenient, but do not result in compromise of funds or core security
  • Losing verifiers in the mesh is costly
  • The attack requires medium technical expertise to carry out

V574: low (low severity/medium likelihood)

  • Misleading sentinels can lead to new entrants not joining or existing verifiers not being protected during downtime
  • No compromise of funds or loss of cycle integrity
  • The attack requires medium technical expertise to carry out

Hence, my following assignments for bounty amounts:

30-day MA of qTrade price: 3111 sats/n

V572: 4 BTC / 3111 sats = 128 576 n / 2 members =>

64 288 n to id__8duga.00nTqUTgoHHpo6QK5qDmEWYUG0qYnDY7JEx5e11mG9qESw
64 288 n to id__8fuGBeFqfcwXPgRh8BraZL-bn3rxgBxv_up6SGXZj.pKyEp.RV1L

V574: 1 BTC / 3111 sats = 32 144 n ==>

32 144 n to (TODO)

Total amounts awarded: 160 720 n

As for the previous development rewards, I will take the arithmetic mean of all amounts mentioned below until the voting phase ends. Haven’t decided a date yet, but probably a few weeks.