scrobble.life
#hive

What the Git Logs Actually Say Part I: Keychain, Ecency and PeakD Under the Microscope

Untitled design (6).png

I made a few pound in crypto over the years by looking at a cryptocurrencies repos (and before you say it , yes many of them were public), to see whether they were worth taking a punt on. If there were hardly any commits the team normally weren't up to much bar marketing. If there were loads of commits it meant a busy team but you would have to look into these in more detail as one line diff's (differences from old code and new code) could be just a name change, a character change here or there so one could say the devs looked busy but they may not have been. You really have to get into the weeds here and look under the hood rather than looking at a graph on Github with the colour green on them. I spent many of my Hive posts dealing with one area of the DHF that was being targeted by scoundrel's which was Valueplan but I needed to broaden my horizons as I am a gluten for punishment and the lack of post rewards compared to my time on Hive. But I have my values and they are more important any post rewards so we plough on.

The DHF pays out real money every day, and lately the community has been deciding — proposal by proposal — who still deserves it. Ecency and PeakD dropped below the return threshold in late June; Ecency has since clawed its way back above the line at a fraction of its old ask, while PeakD remains unfunded. Keychain, at 540 HBD/day, is the largest development payout on the chain.

So I did what anyone can do: I cloned the repositories and read the history. Every commit, every line, every week of 2026. This post lays out what I found. I'm going to show you the numbers, the patterns, and the honest caveats — and then you can decide for yourself whether these projects earn their funding. I have opinions; you'll have yours. The data belongs to everyone. Point to note this is not a big reveal but a constructive look at the work that the remaining funded projects are doing. I use all these platforms and they are all great. Keychain, Peakd and Ecency. During this process I have also gained some understanding on why rugs are pulled on proposals and why some are funded. The 3 projects above are genuinely the best that Hive has to offer. Whether they are worth the dosh at current market prices is for the Community to decide.

What is a commit? I hear the non tech Hivian ask.

A commit is one saved change to the code — like hitting "save" with a note attached saying what you changed and when. The project's history is just thousands of these saves, stacked up, with each one signed and timestamped. That's why they can be audited: nobody can work without leaving them, and nobody can fake having worked by adding them retroactively without it showing.

