The Bitcoin Markets slack channel hosted Anurag, Shane, Noah, Nahom, and me for their first AMA yesterday. As in our previous AMA, we received a lot of important and insightful questions! For those who were unable to participate, here is a recap of the questions and answers. Thank you again to Bitcoin Markets for hosting us, and to our awesome community!

Q (khonsu): How does Snowflake relate to other identity protocols out there like Civic and uPort?

A.1 (Anurag): We see snowflake existing as a layer below these types of projects. Even without blockchain, identity is a broad term. Different people around the world have different forms of identity (state ID, country ID, social media IDs, etc). Civic, uPort, and other blockchain projects help to build specific types of an on-chain identity for a user; however those IDs are meaningful in different ways to different observers. For instance, imagine that a government or business builds a system that accepts Civic as a form of identity while another government/business only recognizes uPort identities. On top of this, certain systems only care about information tied to a user’s social media profile. A user can maintain one standard Snowflake as a base layer and set each of these different forms of identity as a resolver. Snowflake eliminates the need for global unanimous adoption of a singular identity standard and rather allows systems to build business logic off of identity standards they themselves recognize.

Follow up Q (khonsu): thats cool. so its totally depends on the person/ institute utilizing it . One problem I found is how easy its to create fake identities (in their basic system).

A.2 (Anurag): Yup! So people can conduct off-chain verifications to prove that you own a snowflake, and then tie an on-chain verification to your Snowflake. This links real-world KYC to your on-chain ID, so sure you could mint another snowflake, but that same party won’t validate it again for you. Anyone who trusts that party would be able to accept their validations, and people who don’t trust that party can rely on a different validator they do trust.

Q (kat): How big is the team working specifically on Hydro products? Can we get a numbers breakdown of engineers, biz dev, etc? Do you have plans to scale this team as the Hydro project develops?

A.1 (Andy): Our Hydro team is 8 people.Devlopers (Myself and Noah)Product (Anurag and Shane)Community (Nahom)Founders (Mike and Matt)Partnerships/BizDev (Gunjan)The nice thing about Hydrogen though is we have a team of 30 people who we can leverage for different things. For example, Noah and I do not build mobile apps, but we have a front end team that is well versed in mobile app development. So while they are not directly on the Hydro team they do have a direct impact on Hydro.Hydrogen as a company is working to grow pretty rapidly. As we grow we will be filling out more positions in both blockchain and non-blockchain rolls.

A.2 (Anurag): To add to Andy’s answer — pretty much everyone working for Hydrogen helps out with Hydro in some way, whether via design, front-end development, API support, business discussion, etc.Here’s our full team

Q (rocket man): So in the age of ICOs, what motivated your team to not pursue that funding model and instead have a token distribution for developers?

A (Andy): This was something that we spent a very long time considering and discussing. We spent a lot of resources (time, money & energy) trying to find the best solution for us going forward. When it was all said and done, we decided on an airdrop because of two main things, getting the token into the hands of people who will actually use it and regulatory concerns.We feel as though our distribution was the fairest approach that allowed for people with actual interest in the Hydro community to get involved. Overall, we have been very pleased with the level of community engagement from people who are interested in the utility of the Hydro token and we feel that a lot of this can be credited to our distribution strategy.

Q (matheussiq8): How hydro tokens will be used is still vague in the Snowflake whitepaper draft. Would the amount required to hold depend on the volume of API calls or some other parameter? For example, if I decide to implement raindrop and later snowflake in my small webshop would I need to hold the same amount of tokens as Binance (if they ever implement it of course…)?

A (Noah): As always, the permissionlessness of public blockchains is a double-edged sword. smart contracts partially solve the problem by letting us enforce certain things on-chain (minimum token balances, signature validity, etc.), but there are limits. So, regarding your specific question: in raindrop we do not vary the staking requirement across users, because that would necessarily involve value judgements we are not comfortable making as a centralized entity. However, there are two types of staking required for raindrop:1) “institutional staking” requires entities who wish to sign up raindrop users *on their behalf* (i.e. passing new users’ addresses to the smart contract as parameters rather than new users transacting directly from their accounts) to stake a significant amount of hydro. These are the players we want to ensure are acting in the best interests of the community. in this model, hydro is simply one of many institutional stakers (where we sign up users on our kickass mobile app, which will be out soon).2) “user staking” requires individuals who wish to sign up for raindrop on their own, i.e. transact directly with the smart contract, are able to do so by staking a much smaller amount of hydro.What this all means for you, as a potential customer of our API, is that you don’t actually have to worry about the staking requirement or signing up users at all, and can simply use our API in conjunction with the Hydro app.Looking ahead to Snowflake, we have big plans to integrate increasing sophisticated uses of the token into the product. to some extent these are still up in the air, but rest assured that we are very focused on building a strong tokenomics structure. At a high level, the core token mechanism for snowflake will involve depositing tokens into the snowflake smart contract. These deposits will allow native staking/payment/incentive functionality denominated in hydro, without the hassle and worry of using ether with every call.

