HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
blockchainsllc
DAO
TeX2016–2021
blockchainsllc / DAO

DAO

The Standard DAO Framework, including Whitepaper

Explore on GitHubRead Hacker News discussions
18Distinct people
21Mentions
0Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Standard DAO Framework, including Whitepaper

GitHub

Where it is used

No documented product use was verified in the last source check.

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:03:38 AM 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 year21 dated mentions

Observed mentions: 2016-04-04 01:12:46 UTC to 2021-12-06 21:14:51 UTC.

051015202016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 18 mentions; 1 submissions, 17 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

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
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC18117
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

18 sources
nullc·Jul 15, 2016
The website says: (https://daohub.org/explainer.html) By Creating DAO tokens through interaction with The DAO’s smart contract code, you expressly agree to all of the terms and conditions set forth in that code. If you do not understand or do not agree to those terms, you should not Create DAO tokens. [...] The DAO’s smart contract code governs the Creation of DAO tokens and supercede any public statements about The DAO’s Creation made by third parties or individuals associated with The DAO, past, present and future. The software code currently available at https://github.com/slockit/dao is the sole source for the terms under which DAO tokens may be created
In Kraken confirms July the 20th #ethereum Hardfork
gus_massa·Jun 19, 2016
This is essentially the "Stalker Attack" discussed a few weeks ago as a failure in the DAO in http://hackingdistributed.com/2016/05/27/dao-call-for-morato... (related HN discussion https://news.ycombinator.com/item?id=11791671 (170 points, 22 days ago, 81 comments)) If they succeed blocking the attacker, then they'll also prove that nobody has a guarantee to withdraw any money from the DAO. Somewhat related: "Why The Stalker attack is a non issue" https://github.com/slockit/DAO/wiki/Why-The-Stalker-attack-i...
In DAO Counter-Attack
niftich·Jun 19, 2016
Not sure if this is exploiting the same bug as the first split. But commenters on yesterday's thread have noted [1] that the DAO code currently executing seems to be several days older, and out of sync with the newer github repo [2][3]. This is one way to get a free code review /s There was an issue raised on their repo to make exploitable bugs private [4]. So far it doesn't appear to have gained traction but I wonder, what will it say about decentralized communities, and the focus on the sanctity of their code as a contract, if it's accepted. [1] https://news.ycombinator.com/item?id=11928936 [2] https://github.com/slockit/DAO [3] https://github.com/TheDAO/DAO-1.0 [4] https://github.com/slockit/DAO/issues/264
In Another successful DAO attack recursive split
jrpt·Jun 19, 2016
This was a bug in the DAO, not Ethereum. From what I read, this was the bug: https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... I'm not sure why you'd find this satisfying, unless you hate innovation. Also, I agree that the same Dapps can be run with Bitcoin, so it's not like everyone needs to switch to Ethereum. It does have some advantages over Bitcoin, though that might not be enough given the huge adoption Bitcoin has already.
In Another successful DAO attack recursive split
winteriscoming·Jun 18, 2016
If I understood the explanation on that article correctly, what's even more interesting is that this typo apparently hasn't yet been fixed in the repos (assuming I'm looking at the right ones). There are 2 repos which I looked at: https://github.com/slockit/DAO https://github.com/TheDAO/DAO-1.0 I don't know which one is the authoritative one. But the interesting bit is both these repos still have that same typo in the master branch: https://github.com/TheDAO/DAO-1.0/blob/master/DAO.sol#L666 (the other repo) https://github.com/slockit/DAO/blob/develop/DAO.sol#L685 The slockit account repo has a commit which was made 6 days back, with the commit message "Protect against recursive withdrawRewardFor attack" https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... but it doesn't fix the typo and there aren't any more commit in there aft
Read the rest
er that one. Does this mean, the upstream repos containing the typo haven't yet been fixed? Or am I just looking at the wrong repos/branches? Or did this typo get known only a few hours back?
In Deconstructing the DAO Attack: A Brief Code Tour
zenogais·Jun 18, 2016
You're also talking about systems 20,000x larger than what The DAO contract was [1]. The total DAO contract is roughly 2,000 LOC by my estimate [2]. IMO it probably won't be overly onerous to develop reliable contracts of this size using many of these techniques. It's just so few people have the discipline to delay implementation for design and planning at the level required when it needs to be bug free. Most software developers have no training in how to even begin designing and developing using these techniques. [1]: Shuttle's primary flight software contains 400,000 LOC http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_... [2]: https://github.com/slockit/DAO
In Bloomberg – Blockchain Company's Smart Contracts Were Dumb
amluto·Jun 17, 2016
Wow, theDAO has a shockingly cavalier attitude to security (https://github.com/slockit/DAO/wiki/The-DAO-v1.0-Code): > At the time of deployment, it was discovered that the solidity compiler is not deterministic. AST nodes are identified by their raw pointers. So if we iterate over data structures, different raw pointers might result in a different iteration order. > We originally wanted to let the community deploy The DAO and then just check the bytecode, but this was not possible at the moment of deployment. So instead a fixed transaction bytecode was provided for the community to deploy. Shouldn't they have waited to deploy until they figured out how to make it verifiable?
In Critical Update on DAO Vulnerability
benmmurphy·Jun 17, 2016
My guess at how the attackers are doing it: They are calling splitDAO: https://github.com/slockit/DAO/blob/develop/DAO.sol#L618 splitDAO calls withdrawRewardFor which ends up calling back into the users contract. https://github.com/slockit/DAO/blob/develop/DAO.sol#L686 withdrawRewardFor(msg.sender); // be nice, and get his rewards totalSupply -= balances[msg.sender]; balances[msg.sender] = 0; paidOut[msg.sender] = 0; the state is modified after the callback in particular the balances variable. however, earlier in the function it moved funds to a new dao based on the balances variable. // Move ether and assign new Tokens uint fundsToBeMoved = (balances[msg.sender] * p.splitData[0].splitBalance) / p.splitData[0].totalSupply; if (p.splitData[0].newDAO.createToke
Read the rest
nProxy.value(fundsToBeMoved)(msg.sender) == false) so presumably an attacker can call splitDAO and then recursively call splitDAO and the funds will be transferred twice. there is also some complications around rewardToken because this state is modified before the callback but apparently it is all zero at the moment. if this is the bug the attackers are exploiting then maybe if they generated rewards it would stop the drain of funds. however, the fact the draining is still going on and the DAO people are likely to know how they are doing it and it hasn't been stopped reduces my confidence that this is how the attackers are doing it. EDIT: to add i don't think you can cash out the new DAO for 28 days so this is probably not how the attackers are doing it. EDIT: update again. https://blog.slock.it/dao-security-advisory-live-updates-2a0... 'It would appear the attacker has moved the stolen ether to a child DAO, which means that the funds be moved for at least 27 days.' -> i'm now fairly confident this is how the attack worked :)
In Critical Update on DAO Vulnerability
benmmurphy·Jun 17, 2016
I'm not expert on etherium code (just started looking at it now) but it looks like the DAO didn't look for similar issues with the latest security fix. https://github.com/slockit/DAO/commit/f01f3bd8df5e1e222dde62... reward = rewardAccount.balance < reward ? rewardAccount.balance : reward; + paidOut[_account] += reward; if (!rewardAccount.payOut(_account, reward)) throw; - paidOut[_account] += reward; + return true; } but if you grep payOut then you see a similar broken pattern where it modifies the state after the call instead of before it. if(_toMembers) { if (!DAOrewardAccount.payOut(dao.rewardAccount(), reward)) throw; } else { if (!DAOrewardAccount.payOut(dao, rew
Read the rest
ard)) throw; } DAOpaidOut[msg.sender] += reward; but apparently this is not how the DAO is being drained because there are no rewards at the moment. this is a good summary of the problem: https://blog.ethereum.org/2016/06/10/smart-contract-security... and should scare you about the security of smart contracts base on etherium. EDIT: mm.. maybe it is safe because the addresses dao/dao.rewardAccount() can't be controlled by attackers
In Critical Update on DAO Vulnerability
ThomasRooney·Jun 17, 2016
- I don't think there's any definitive details yet, but it could be an instance of this attack [1]. The code behind the DAO is available here [2]. Apparently [3], there's a bug where one can recursively call `splitDAO` multiple times to extract ether from the contract if one has a split open. - Ether can go missing when it is sent to a public address which has no known corresponding private key. It's a "we can't inverse a hash" type of problem. - People lose if they're holding a long position on ETH, or have DAO which they can now no longer recoup to ETH. People gain if they're shorting ETH, or are the attacker themselves (it looks like the ETH from the dao is going to this address [4]) - Looks to be an existential threat to the DAO from where we're standing right now. I can't see any mitigations but an entire Ethereum blockchain split. [
Read the rest
1] https://blog.slock.it/no-dao-funds-at-risk-following-the-eth... [2] https://github.com/slockit/DAO/blob/develop/DAO.sol [3] http://pastebin.com/DykumjLs [4] http://etherscan.io/address/0x304a554a310c7e546dfe434669c628...
In Critical Update on DAO Vulnerability
drcode·May 25, 2016
1. Well, it's a bit more complex- DAO investors give up direct ownership in ether when they participate in the DAO in exchange for DAO Tokens. You're right that there could be some maligned incentives, but they fall on both sides of the ether valuation to a certain degree. 2. While the non-professional voters have little ability to do proper diligence, they DO have a mechanism for hiring outside parties to do diligence. 3. What complexity? Here's the source code, it's pretty darn simple: (https://github.com/slockit/DAO/blob/master/DAO.sol) Also, I think the DAO solves two problems: First of all, VCs and VC lawyers and Hedge funds have enormous secondary costs that the DAO avoids entirely. Secondly, VCs and fund managers also have enormously maligned incentives which may affect their performance. (Note: I am still a skeptic of the DAO and
Read the rest
did not participate in the experiment)
In Is the DAO going to be DOA?

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

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.