HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
compound-finance
compound-protocol
TypeScript2021–2021
compound-finance / compound-protocol

compound-protocol

The Compound On-Chain Protocol

2Distinct people
2Mentions
0Explicit recommenders
2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Compound On-Chain Protocol

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day2 dated mentions

Observed mentions: 2021-10-19 03:48:26 UTC to 2021-10-30 19:08:38 UTC.

012021-10-19 00:00:00 UTC to 2021-10-20 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 192021-10-20 00:00:00 UTC to 2021-10-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-21 00:00:00 UTC to 2021-10-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-22 00:00:00 UTC to 2021-10-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-23 00:00:00 UTC to 2021-10-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-24 00:00:00 UTC to 2021-10-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsOct 242021-10-25 00:00:00 UTC to 2021-10-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-26 00:00:00 UTC to 2021-10-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-27 00:00:00 UTC to 2021-10-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-28 00:00:00 UTC to 2021-10-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-29 00:00:00 UTC to 2021-10-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-10-30 00:00:00 UTC to 2021-10-31 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 30

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Oct 192021-10-19 00:00:00 UTC2021-10-20 00:00:00 UTC101
Oct 202021-10-20 00:00:00 UTC2021-10-21 00:00:00 UTC000
Oct 212021-10-21 00:00:00 UTC2021-10-22 00:00:00 UTC000
Oct 222021-10-22 00:00:00 UTC2021-10-23 00:00:00 UTC000
Oct 232021-10-23 00:00:00 UTC2021-10-24 00:00:00 UTC000
Oct 242021-10-24 00:00:00 UTC2021-10-25 00:00:00 UTC000
Oct 252021-10-25 00:00:00 UTC2021-10-26 00:00:00 UTC000
Oct 262021-10-26 00:00:00 UTC2021-10-27 00:00:00 UTC000
Oct 272021-10-27 00:00:00 UTC2021-10-28 00:00:00 UTC000
Oct 282021-10-28 00:00:00 UTC2021-10-29 00:00:00 UTC000
Oct 292021-10-29 00:00:00 UTC2021-10-30 00:00:00 UTC000
Oct 302021-10-30 00:00:00 UTC2021-10-31 00:00:00 UTC101

What Hacker News says

2 sources
Yep however I don't think I'd consider it to quite the same extreme. No doubt it was bad however proportionally to the size of the platform Cream's exploit was far more damaging. Like the rekt.news post mentions, it was more of a banking/spec error than an outright vulnerability. Your spec can't protect you if the loss is due to intended behaviour. There are ways to mitigate this however. The main way is by making your spec concise and clearly representable as a series of state transitions & operations or as a series of transformations. The Compound Finance paper spec essentially just lists "this subsystem does these things" and then each function/operation is a list of preconditions, what actions are taken in what conditions, and the expected result. This isn't bad per se but it's not great either. Instead the paper spec really should be
Read the rest
showing what transformation is being applied to the state, why we want that transformation applied, what properties must hold throughout the transformation, and then demonstrating that those properties hold. Compare this (Compound): https://github.com/compound-finance/compound-protocol/blob/m... https://github.com/compound-finance/compound-protocol/tree/m... to this (Uniswap): https://github.com/runtimeverification/verified-smart-contra... https://github.com/runtimeverification/verified-smart-contra... or this (Djed): https://eprint.iacr.org/2021/1069.pdf The first just describes the system and then asserts preconditions hold which works well enough for verifying that the code matches the spec but the other actually verify that the spec is doing what the user & developer expect it to by formalising the system and analysing the properties of that system. Compound's project wouldn't have been vulnerable to any of the attacks executed on CreamFi however they are vulnerable to the class of spec errors. Uniswap and Djed on the other hand would be protected from the majority of that class of issue that Compound experienced. This isn't to say that they are invulnerable but I'd be willing to say that they are approaching "cryptography-grade" security where you can trust these protocols just like you can trust AES, RSA, and ECC encryption & signing. --- This of course isn't to say that what Compound does is bad but as that incident shows, there is still room for their improvement in the security space. Cryptocurrency and "Decentralised Finance" are finally starting to grow up into proper subsets of the cryptocurrency and game theory communities. Now this might be a bit of general commentary on the SW space but hopefully long term this trend causes some of this security minded design to bleed over into the greater software engineering community.
In Cryptocurrency loan platform implodes in $130M hack
> How are these companies providing 8%+ return on stable coins? Aave/Compound/Curve/Benqi <- decentralized non custodial overcollateralized lending protocols. These centralized and incorporated companies [basically a big bulls eye saying "please screw me over, here, I'll make it very easy for you for governments"] use Aave/Curve/Compound on behalf of their users who are too lazy/ignorant to do it themselves, plus maybe some economies of scale with cost of gas fee on ethereum. Right now on benqi (compound fork on avalanche), one can supply DAI and get 8.09% APY in DAI alone (there's more APY in other tokens but I don't like to count those since those incentives come and go), but it fluctuates based on borrower demand/pricing model used in the smart contracts [0]. By supplying DAI, using it as collateral to borrow more dai (up to 75% for da
Read the rest
i, different collateral factors for non stablecoins, i think max 60% of collateral value, some with 0%[which means it cannot be used as collateral but it can be lent/borrowed, USDT is like this]) and then depositing it back in again, you can get more yield on that minus the borrowing costs if there are protocol rewards/incentives to be liquidated for more dai. There's also providing stablecoin <-> stablecoin liquidity on dexes and collecting fees on each swap. [0]: compounds jump rate model: https://github.com/compound-finance/compound-protocol/blob/m...
In Attorney General orders unregistered crypto lending platforms to exit NY

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.