Q (Jeff_We_Cannafi): To piggyback on matheussiq8’s question, how do these identity tokens compare to existing forms of identity authentication, and do you anticipate the tokens themselves will be traded on exchanges?A (Andy): In my opinion, the main difference between what we are working towards and others like civic and uport is the scope of what we are aiming to do. We understand the value of having KYC on the blockchain and “One click signup”, but really I think blockchain identity can be so much more than that. We are aiming to create a completely extendable and modular protocol which will allow for people to link anything they desire to their blockchain identity. Other protocols can tend to lean towards centralization (more a fault of current KYC procedures than the projects themselves) and we feel like this doesn’t have to be the case. At least for now, something like KYC needs to have central authorities to verify user information, but why can’t I also link my crypto kitties to my blockchain id or my linkedin profile to my blockchain id?Overall, what we are trying to build will easily allow for other blockchain developers to create robust identity solutions for whatever application they feel fit with Snowflake being at the core of that. We feel that this is crucial to eventually creating a completely open and decentralized identity system. Anyone can join and anyone can add what THEY consider to be an identity, but I only have to accept what I consider to be an identity.As far as trading, Snowflake Identity tokens will never be tradable. We feel that your identity should always be linked to you. This would be a dangerous road to a very easy black market for people’s identities.

Q (Jrock): What do you find the hardest part of pitching icos to regular companies?Also what do you think needs to happen for widespread crypto adoption?

A (Shane): If you mean pitching Hydro to regular companies (we’re not an ICO), I would say the hardest part is getting the larger companies to move faster than a snail’s pace. There are too many chefs in the kitchen and sometimes there is a lack of top-down strategy on blockchain, and it leaves large enterprises paralyzed sometimes. We try to resolve this by pitching how easy Hydro is to use, and how it connects to our broader Hydrogen ecosystem which can add value in a lot of places.In my opinion, widespread crypto adoption is going to be dependent on how parallelization plays out. If crypto’s only option is to create a new parallel economy, widespread adoption is going to be slow and arduous and will take decades. However, if blockchain is able to be infused or layered on some of the current systems we have in place, the adoption will be much faster and broader. Ultimately this comes down to the usage of private vs public chains— the more private and centralized chains that get implemented, the farther the mainstream adoption will get pushed out.

Q (Luke): One aspect of Hydro that is beginning to really intrigue me are the potential use cases and dapps that can be built by external developers ontop of the Hydro protocol layers for each phase.1) Having held various dev meetups and networking at various conferences, how are you finding the process of attracting developers to start building dapps and products in your ecosystem?2) I understand the HCDP is getting updated with various new rules and bounties for dapps to be built, have you approached any developers yet with this new offer, and if so, how has the reception been?3) How else do you intend to attract developers towards building on the Hydro protocols?

A (Anurag):1) Through our events, we’re mainly focused on helping expand the blockchain-focused developer community. We help give exposure to projects we find to be doing neat, innovative work in the space and keep ongoing dialogue with these communities.2) In particular, to provide impetus to developers in the Hydro ecosystem, we’ve established the HCDP. The new process will involve putting out specific task requests. In the next week or so we’ll have published specifications for dApps that can be built on top of Snowflake. We ourselves will not be building these dApps (they have nothing to do with Hydrogen’s space as a company). This helps the ecosystem expand outside of Hydrogen-specific use-cases.3) ^^Through the above process to get them started. Eventually, we want the Hydro development process to be community-driven, so people are building on Hydro because it benefits their own programs and applications.