How I measured (and what the numbers can't tell you)

Before a single number: methodology, because commit counting done lazily is worse than useless.

  • I cloned every public repository of each project's GitHub organisation — 16 repos for Keychain, the full Ecency org, and everything I could find for PeakD.
  • I counted commits and lines changed per commit across all branches for 2026 (Jan 1 – early Aug, ~32 weeks).
  • I excluded automation and generated content: dependabot, lockfiles, build artifacts, committed coverage reports, translation-file syncs (Crowdin), snapshot files, and pasted reference data like contract ABIs. This matters more than you'd think — for one project it removed more than half of all commits.
  • For forked repos, I counted only the project's own commits, not upstream authors.

And the limits, stated up front:

  1. Lines are activity, not value. A 12-line consensus fix can be worth more than a 1,000-line UI refactor. Judge the shipped features, not just the churn.
  2. Not all work is commits. Releases, app-store wrangling, infrastructure, user support, and design never appear in a git log.
  3. Private repos are invisible. I can only audit what's public. I get it some platforms need a private repo but if they are being funded should the repo not be accessible?
  4. Workflows differ. One dev making 100 small commits and another making 20 large ones can represent identical effort. I report medians and totals so you can see both.

Everything below is reproducible by anyone with git and time on their hands.

Keychain — 540 HBD/day, currently funded

The team: effectively two developers, splitting ~1,200 commits almost evenly.

The volume: ~32 real commits/week, median 85 lines per commit, roughly 264K lines touched in 2026. For a two-person team, that's a solid, professional cadence — about four commits per developer per working day, with a fifth of commits being substantial (200+ lines). This is not padding.

The pattern is where it gets interesting. Their 2026 proposal post went on-chain in mid-April; the proposal (#373) began paying on May 15.

Period Output
Jan – mid-March (old proposal paying) ~2,000 lines/week
Mid-March – mid-June (buildup, campaign, and the month after funding) ~13,000–25,000 lines/week
July – now (funding secure) ~3,500 lines/week

The surge began a few weeks before the proposal post and peaked in the weeks around the vote — which is also exactly when they shipped their multichain/EVM beta. Then output fell to roughly a quarter of campaign pace.

keychain-weekly-vs-proposal.png

Keychain weekly output vs proposal timeline

Keychain's weekly output against the proposal calendar: quiet under the old funding, an eightfold surge through the campaign, peak just after the money lands, then the drop.

Two readings fit this data. The skeptical one: work intensifies when funding is at stake and relaxes once it's secured — note that the two quietest stretches of the year are both periods when funding was comfortably locked in. The charitable one: this is a normal release cycle — crunch, ship the beta you promised, recover — and a European team slowing down in July and August is hardly a smoking gun. The commits themselves are real and substantial either way. What the pattern does establish is a fair question: what does the daily rate buy in the quiet months? Their proposal commits them to progress updates — their own dev posts open with "as promised in our proposal, here's a summary of our latest developments" — so the record is checkable. And checked, it reads like this: the account's last development summary predates the quiet period; its July output was contest announcements for the multichain challenge; its last post of any kind was the contest winners on July 12 — four weeks of silence as of this writing; and no release has reached the Chrome, Firefox, or mobile app stores since June 11. The commits, the posts, and the store releases all go quiet together. Perhaps the next update will show the "larger features pushed progressively to production" that an earlier post promised — the reader can line the dates up and judge.

At today's depegged HBD (~$0.91), 540 HBD/day is about $494/day, or ~$15K/month for the team. What that 15k shipped in July is the question?

Ecency — defunded in late June, re-funded at a reduced ask

First the funding arc, because it moved three times this summer. In mid-June, with the belt-tightening mood building, Ecency publicly offered to reduce its own daily ask. It dropped below the return threshold anyway in late June — and in the same week, filed a new, drastically smaller proposal (#379, "Ecency development and maintenance," 100 HBD/day, running June 22, 2026 to July 22, 2027). It kept shipping through the unfunded weeks, and in early August that reduced proposal climbed back above the return line — at the time of writing it has been paying for only a few days. Whatever you make of the numbers below, the community's verdict has already moved once: defunded in the purge, re-funded at less than a fifth of Keychain's rate.

The team: essentially one extraordinarily prolific developer, with occasional contributors.

The volume (after heavy cleaning): of ~6,900 raw commits, more than half were translation syncs and version automation. What remains is still remarkable: ~104 real commits/week, median 48 lines, ~685K lines touched in 2026 — roughly two and a half times Keychain's churn, from one person and 5 times less the funding. That pace (15–20 commits per working day) suggests a rapid-fire, likely AI-assisted workflow. I don't say that as criticism — shipped and working code counts — but it does mean raw commit counts can't be compared across teams. Lines and features are the fairer yardstick.

The pattern is the mirror image of Keychain's. Ecency lost DHF funding in late June. Through the unfunded weeks that followed, output went up — that stretch includes three of the biggest weeks of the year, driven by real deliverables: a complete API port, an icon-system overhaul, mobile camera fixes.

Ecency weekly output vs defunding ecency-weekly-vs-defunding_1.png

Ecency's weekly output in three acts: funded (blue), defunded (orange — everything here was built unpaid, at half again the funded pace), and the green ending: voters put the reduced #379 back above the line in early August.

Two readings fit here too. The charitable one: this is a builder who ships regardless of pay, and defunding a project that behaves this way was arguably the DHF cutting one of its better performers. The strategic one: nothing motivates a sprint like needing to win back a vote, and sustained unpaid output is also the best possible campaign material. Both can be true at once — and for what it's worth, the campaign worked: the visible unfunded output is plainly part of why voters put the reduced ask back above the line.

PeakD — defunded in late June, reduced ask still unfunded

First, the funding facts, because they've moved twice this summer. PeakD's combined proposal (#350, "PeakD and Peak Open Projects," 490 HBD/day) had been funded for about a year before it fell below the return line in the summer purge. Within days, the team posted a leaner replacement — #382, "Sustainability and Maintenance" (June 19) — explicitly scaled down to keep-the-lights-on scope. As of this writing, #382 has not reached the return threshold either. So PeakD is currently receiving nothing from the DHF on either line — while its weekly release posts have continued without a break: new discovery feed, GIF search, wallet improvements, security hardening, a built-in chat. Whatever else this post says about verifiability, the record shows a team that responded to defunding by asking for less and shipping anyway.

Now the finding that makes their section different from the other two: the commit-level analysis in this post cannot be run on PeakD's flagship.

Their GitHub organization contains status-page repos, and the main peakd.com frontend — the product the sustainability proposal funds — is closed-source. But it would be wrong to say the team publishes no code, and an earlier draft of this post got that wrong: they maintain a public GitLab group (gitlab.com/peakd) with genuinely open side projects — HiveHub and its block explorer, the Hive Node Beacon — built under their separate "Peak Open Projects" initiative, with a stated policy of opening each repo once stable. Credit where due: those repos are cloneable and auditable by anyone, exactly like Keychain's and Ecency's, and readers are invited to run this post's methodology on them. The distinction that matters for the DHF question is which code the money funds: the flagship interface used by thousands remains unauditable, while the open repos are the periphery. Their weekly release posts show real features shipping on that flagship — including after defunding — and I have no reason to doubt the work happens. But no one outside the team can verify it at the commit level.

To be fair to them: closed source is a legitimate choice with real reasons (abuse resistance, competitive concerns), PeakD is widely regarded as one of the most polished interfaces on Hive, and a git log was never the only form of accountability — their public release notes are consistent and detailed. But when public money funds development, the difference between "verifiable by anyone" and "take our word for it" is not nothing. Two of the three projects in this post can be audited line-by-line by any stakeholder with an internet connection. The third asks for trust. Whether that difference should matter to your proposal vote is exactly the kind of thing this post leaves to you.

Do they earn money elsewhere?

A fair audit has to ask this, because "the DHF is their lifeline" and "the DHF tops up an existing business" are very different propositions — and the answer is different for each project.

Keychain operates a swap service with a fee on every trade, and markets a swap widget to other Hive apps with a revenue-share on the fees it generates. The lead developer also runs a long-established top witness node, which earns block rewards. Ecency sells Points — purchasable in-app, spent on boosting and promoting posts — which is real cash revenue, and its founder likewise runs one of the chain's longest-standing top witnesses. PeakD charges its users essentially nothing — no ads, no fee skim — so this question largely doesn't apply to the site itself; the team's known commercial arm is PeakMonsters, a separate Splinterlands market business.

To Keychain's credit, their fee rates have never been hidden — release posts state the commission openly and the swap shows its fee on every quote, and when asked years ago about long-term monetisation, the lead dev publicly described a plan for a shared-revenue model that would buy and burn HIVE. What no project has published is the quantities — no swap volumes, no revenue figures, no Points-sales numbers — and the proposals don't include them. In fairness, all of these revenue streams are denominated in assets that have lost most of their value this year; a witness node or a fee book in 4-cent HIVE does not pay a developer's salary, and DHF support may be exactly the bridge covering what market revenue currently can't. But voters can't weigh what they can't see. Which raises a governance question bigger than any one project: should DHF proposals be required to disclose the applicant's other Hive-derived income, so stakeholders can judge need alongside output?

The context none of this escapes

All of this is happening while HIVE sits near its all-time low and the HBD debt ratio has pushed into haircut territory — HBD is trading below its peg, and every HBD paid out of the treasury into circulation now degrades the backing of the rest. That's the backdrop for the summer's churn: six funded proposals cut to four at the purge's deepest point, both major frontends dropped, one retroactive-pay proposal ended, at least one ask withdrawn after pushback — and the list is still moving weekly, with Ecency's reduced proposal and a new AI-coding line climbing back above the bar even as older ones slip below it. Stakeholders are doing triage in real time. The question this post can't answer — because it's a values question, not a data question — is what a treasury under stress should fund: the tools with the most verifiable output, the most users, the most trust, or nothing at all until the peg recovers.

What I'd ask each project

Keychain: two questions. First, the funded quiet months are the accountability gap — what does 540 HBD/day deliver in a non-campaign month? The weekly reports promised in the proposal are the place to show it. Second, on revenue: your fee rates have always been public, and years ago you described a plan to monetise via shared revenue with a HIVE buy-and-burn — so the follow-up writes itself. What did the swap and commissions actually bring in, and did the burn ever happen? I checked the second half myself: across @keychain, @stoodkev, and every swap-related account name I could find, the chain shows a combined ~388 HIVE ever sent to @null since 2020 — a handful of promotional-scale burns, not a revenue programme. If the buy-and-burn runs from an account I haven't found, a transaction link would settle it in one comment. Either way, the swap volume is on-chain and measurable, so the revenue numbers will surface eventually regardless — publishing them yourselves in a proposal update would close the loop you opened, and would cost nothing but candour. Ecency: the work is visible and abundant, and voters have already answered part of the question by re-funding the reduced ask. What remains is the disclosure one: roughly what do Points sales bring in alongside the 100 HBD/day? Even a ballpark figure in the proposal updates would set a standard every other applicant should follow. I presume it is negligible. PeakD: you already open-source your side projects and have said you open repos once they're stable — would you extend that policy to the main interface, or publish any independently verifiable development metric for it? Nothing in this post would strengthen your case more.

In summary these 3 blockchains are putting in the work. Maybe more work than normal at certain times of the year but we all have deadlines in our jobs that we work harder to achieve and this is precisely that. The positives we can get from this is that the teams are still working and active on Hive which is more than what we can say for a few other proposals that have gone by the wayside since defunding.

Verify me

Don't take my word for any of this. Clone the repos yourself (git clone --bare), run git log --numstat, exclude the noise, and check my numbers. Pull the proposal dates from the chain. If I've made an error, tell me in the comments and I'll correct it prominently. The point of a public treasury on a public chain is that nobody — not the projects, and not me — gets to say "trust me."

For scale: my own repo. I ran the same analysis on my own hobby project Sportsblock — 229 commits over 12 weeks, unfunded, built in evenings around a full-time job. Per developer, that's a comparable commit rate to the funded teams, with the same bursty rhythm I noted at Keychain: a big opening sprint, a monster week, quiet patches, steady maintenance. Burstiness alone proves nothing — it's how everyone works. The question I'm putting to funded projects isn't "why do you have quiet weeks," it's "why do the loud ones track the proposal calendar."

Analysis covers Jan 1 – Aug 6, 2026, all public repos and branches of each organisation. Automation, lockfiles, generated files, translation syncs, and upstream fork commits excluded. All figures approximate to the nearest sensible rounding; the repos are the source of truth.

Point to note I picked these 3 out because they are our best proposals for funding with the exception of the Hive Core Development Proposal. I did a quick scan on the Magi Network which was said to be the answer to all of Hives problems and we were all having orgasms over. They have only 1 commit so far August so it looks like they are having trouble without the funding, dev team leaving or changing etc. After 800,000 HBD already allocated it would be a shame for this to flop. Maybe this is worth a Git Log episode in Part 2. Hopefully the post above gives you an understanding more about the DHF and its funding proposals and the commits that are happening. Give me a vote or comment if you like the post.

Comments · 9

  • @stoodkev(72)· 8d

    Hey! Sorry I missed your post, just saw the mention. You're pretty much right with you assumptions about the reduced pace

    • We pushed very hard to have a good Multichain Beta early and receive feedback
    • It's summertime so we both alternatively took some days off

    On top of this, we're working mostly on getting our multichain swap/ramp aggregator and this changes a bit our commit speed:

    • Lots of manual testing
    • Lots of admin (KYB to partner with ramp providers etc.)
    • Part of the code is private because it touches the core business that we will use to try and make Keychain sustainable without DHF in the future

    Now about your question: We only make a few hundred USD per month (currently more like $100+ actually) with the Hive swaps. Since there's no way this could fuel a sustainable activity (couldn't even cover our infra), what we're working on aims to propose multichain swap and ramp services for cheaper than, say Metamask, and generate additional revenue this way. Once we manage to generate enough to stop having to rely on the DHF, we can start buying back Hive and influence the price positively. That's what we described, but building the multichain wallet was not a quick task.

    About the update posts, that's a totally fair point, we promised regular (not weekly though) posts and one is long overdue, mostly because it will be a bit boring (we're still working on the swap feature) but yeah, my bad. This will be done before the end of the week.

    Thank you for raising important questions without trying to draw all the conclusions by yourself.

  • @seki1(71)· 15d

    This is quite a lot of data and information you've dug, it's insane.

    I'll probably need a few days to fully understand it and maybe leave a better comment.

    But peakd and ecency can be assumed to be more active because their sites are a bit more complex and has a greater user base than keychain, no?

  • @buttcoins(75)· 15d

    763BEF90-EA1B-4F01-8915-B05C3B2A1E44.png you are an investigative sleuth fine sir!

  • @molometer(72)· 15d

    Thanks for the analysis. Very useful to know what is or isn't happening with the various projects.

    It would be interesting to know the details about the swap fund earnings.

    I'm sure more people would use it if there was more transparency.

    Paekd is glitching as I write this comment. Might have to switch to ecency?

  • @jza(68)· 15d

    Amazing work and I hope we have more people looking into the operation of these projects. Also I think this is outside of the scope that Hive cannot support this pressure of debt. I would still push for a change on the DHF funding mechanism to switch to native Hive so that projects are more active in the action price as their expenses will depend on the best performance of the coins.

  • @jacobtothe(77)· 16d

    There is a visual glitch following your keychain chart. A page element doesn't seem to be loading properly, and everything below that just flickers. I am using PeakD, and I opened the article on Ecency and didn't see the same issue. I'm using Firefox on Android at the moment, for whatever that is worth. The flaw may not be in your post.

  • @kryptonita(71)· 16d

    @blanchy, lo de "Judge the shipped features, not just the churn" está bien fundamentado, se nota el research detrás.

  • @meesterboom(81)· 16d

    We love what you do auld feller!

  • @bozz(83)· 16d

    So many words... Thanks for parsing this out though.