A new fundraiser has been mentioned in forum threads and town hall, but the details are scarce on this. How can the community, especially those of us who are original investors, learn more? Specifically:
will you be selling a stash of the org’s SNT, or will you be minting more and diluting your tokenholders (since there still is a minting function in the contract) or is this going to be another token or another fundraising method?
what are you raising the money for, specifically?
how does this factor into liquid democracy and the DAOification of Status?
when will this be happening?
will it be open to the public, or will it be a VC round?
what’s the target?
why was the initially raised money not enough, can the community see a report of where the previously raised 100 million went?
will you use this opportunity to update the SNT token and remove the mint/burn functions?
I’m not privy to the actual answers to these questions, because they are not fleshed out and we as CCs expect to know more in January. Anything that comes up then will also more than likely be subject to discussion from the Stakeholders as that’s how we’ve always operated in the past, there is no reason to think we’ll change that as it’s core to our principles. It should also be noted that things are quiet during the holiday season, as we typically take time off to enjoy the humans around us during this time of the year. Here are my guesses at your questions:
It should be from the stash or org’s SNT. I do not believe we have any intention of ever using the minting function that is currently available. That functionality was more of a feature of the MiniMe contracts that we inherited during the ICO.
I’m not sure about specifics, but secured CC runway is probably a large part of it as the majority of our holdings are set aside for Status adoption when we feel we are ready for it. Furthermore, as many have learned during the ICO phase of Ethereum, although projects made significant money, the process lacks the wisdom and assistance that VC and investment partnerships bring to the table. It makes sense to me that a fundraising looks to benefit from these things.
Not sure, but we’ve been building more governance tools and ways to fund projects in the Status ecosystem that bolster the use of SNT, which helps everyone. Not sure why we wouldn’t take advantage of them where we can.
not sure, but we’ll certainly have more information early next year. Once again, discussion about the way forward may affect this.
zero idea, but order of magnitude guesses should be in the ballpark of what it takes to secure a reasonable runway for development of all projects we currently work on.
I think this is also a good question. From previous discussion I remember that being something we’d like to remove. How exactly we do this is also subject to discussion and vetting/planning to make sure it goes the way we expect.
Once again, these are all guesses based on my knowledge, understanding, personal opinions, and random conversations with other CCs. They don’t constitute any inside conversations or anything like that. I’m just trying to be transparent with my thoughts as I spend more time in this ecosystem than most so it stands to reason I have a more informed opinion.
Hey Bruno! Thanks for being understanding of the slow response over the holiday period. These are great questions, which we’ll answer in detail this month and next, and Corey’s reply is spot on in terms of the current thinking.
Given the way financing rounds tend to work, it seems prudent to ensure the structure / documentation (from a legal perspective and otherwise) is solid before we open up the discussion to all stakeholders publicly, so appreciate the patience on this - details are forthcoming.
I can however shed some light on this now: further funding won’t impact Status’ DAOification (see our Assemble project), and would provide greater long-term security for existing CCs. SNT from the orgs’ existing holdings would be sold, and we do not we foresee any SNT reaching secondary markets in the short-mid term. Additional funds would offer a number of benefits, including: a) providing stronger governance and accountability over the GmbH, and access to strategic partnerships. b) facilitate growth as we enter the next phase of the Status App; acquiring real-world users and catering to people beyond the crypto community (shortly after Waku we’ll have clear metrics on user acquisition costs for this). c) enable us to continue investing in infrastructure.
In regards to expenditure thus far, that seems like a good idea. Obviously the multisig is public and as an organization we don’t face liquidity problems. We’ve already begun adding these details in the quarterly reports (from which a lot can be gleaned indirectly), but after annual filings we could explore offering an annual retrospective with more granularity. I’m aware from prior ventures that funding can take many months, so it’s best to prepare very early - if we’re in a position to begin scaling our user-base at a reasonable cost per user (protocol scalability permitting), marketing costs will almost certainly increase drastically, hence the planning for this.
Hey, I dont know exactly how to answer all your questions, but there are some that I might help you figure out…
Not sure if this factor into LD or DAO. Status always loved Liquid Democracy and DAOs, and research & development is going on. The biggest problem of course is scalability & gas costs barrier, but also natural low user engagement due time costs and complexity of issues in vote.
There are many financial reports available on YouTube Town Halls that explain exactly how this funds were used, maybe someone else knows exactly the links, however you can also check the details on the blockchain itself. While its confusing to check blockchain, I found this tool very useful https://app.santiment.net/projects/status
These functions are not available in the SNT. While Status GmbH technically can upgrade the smart contract to include those functions, there are no plans in including them (as SNT is fixed supply), so I am not sure why you are asking to remove them. Perhaps you looking just MiniMeToken and not seeing that SNTPlaceHolder don’t allows mint and burn.
However Burn and Mint could become useful depending on the final design, for example, we could use burn function to pay to receive/send offline messaging/send reaction/whatever, allowing later a history node to mint it back as payment for delivering messages. In case that happens, the amount minted would not be higher then the max (current) supply.
We had some informal discussion on upgrading the token contract. I think that MiniMeToken itself is questionable in case of Storage Rent gets implemented, also with ETH 2.0, MiniMeToken could better serve us inside a shard, because of ETH 1.0 scalability issue.
I think that we should first see what ETH 2.0 will become to plan a token upgrade, for now, MiniMeToken is fine. Meanwhile Status is also researching on using L2 Scaling solutions, and also collaborating with ETH 2.0 for resource limited devices.
The functions can be called by the controller which is the placeholder contract which in turn can be changed to someone else by a multi sig if 3/5 parties agree. The new controller can then mint and burn.
As for financial reports on YouTube, those are vague estimates that nowhere near approach the 100m figure and it’s comical to even consider them reports, unless I again am thinking of the wrong videos in which case please provide links to the detailed ones. Please understand that investors more diligent than I will tear this data apart, and good explanations need to be in place.
The SNTPlaceholder contract not having access to the mint and burn function are enough. We are aware that this backdoor is against our principles, but we are working in fixing it. What you suggest as a better way of keeping the upgradability feature of Status Network? Rise the threshold of the multisig? How big is the security risk of someone else taking over the token contract and abusing this? @petty wdyt?
This is a standard used by many projects, and the alternative would be a DAO with direct democracy to upgrade, but this creates a whole other discussion on the implementation and security - which we are working on.
The mint and burn functions are part of the MiniMeToken, and it would be totally possible to wrap it around a controller that remove that functions , but why should we make our lifes harder by bloating the token contract and limiting it in case we need this in future?
As I told, there is plans on upgrading the Token contract, and I think is reasonable to remove the mint and burn functions if we are sure that we are not going to use this feature, and this is just one of the issues I see with MiniMeToken, that is good in other aspects.
Do you have any suggestions on what we should do on what you think is wrong? I’ll appreciate that.
Ive been a lurker for awhile, and I understand that Status had a 100mil ICO. How the heck did you guys manage to burn through that much capital and barely release a V1? Can someone enlighten me with the payroll numbers and give justification for this insane amount of spending PRE V1. Having to read that you guys need to start fundraising is giving me second thoughts about the leadership here.
We’ve maintained a reserve of ETH from the funds raised at the contribution period - precisely because we wanted to have resources set aside and ready for user acquisition once v1 is released. Check out our last published quarterly report for more info (see section 5 - funding), I think this should help with what you’re looking for, but let us know if any other questions. Cheers!
Well my suggestion is migrate to a new token that has no controller and no mint/burn at all. There is no excuse to ever need to mint more SNT, that’s not in the whitepaper and would go against many promises to original investors.
Burning can be done by sending to null, so why even have that as a function I don’t know, I guess it’s practical to be able to reduce supply in precise amounts and not rely on market cap sites and block explorers to deduct from the total based in null sends, but this function does not need to be behind a controller anyway - anyone should be able to burn their own SNT, and there is no reason for the org to have the ability to burn someone’s funds.
No multi sig is needed at all for the admin functionality, only for transfers, and yes I would agree with diversifying the key holders into more multisigs, perhaps one for each team in Status. Right now, the addresses that can do things are two dormant ones (0x6b9ef02657339310e28a7a9d4b5f25f7c1f68d61, 0x904ef6ff8e82478c5604d99884eb9bcd7f73cc36), one active address very much involved with Chainlink (0x02e3f16ca21cf0508835b190933ecbde2f7f14df), a cofounder of Aragon (0x4838eab6f43841e0d233db4cea47bd64f614f0c5) and the Status multisig (0xa646e29877d52b9e2de457eca09c724ff16d0a2b) which has as one of its owners this very multisig we’re looking at, looping permissions. That’s Carl and Jarrad probably being the other two owners of the multisig there. So this whole thing is very much sudo-enabled if you ask me.
it should be reiterated that these functions were inherited from the MiniMe token contract and there is no reason to believe anyone ever had any intention of using them. It is also reasonable to have them there (in the first place) as token standards were not what they are today which removes ideas on original malicious intent or “just in case” reasoning.
Moving to a new token contract is not an easy feat, I think there’s possibly better (less riskier) methods of achieving the same goal. It might be reasonable to just remove controller functions altogether at this point, but I’d need to make sure exactly what that entails. In case of emergency, a clone could be made with distributions at a given block which is about he same risk/work as migration. I’ve looked into setting this up so that it is ready at any given time.
The multisig could be expanded for better distribution of power. This could be done in a multitude of ways. I’ll explore options here to see what seems like a reasonable trade-off of coordination burden and security. That being said, the current multisig setups are as good or better than most projects, especially considering many people watch these addresses like a hawk (me included) that would sound the alarm at any suspicious behavior. I also think making sure all available constituents can still use keys so that we don’t have any loss of power distribution.
would an overview post of this functionality and how it’s controlled be useful for the stakeholders? It’s there for everyone to see but only if they know how.
Yes, I think such a post would be beneficial. Clarifying who’s who in the multisig and being open about what’s in the contract in terms of functionality and possibility would go a long way at re-establishing or enhancing credibility.
We considered this initially, there’s a certain level of idealism that is quite appealing with this approach, and a goal we’re working towards. Unfortunately there’s more considerations that require a more pragmatic and tempered perspective which comes from having skin in the game.
This course of action has put other token projects, such as OMG, at a serious disadvantage in the uncertain socio-technical landscape of our industry, they cannot add functionality to their token. At the same time, it’s unreasonable to treat it like a base coin, because in that context there is recourse in changing by making upgrade suggestions in the form of soft/hard forks, as you know, erc20’s and smart contracts don’t have that option.
Hopefully you can see why having the ability to administer a token is favourable in such a young, temperamental technology, the next question is usually some variant of “why isn’t this governed better than a multisig?”.
That’s pretty easy to answer, I am not aware of any mature governance project that is simple, robust and risk-free enough that can be deployed that can be responsibly used to manage locked capital. We are quite close with Aragon, as you have astutely pointed out they are on the multisig. When the risk of moving to a DAO is minimal, we will.
As for distributing multisig signatories further, we had looked into distributing responsibilities of signatories for parameter updates on other smart contract components of the application, and it was found out that it was not favorable for exposing our contributors to the legal risks when it includes loss of capital. Given the failure in that scenario, it’s even more unreasonable to attribute the exposure to loss of value on the token.
The other issue here is that Carl and I control the salaries of the contributors, therefore I would be surprised if the community viewed these signatories to be considered more trustworthy, they should be people that are well reputed in the community and independent of Status.
The signatories that were chosen because they have very little social overlap and we find them all ideologically aligned and responsible. They certainly wouldn’t appease neither Carl or Myself unless they thought it was in the best interest of the greater community and for their reputation.
Citations for the owners of the keys are to be found here, and the outline of responsibilities have been publicly available since the beginning:
To have access to any of the functions discussed here, we would first have to update controller, which is the real concern, I suggest you setup a monitor for a contract call to this function to dump all your SNT holdings when triggered:
Understand that this a burden of risk & responsibility that I do not want for myself nor would wish to impose on anyone else, and one I suspect we will shed ourselves of within the next 2 years.
And of course, there is the ultimate recourse for you, if you are not satisfied with the current setup and reasoning, then you do not have to hold SNT.
Hey Bruno! @carl’s previous message committed to getting back on these questions “in this month and the next” (i.e. by end of Feb) - we still are working on fundraising and there’s no additional update to give yet, please bear with us. Thank you!