Q (elmer_FUD): Hey Hydro Team! Here’s a few question I’ve got for you after checking out the Raindrop and Snowflake whitepapers:How has your experience working in the Ethereum ecosystem been so far?While you are currently focused on the financial sector, would you consider actively marketing to other sectors such as healthcare and education in the future?It seems like both Raindrop and Snowflake would be useful in any environment that processes or stores sensitive data.Do you have plans to release official Raindrop SDK packages in other languages in the future?A bit more of a specific question: Raindrop is looks like a great product to use in a PCI-DSS environment — do you have thoughts on whether or not it the product is ready for primetime and do you think the industry standards and government regulation is prepared to handle these kinds of systems?

A (Andy): Overall it has been pretty solid. There is still a ton of room for growth in terms of documentation and stuff like that, but it is miles ahead of basically every other blockchain platform I have worked with. By far the biggest pain has been handling gas costs when considering the user experience. When trying to build actual products that people will want to use we feel that making it user friendly is something that many blockchain projects have not focused on nearly enough.Yeah certainly. We focus on fintech as that is where the rest of our companies APIs focus and that is where we have the most connections, but much of what we are building is much further reaching than that. Just as far as authentication goes, it really can apply to any major field and we intend to market it as such.We currently have Python and JS SDKs and have had a few java ones submitted through our community dev program. We have been revamping that program, but I anticipate we will be putting up more bounties for most major languages. I have considered making a few more myself, but we feel that they could be better suited as community projects.I completely agree. Raindrop and blockchain authentication when handling anything around payments is a great application. I think the biggest thing is actually convincing regulatory bodies that the protocols we have built are secure (since many can still be scared of blockchain). I definitely see this as a direct use case though.

Q.1 (khonsu): What kind of banking relations do you have as a company, do they (banks) understand what you are trying to do ? Any VCs approached you for funding ? explain your business model.

A.1 (Shane): Hydrogen has existed since 2009 in the form of Hedgeable. Hedgeable is a consumer-facing online investing app, and the tech behind it eventually spawned the Hydrogen tech platform. The story of how the transition happened goes essentially like this: (1) Hedgeable was disrupting banks & investing firms, (2) banks & investing firms started contacting us and seeing if we would help them digitize & automate their own businesses, (3) we started packaging up our tech and selling it to the banks. There was so much demand for this from financial institutions that we spun out a new company (Hydrogen).So to get back to your original question: we have some long-standing relationships in the banking & finance world, and to this day we have inbound leads from that space coming in every week. The key thing to keep in mind is that these institutions move extremely slowly, but they do understand the core value prop of our platform. Many of these firms are still in the midst of basic digitization efforts (i.e. moving from really slow offline processes to simple digital infrastructure), and that is the primary thing we are helping them with in early stages. But they are also keen on blockchain tech and they will naturally turn to us for that once they reach that point. We do have a few relationships with big financial companies in which Hydro/blockchain are already part of the discussion.We have revenue and don’t need to rely on VCs. It is our general philosophy that building a business sustainably with actual clients and revenue is a good approach, but we would consider working with the right VC if that came to be and we wanted to scale more quickly. Right now, that is not an immediate concern for us.Our business model is in charging developers and enterprises to access the Hydrogen technology platform, which currently consists of products like Atom, Ion, and Hydro. Developers pay a per-user fee to hit our core APIs, while large enterprises negotiate custom (usually multi-year) contracts with us that typically include recurring revenue. Hydro, specifically, is being offered for free right now, as we attempt to gain adoption. But it is important to note that Hydro is just one piece of our ecosystem.

Q.2 (Joleen): When you say fee — is this fee HYDRO? And when do you envisage HYDRO to no longer be offered FOC?

A.2 (Shane): Sorry if it wasn’t clear, I meant free to use our Hydro tech/APIs. The usage of HYDRO tokens within that is a separate issue — they still need to have HYDRO and we do not give it away for free to clients.

Q (guacam0le): Adoption of an identity management solution (etc) would potentially involve a lot of identities. Further, scalability is a hot topic w/ blockchain. Is this a potential bottleneck? What is or might be done to address such?Tackling a competitor like Google or Authy’s 2FA is no small feat. Also, not everyone is yet to embrace blockchain-based solutions. Have you found it difficult to interface with enterprises & get them excited about the idea of an overhaul?

