Hi everyone. With the recent finalization of the Community Charter and the formation of the Tari Council, I wanted to open a discussion about a concerning discrepancy between stated bounty protocols and actual PR execution, which currently risks alienating high-level contributors.
On the May 19th Tari Show, it was explicitly stated regarding the ~25 competing PRs that “maintainers will select best implementations.” However, the on-the-ground reality seems to contradict this.
Recently, on a major architectural migration PR, my submission implemented the correct timeline-reconstruction, properly mapped legacy outputs, and passed all 8/8 CI tests first. Instead of selecting the “best implementation,” the PR was stalled in review. During that delay, my architectural pivot was utilized to guide a competing, fundamentally flawed PR out of a failing state, which was then merged under the justification that it was “the first one opened.”
If the unwritten rule is actually “first draft opened wins, regardless of architecture,” that needs to be officially documented. But if the rule is truly “best implementation wins” (as stated on May 19), then keeping contributors on the hook while their intellectual work is transferred to salvage a competitor’s broken code is a severe governance failure.
As Tari scales, coordination and communication across contributors are critical. But if the bounty system operates as a lottery for who opens a draft first, rather than a meritocracy for bulletproof engineering, it will actively discourage the technical talent required to build out this ecosystem.
I am raising this for the Council and the community to clarify the standard operating procedure moving forward, and to request a review of how cross-pollinated architecture is handled in competitive bounty payouts.
As the person who merged the PR, let me expand on why I selected the first one. PR 121 was the first PR submitted, and it was made by the first contributor to claim the issue. This matters.
We create issues for a few reasons:
To document the problem
To provide a place and a record for discussing it
Importantly, to allow someone to claim the issue and signal that they’re working on it — it doesn’t help if the entire community works on the same issue in parallel
That said, on this project there are sometimes competing ideas, and more than one person wants to work on an issue. In those cases, we’ll try to merge the best PR we can — but that decision happens at merge time, not at the initial concept stage. When I did a final review of the two PRs, both were in a good-to-merge state, with very little difference between them.
From a maintainer standpoint, I try to go over all PRs every day, but I can’t sit and wait to drop everything the moment a new commit is pushed. Sometimes I can’t get to reviews right away because other items need more immediate attention. And depending on the size of a PR, I’ll often stop reviewing once I’ve found enough things that need addressing — especially if the required changes would reshape part of the PR. If I kept going past that point, I’d be reviewing code that’s about to change anyway, which wastes everyone’s time.
@blackwolfsa Thank you for the detailed response and for clarifying how the Tari team prioritizes “first claimed” over “first functioning.”
I respect your authority to merge whichever PR you prefer as a core maintainer. However, for the historical record of this bounty, I must clarify your statement that there was “very little difference between them.” That similarity only existed at the very end because my PR’s correct timeline-reconstruction mapping was actively utilized over the last few days to resolve the fundamental blockers in #121.
Given that this touches directly on the “best implementation wins” policy discussed on the May 19th Tari Show, I welcome the newly formed Tari Council or other Core Stewards to review the commit timelines independently to ensure the bounty allocation process remains transparent and fair for future contributors.
So let’s dig into the specifics here. Yes, initially your PR was in a better state than the other one — but importantly, neither PR was in a mergeable state at that point. It was only after multiple passes over both that they got there. So you’re right that “very little difference between them” only applies at the end, but your PR also had fundamental blockers right up until the end. If that hadn’t been the case, it would have been merged first.
If you look at the community PRs I’ve merged recently, quite a few of them have a commit from me at the end. That’s because I don’t want to block a PR from getting merged over a quick nit — I want the community to contribute.
We’re an open source project, which means code submitted here is open for everybody to look at and review. If any contributor reviews a PR and points out an issue, that issue needs to be fixed before the PR can go in. You can open a PR against that PR, or, if the original contributor doesn’t want to address it themselves, open a separate PR with the fix. Either way, we’re working together toward a shared goal. The code gets better when you, me, or any other contributor reads through it, reviews it, and opens a PR. That code can be inspired by any other piece of software out there — as long as nothing is being copied in a way that violates its license or steals someone else’s commits.
To clarify for the Council and ensure transparency, let’s look at the actual sequence of events regarding these “fundamental blockers.”
My PR (#122) successfully implemented the correct timeline-reconstruction mapping. During review, four specific output status mappings were flagged for filtering final phase review comment. I pushed the exact fixes for those within minutes, bringing the PR to a fully passing, ready-to-merge state. However, instead of merging it, my PR is stalled for 5 days with not even single comment , direct commits were manually pushed by a maintainer to the competing PR (#121) to salvage its failing state, prioritizing one and ignoring another one.
A minor status filtering adjustment is a standard code review refinement, not a “fundamental blocker.” Pushing manual commits to save a failing competitor’s PR while a fully passing one is left open completely contradicts the stated “best implementation wins” policy.
I have laid out the sequence of events and the links for the Council to review. I ask the Stewards to evaluate this process to ensure future contributors are judged on the merit and readiness of their code.
This means your pr was not as you claim fully passing, ready-to-merge
your 5 days is wrong as well. It did the review on Friday. I am not going to do code reviews on weekends unless absolutely required to. Monday had crucial tasks taking priority. Tuesday I got it.
If you want to nitpick my timestamps, go look at them. I gave the exact same effort and attention to your PR as the other one, except I always review them in order of oldest to newest. And you can see that on all my reviews.
@blackwolfsa To be clear, the issue being raised for the Council’s review is not about weekend review schedules or minor dependency syntax. It is about fundamental architectural superiority and project governance.
To ensure the Council has accurate technical context regarding the claim that there was “very little difference” between the two PRs, we need to look at the actual architectural implementations and file structures. Beyond the multi-output and block-height logic, there is a fundamental difference in how the codebase was modularized.
PR #121 (The Merged Implementation):
Lacked proper command modularity.
Lacked --dry-run and --allow-partial-import safety flags.
Required extensive, step-by-step maintainer coaching just to reach baseline debit/credit functionality.
PR #122 (The Closed Implementation):
Implemented strict, clean architectural modularity by isolating the command logic into minotari/src/commands/migrate_console_wallet.rs and minotari/src/commands/mod.rs—files that do not even exist in the merged PR.
Provided advanced CLI execution flags for safe testing.
Engineered the correct scanner-style timeline and balance changes from the start, without requiring maintainer intervention.
Claiming “very little difference” ignores that one PR used superior module organization and safety features, while the other required massive maintainer hand-holding just to pass.
Merging a PR that required coaching over a PR that engineered the architecture from the ground up violates the “best implementation wins” mandate. I am leaving this file breakdown here for the Council. The diffs speak for themselves.
I’ve been pondering this and think there are some fundamental tensions at play:
All contributions are publicly evaluated
The nature of open source contributions means that competitors can glean from one another in their solutions
Saying that the ‘best PR’ will be chosen implies there is an objective rubric that can be consistently applied to each PR
Bounties are winner take all
While it is tempting to suggest that the council should intervene and make strict rubrics here, I think that kind of centralized micromanagement would be anathema to the project’s long-term decentralization goals, push contributor burnout, and create more litigative discourse.
I would put forth a few refinements on the bounty program:
Instead of saying the ‘best PR’ will be chosen, we can say that ‘maintainers will have discretion to choose the PR they believe is most viable and demonstrates good contributor practices/behavior’
The ‘good contributor behavior’ allows a maintainer to decline bad-faith bounty pull requests that verbatim copy someone else’s work and apply one fix while the other is sleeping, say.
We should make it explicit that contributors are expected to learn from and pull ideas from each other’s PRs and reviews.
This ensures people aren’t doing non-productive redundant work that isn’t aiming toward a common goal just to make sure their bounty is ‘free and clear’ and also makes sure that borrowed ideas don’t become a point of litigation, which is against open-source ethos.
It should be possible to split bounties in cases where multiple contributors are making significant contributions. The apportionment can be at the discretion of the maintainer.
This makes sure that being a first-mover doesn’t put a contributor at a disadvantage and means that people have some incentive to work collaboratively. Each has to do less work, and each is rewarded for it.
After reviewing both PRs, it seems clear the wrong PR was selected. 0xPepeSilvia - still deeply respect the contribution - but @Sanrishi had a PR that was more mature and met a considerably higher level of coding standard that we should expect for a financial system like Tari. @blackwolfsa - did you have any preexisting relationship with 0xPepeSilvia? At risk of sounding accusatory, if you are buddies it might be best to recuse yourself from the decision making process so the best PR can be accepted in the future.
I think these are all great suggestions, particularly split bounties.
I would also like to suggest a change to how the bounties work.
Instead of “5. First PR that passes review and gets merged wins the bounty” I think it should be the best PR that passes review (or some variation of Fox’s suggestion in point 1 above). This is obviously subjective and up to the reviewers discretion, but in conjunction with the split bounties @Fox suggested above, it should facilitate more collaboration and borrowing of ideas which hopefully results in better code.
I also think bounties should be posted with a claim window. For example, if a bounty is posted with a 72hr claim window, contributors don’t begin the review process until after the window has closed and no further submissions will be accepted.
At this point, reviewers could select the best option(s) from the submitted PRs, and work with the contributor(s) to make any necessary adjustments before merging.
Together, I think these two changes will result in much higher quality submissions. We should structure the program so that it incentivizes thoughtfulness, ingenuity, and quality engineering over speed.
The bounty program is new, there’s bound to be some issues. We should focus on working together to improve the program rather than arguing about what’s now done.
This is an interesting idea, but I think I’d rather hold off on it for now and see if the incentive changes from the things I suggested resolve the issue first. A concern comes to mind that it may exclude people who were out at the time and missed the memo, or people who took extra time to think through a solution. Your idea might still be necessary-- especially if we end up with a large volume of contributors going after a single bounty-- but I’d rather wait and see a bit.
@possum To ensure the long-term technical standards of Tari, we need to look at the game theory and incentives created by this specific rule proposal. While the intention is clearly to streamline reviews, the current wording introduces critical security and quality vulnerabilities.
“Review comments are public, and contributors may borrow ideas from each other’s work.”
If a developer spends days engineering a complex architectural solution, and another developer can legally copy that architecture at the last minute to patch a failing PR, you have destroyed the incentive to build complex systems. Senior contributors will stop submitting high-level work if the rules explicitly protect architecture-sniping.
“The maintainer selects the PR…”
This replaces objective engineering rubrics with absolute subjective authority. If two PRs are submitted, and one explicitly handles critical edge cases while the other does not, but the maintainer merges the inferior one based on “discretion,” the protocol degrades. A financial system cannot rely on subjective discretion; it must rely on objective, verifiable technical superiority.
The Solution:
Giving a single individual unilateral, final decision-making power over competitive financial bounties creates a central point of failure for project governance.
To protect the protocol’s integrity, competitive bounties should require Review Consensus. If multiple PRs are submitted for a bounty, the final selection should require review and sign-off from at least two core maintainers. This ensures the best architecture wins, enforces separation of duties, and removes the risk of individual bias or bottlenecking.
If the goal is to incentivize thoughtfulness and high-level engineering, the rules must require strict, objective technical justifications for every merge, verified by consensus.
Personal accusations without merit are not appreciated.
@Sanrishi
This is open source; you cannot force people not to look at other code structures. Are you telling me that you have never looked at a solution on Stack Overflow, or used any LLM in the code? And complex systems != better code, complex systems == complex bugs. Simple code is always better.
On code reviews, nothing stops you or any other reviewer from reviewing the PR’s. Infact its encouraged to do so. This is an open source project, meaning more eyes on PRs = better code.
Thanks everyone for the discussion. This thread surfaced a real issue and the community responded with constructive suggestions. Here’s where we’ve landed.
The bounty rules have been updated:
Bounties are competitive. Multiple PRs may be submitted for the same bounty. Review comments are public, and contributors may borrow ideas from each other’s work. The maintainer selects the PR that best solves the problem, considering code quality, completeness, and contributor behavior. In cases where multiple contributors made significant contributions, the maintainer may split the bounty. The maintainer’s decision is final.
This incorporates suggestions from @Fox and @kinkajou : borrowing is expected and named as such, maintainers have discretion based on contributor behavior, and bounties can be split when multiple people made real contributions.
On the question of maintainer discretion: this is how open source works. Maintainers review code, make judgment calls, and merge. Adding review committees to bounty decisions would slow the process to a crawl for a problem that doesn’t exist at our current scale. If that changes as the project grows, the Council can revisit it.
This thread did its job. The rules are better for it. Let’s get back to building.