A (Anurag): Snowflake is designed to be relatively low-load on the blockchain. A user needs to conduct a single transaction to “mint” their Snowflake. Once this is complete, they would need to complete one-time transactions to set each of their different forms of identities as resolvers as needed. A Snowflake is designed to be built out via resolvers over the duration of a user’s lifetime, so there’s never a need for heavy, frequent transactional capability. Similarly, smart contracts simply need to be set as resolvers by users; they do not themselves transact. Network scalability improvements will increase the range of use-cases for smart contracts that can be tied to Snowflake, but they aren’t a necessary prerequisite to some important early use-cases such as KYC platforms, and a few basic user-interaction platforms.As far as competition, we feel that current adoption of 2FA is, in general far short of where it should be, and any 2FA is generally better than none. Many businesses use text-message based 2FA, etc. In the short-run we are aiming toward pilot implementations with small businesses. To further this, we have put out many integration resources, guides, and documentation and accordingly believe implementation of Raindrop is a more straightforward workflow. As far as large enterprises go, Hydrogen has clients, so it is helpful for our project to have those connections. Large institutions are generally relatively slow-moving, but have expressed interest in using Raindrop, in particular for securing employee accounts. As the product grows, we may eventually move in this direction with Client Raindrop, but resources will always be available for any site that wants to adopt it. Additionally, we are looking into making a wordpress plug-in to make implementation much more accessible for many developers.

Q (khonsu’s mumaffi): Ill be honest i have not yet fully read the whitepaper but id like to know other than investor growth do you truly believe there is interest in a model where users have to pay each time for access? How big do u expect this fee to be…for large companies dont you believe this is an unscalable practice? This may be a question more about most technologies built on token based economics too.

A (Andy): So we have 2 different authentication protocols. One happens less often and is in the same vein as OAuth. This is called Server-Side Raindrop. This requires tokens to be sent. This protocol would only happen once per day for a business when accessing something like an API. I don’t feel that these values are extremely high for increased security.Our second protocol, Client-Side Raindrop, functions much more like google auth. This logic actually does not require any tokens or even a transaction by the end user. It is 100% free for them to use and they will never have to pay for a transaction. Here the responsibility is on the implementing party to stake tokens. This allows them to onboard users and authenticate them.We felt it was crucial to have an authentication that did not have a cost per user login as it is not scalable.

Q (ghost): As a company in the space, do you see the fact that tokens have to be acquired on exchanges as an issue? How would a company that wants to develop with you acquire tokens?

A (Anurag): Depends on what they’re developing. dApps developing using Hydro smart contracts to create native functionality to their applications would need to acquire those tokens on their own; however, companies using the Hydrogen API will not. Here’s a detailed article outlining when a developer would need the token for the Client Raindrop smart contract

Q (khonsu’s mumaffi): Also do u plan to tokenise atom and ion too and if not covered earlier how big of an impact do the market conditions have on your business

A (Anurag): Tough to say we’re going to “tokenize” them since that word can carry a lot of different meanings in different contexts, but we do plan on integrating the entire Hydrogen platform with Hydro. This will most likely take the form of enhancements to systems leveraging Hydro. You can find a more detailed breakdown on our Hydro roadmapMarket conditions don’t really have an impact — we’re still building the same tech on a day-to-day basis.

Q (jarederaj): Can you describe your stakeholders and give me a better sense of the exigency of your products? Who are you focused on serving with your platform and why are they motivated to use your platform?

A (Shane): The Hydrogen platform serves developers and enterprises who want to build applications. We are specifically targeting the financial services sector, including banks, investing firms, insurance providers, and financial advisors. This includes large enterprises, individual developers, and startups.Our products are Atom (core digital infrastructure & engine for finserv), Ion (AutoML & business intelligence capabilities), and Hydro (blockchain & decentralization layer). Each has a different use case but these products combine to form an ecosystem of tools for developers to build sophisticated applications with.The main pain point we are addressing is the resources required to build, launch, and run a digital financial application. These resources include both time and money.Large enterprises have resources, but they waste years and millions of dollars trying to launch digital platforms (we’ve seen this first-hand), often unsuccessfully. The motivation here is obvious. Startups and smaller developers, on the other hand, do not have access to huge resource pools, so they are forced to look for solutions that make the process more efficient.In the same way that Wordpress makes launching a blog easy and also allows for extended functionality, Hydrogen makes launching fintech applications easy.