Devvio’s vision is to create the world’s infrastructure for transferring value. Devvio has created the world’s fastest blockchain as well as the only solution that addresses all of blockchain’s biggest challenges such as scalability, cost, stability, fraud/theft/loss and privacy, in a single solution. The following Frequently Asked Questions (FAQ) lists many common questions we have gotten, along with the answers. A good place to ask any additional questions is at Devvio’s Telegram group located here. Most of these questions have come from the Telegram group.
Devv is both a blockchain protocol and a cryptocurrency created by Devvio, Inc.
Devv is primarily addressing scalability, cost, stability, fraud/theft/loss, and privacy. When we first started looking into blockchain, there were no solutions that addressed all of these problems in a single solution, so we designed our own protocol from scratch. If one builds a house without a solid foundation, nothing good will come of it. Devv is unique in our sharding solution (we have recently benchmarked at over 8 million transactions per second), our privacy solution which is meant to work within government regulation, our fraud/theft/loss protection capabilities, our efficient and inexpensive Smart Contract solution (using Smart Coins), and our stable coin implementation.
The Devv cryptocurrency can be used for payment in Devvio’s Blockchain-as-a-Service business.
Devvio wants to build the world’s infrastructure for transferring value. We intend to create one of the most powerful blockchain solutions, and let many other people implement their blockchain needs on our platform, growing our Blockchain-as-a-Service (BaaS) business. We have the ability to create inexpensive, scalable, and secure Smart Contracts which also leverage our other protocol features (fraud/theft/loss protections, privacy, etc.). There are some vertical markets we would like to focus on ourselves as well, such as financial transactions (remittance, exchange, and payments).
The Devv cryptocurrency is intended as a general purpose cryptocurrency as well as the currency we will accept for our BaaS business. Purchases of Devv can be in essence pre-purchases of Devv blockchain utilization. The Devv cryptocurrency has advantages over other cryptocurrencies. It has fraud/theft/loss protections, privacy that will work within regulatory environments, and scalability to millions of transactions/second. Devv also will be used on our BaaS business — customers can pay for their token usage in Devv. Devv’s Whitepaper lists a number of use cases (in the Use Cases section) for both the cryptocurrency and the blockchain.
Ripple, EOS, and Hashgraph have similar technologies and could be competitors with us.
One thing to keep in mind is that the entire blockchain space is in its infancy. In 1999 many people were dismissive of Google. Blockchain is a fast moving and quickly changing space. The landscape in a couple years will be dramatically different than it is now and our goal is to be a leader in the space. We feel one of the main reasons that we can become a significant company and technology in the space is that we address the issues that larger institutions and enterprises want to see to fully embrace blockchain. We solve the problems that large entities need to have solved to use blockchain broadly. We envision we will be seen as “THE Enterprise and Institutional blockchain solution”.
Yes, IP was a core focus for us from the beginning. We believe we will own some significant blocking patents for some important concepts in the space. Our team has a great deal of expertise in Intellectual Property. The first thing we did for Devvio when we were starting the effort was patent all our ideas before we told anyone anything about what we’re doing. That’s part of the reason we’re so far along but still under the radar.
Yes, we have a large list of industry partners we’ve spoken to, and there appears to be a lot of interest in our solution. Our team has a lot of experience in corporate development, and our solution solves many of the biggest problems enterprise customers are struggling with.
We understand this question as we have often received this feedback. On the same note, we have wondered why no one else has addressed many of the problems we have solutions to as well. For example, it is surprising that everyone just accepts that massive thefts exist in the cryptocurrency space. There are five things we do that are particularly compelling — scalability, efficiency (and therefore cost reduction), fraud/theft/loss protections, privacy, and stability. We would argue that a solution that has all of those components in a single solution can truly bring blockchain to mainstream use. Our scalability (and the resulting efficiency) has been vetted and tested, and is described in detail in our Greenpaper. Experts in consensus algorithms who have done due diligence for potential investors feel it will work, and our working system has been benchmarked. We have a video showing our benchmarking and our testnet will be live soon, so anyone who doesn’t believe what we have show so far will have proof shortly. The stability solution (which we call DevvFiat – it is not the Devv cryptocurrency itself) is a flavor of a stablecoin, but that concept has been shown to work. Our fraud/theft/loss solution and privacy solution are both clever, but they’re not really that complicated. If one does their due diligence, and really looks at all 5 components, one can see what we’re truly doing, and why what we’re doing will work. It’s only a matter of time until people realize the power of what we’re doing.
We are starting conversations with many enterprise customers. Our solution provides many of the capabilities and features enterprise and institutional investors need to see to truly embrace blockchain. We believe we could be THE enterprise blockchain solution. We are also planning an investment fund for our platform and have a great deal of in house expertise in planning that.
DEVV LTD is a Corporation based in Cayman that is wholly owned by Devvio Inc. We are implementing our token sale out of Cayman. Many of the bigger token sales have been done out of Cayman.
That is true that we have been under the radar so far. We are working with TokenMarket and have been preparing all of the pieces for their process for marketing. We are about to start many of our marketing efforts and we feel we will no longer be under the radar soon.
Devv is short for Developer. By naming our cryptocurrency and protocol Devv, it references what it really is (software) and also is a nod to the folks who make it happen (Developers). The reason that is important, is it grounds the philosophy of what we're doing. Devv is a blockchain for mass use and for everyday people. The ultimate goal is to create the world's infrastructure for transferring value. That is an ambitious goal, but if we are successful on that large of ambition, we also need to keep in mind the roots of where we came from, and stay grounded. I like the idea of the folks who create something getting credit and upside rather than big organizations.
In the Devv Whitepaper, we have a simple high level table comparing Devv to the majority of other approaches. In the Devv Bluepaper, in Appendix B, is a more detailed comparison between Devv, Bitcoin, Ethereum, and Ripple.
Perhaps if we are very successful it will be a sort of new norm, but it is an approach we just thought out. Ethereum had some different colored papers to show different purposes. Some of our team’s background has an emphasis in graphics, so the Whitepaper is a summary, and we have more detail in our component papers, the Bluepaper (business integration), Greenpaper (technical implementation, and green because we solve the energy problems of Proof of Work), and an upcoming Redpaper (smart contract approach). Red+Green+Blue components = White.
We do not have any specifics to report on a token sale, but we will post on our Telegram group when we do. Here are some answers to related questions though.
Our hardcap is $18m, our softcap is $3m. We will sell 30% of Devv. The current whitepaper has some additional tokenomics details.
The fees percentage (in contrast to the other categories that were more based on amounts rather than percentages), is based on agreements we needed to put in place early on when we were first getting started. The earliest partners, who took risk with us up to a year ago, negotiated to receive a part of the token sale. A large portion of it goes to early partners who helped to arrange the token sale in the first place, a large portion goes towards building the initial blockchain prototype that benchmarked at 1 million transactions per second, and a large portion goes towards IP acquisition. We’ve made pretty tremendous progress with the resources we’ve had, but much of that was in trade for future upside (that at the time had significantly more risk than we have now).
We don’t have an exact date for the TGE. We’re looking to do a token sale in October if all goes as planned. Yes the TGE will be ERC-20 tokens, and yes, there will be a swap with the native token in the future. Wr will do so because we are a protocol, of course.
We aren’t planning on implementing staking. I think there is a natural incentive for people to hold tokens given the progress wr expect we’ll make, announcements we’ll hope to be able to make, and the future use of Devv in our BaaS model, which could be very valuable for everyone involved.
We feel our entire effort will be very valuable. Devv will be used in our blockchain as a service business, and our BaaS business is built on a truly exceptional technology and team. I think we have the best technology and approach in the entire blockchain space. We have the fastest blockchain in the world, and we have the only blockchain that has solved all of the biggest problems in blockchain in a single solution — scalability, privacy, fraud/theft/loss, cost, and stability. Imagine what that means towards taking blockchain to mainstream, and imagine the potential value our entire solution can hold to the industry, and the world. Our team are experienced businessmen, and across the board, everyone who has gotten involved with us early on feels this is the most exciting thing they have not only worked on, but have ever seen!
A more detailed description of Devv’s technological implementation is given in the Devv Greenpaper, which can be viewed here.
Devv’s latest benchmarking was at 8 million transactions per second, on-chain. You can see details on the test including a video in a recent blog post.
For those who feel the combination of a full description of our approach in the Devv Greenpaper plus the video is not enough proof, we will have a testnet available shortly where the code will be available to view on our Bitbucket account.
Devv uses Proof-of-Validation for our consensus mechanism, where validators (which are our consensus providers) create blocks comprised of transactions, and then collectively validate each block by sending validation messages. Our scaling is implemented with a multi-tier architecture which is a sharding solution. Proof of Validation and our sharing approach is described in detail in the Devv Greenpaper.
Yes, we have benchmarked the Devv blockchain at 8 million transactions per second, on-chain. The details of our tests, including a video, can be seen here.
There was low latency in the network, but one of the advantages of our sharding approach is that the shards are independent blockchains, each running their own consensus process. In real life, we can have Validators close to each other in our T2 shards, so low latency is realistic for consensus in our shards. Communications between T2 shards and the T1 shard can have larger delays but the cost there is some additional time between payment and settlement. We can use a concept of repeater nodes to maintain throughout. There are also other ways we’ve designed to further account for latency issues and other real world issues.
Yes, our sharding approach is designed for high throughput across a global network. Verification of a transaction can happen very quickly in a geographically localized shard, and settlement across shards can have some additional delay (a few seconds), but once a transaction is verified, settlement is guaranteed. We separate payment and settlement in our sharding approach.
This is definitely not the case. We wouldn’t have announced our results as we did, if that were the case (that would have been horribly misleading if that were the nature of the tests). Our tests use ZMQ for the networking communications. A single shard can process over 3000 transactions per second. If we simply kept all of the processing in memory, then a single shard itself could process millions of tps alone. Instead, we relied on millions of shards to implement our benchmarking. We did preprocess the blocks for the shards – that is a fair way to benchmark a system like ours (since each blockchain is an independent blockchain so from the T1’s perspective the data it receives is not affected by preprocessing or not), but the results from that preprocessing were sent to the T1 network over ZMQ. The network we used had low latency (as it is benchmarking, so an ideal situation) but it represents real world use. We might take a relatively small percentage hit for real world use, which is the nature of benchmarking, but there are other optimizations we can add in too compared to our current system. Therefore we feel the overall throughput long term, even in real world use, will go up from where we currently are benchmarking.
About 3500 right now.
The number of nodes per shard will be defined by security requirements (as opposed to technical limitations) that we will determine as we do our 6 month security testing and audit. The primary question is how many nodes are needed to assure the prevention of 51% of nodes being compromised.
A Validator node cannot validate for more than one shard. A network node can contain more than one Validator.
Yes we will continue to expand our testing across many different scenarios and attacks, but that said, our test was indicative of a real world network as was described above. All of the actual communications that ran through the benchmarking were communicated through ZMQ. Delays in communication from T2 to T1 affect settlement time but ultimately not throughput. T2 Validator nodes will likely be geographically located near each other to reduce latency on Proof-of-Validation consensus.
In general, one of the advantages of our approach is that shards can be implemented to focus on geographic areas or specific application areas (e.g. shards focused on IoT). Given that, many transactions will reside within a single shard. That said, we designed the system to have the same scalability even if all transactions go from one shard to another. We separate payment and settlement, so a sending wallet’s shard validates the transaction. Then that shards block is sent to the T1 network, and it is put into a T1 block. Then the recipient’s shard reads the T1 block and validates the receipt side of the transaction, putting it in its block. A detailed set of diagrams in the Greenpaper Appendix A show the flow of a transaction through the entire system.
About 6–8 devs have been working at various hours/week. We’ll have a bug bounty program, and expect to start ramping up getting many more people involved in general. One way we’re looking at doing so is with partners who want to use our blockchain — We’re onboarding developers from potential partners now.
We feel Devv would actually be a good replacement for the lightning network. Users will be able to transfer Bitcoin to Devvio, and Devvio will put it in escrow and give the user DevBitcoin. The Devbitcoin can then be traded instantly, worldwide, with small to no fees (i.e. a one-to-one backed version of Bitcoin), which is the point of the lightning network. We feel this is a better way of handling the problem of scaling Bitcoin transactions though. Anyone who has DevBitcoin can exchange it for the Bitcoin held in escrow. The concept works with fiat (which we call DevvFiat), ETH, gold, commodities, etc. one of the biggest benefits of this approach is that the Devv implementation of any of these assets can utilize other features of our protocol like the fraud/theft/loss protection or our privacy solution.
The following questions relate to how Devvio will run the Devv blockchain. Additional details are given in the Devv Bluepaper.
The Devv blockchain’s shards are independent blockchains, each with many Validators per shard. At the point where we are processing millions of transactions per second, we will likely have thousands of shards and each shard will likely have dozens or more Validators. The Devv blockchain’s operations are therefore decentralized. That is different than the permissioning of Validators.
We feel there is a general misconception of what miners do in the blockchain space. They simply order valid transactions. That’s it. The protections that one gets, and the trustless nature of blockchains, comes from the immutability of blockchain combined with the transparency of a public chain. Any two people can independently verify their transaction. Anyone can independently audit the entire chain. Devvio doesn’t oversee any transactions like a central authority does — Devvio simply oversees the Validators that order transactions. The reason, then, to permission Validators is to prevent collusion.
It is a very difficult problem to prevent collusion when anyone can contribute to consensus. Bitcoin has a reasonable approach, but there are many trade-offs (i.e. with Proof of Work) and there are many inefficiencies in that approach. When one adds Smart Contracts, the inefficiencies are much more pronounced.
Devvio intends to grow the Devv blockchain towards a permissionless system over time. We would argue that Devvio’s approach is the best approach, even if the ultimate goal is a permissionless system. If one wants to have a permissionless system in the end (in our case we envision Validators being comprised of universities and businesses where collusion would be so easy to detect and the risk of collusion therefore is so small, it is non-existent), we feel the best approach is to gradually work towards permissionless consensus while gaining experience along the way to implement it effectively. In the beginning, when regulations, technology, and competition are quickly changing, a lack of effective governance is a fatal flaw. In our approach, we will be able to govern our growth in the short term, and have years of operations under our belt as we tackle moving towards a permissionless system, arguably the most difficult challenge in the blockchain space.
Validators simply receive payment on par for running a server. Payment should be fair with a reasonable and fair amount of profit. We have a different philosophy than many other blockchains — the idea that people that provide consensus (which is fundamentally simply ordering valid transactions) would get millions of dollars of crypto per day doesn’t make any sense to us. Devvio’s approach pays validators fairly for their resources, but it is on par with any cloud service. Many validators will want to be part of the system as they will want to have interactions to assure their business requirements on chain (which is one area where we have already seen interest). Devvio will arrange for many other validators directly and simply pay a fair use for server usage.
In Devvio’s approach, we decide on Validators and permission them to use our system.
The permissioning won't dramatically affect the TPS. Sharding is where we get our scaling and it works with or without permissioning. The permissioning is needed early on to prevent collusion.
A more detailed description of Devvio’s business integration with the Devv blockchain is given in the Devv Bluepaper, which can be viewed here.
A large focus for Devvio is on our Blockchain-as-a-Service business. We will allow customers to tokenize assets for their business models. Customers will be able to implement their blockchain business on our platform in an inexpensive and scalable way, with access to the advanced features of our approach like fraud/theft/loss prevention and privacy.
Devvio’s privacy solution is described in the Devv Bluepaper.
Our privacy solution was designed to be compliant with government regulation. We can provide true privacy, but we can also provide court ordered transparency. We describe our privacy solution as “True privacy, other than court ordered transparency”. We feel this is the only type of privacy that will be acceptable to governments, and therefore the only type of privacy that will be able to thrive. As brilliant as approaches like zk Snarks and other zero knowledge proofs are, in the end governments won’t like them because they provide true privacy. Governments want to prevent illegal activities like money laundering and terrorism.
In our approach, we can prevent people from reverse engineering identities in pseudonymous wallets, but the ways that we do so are tracked by a trust based entity (Devvio), which can then provide court ordered transparency of how private transactions were implemented. Devvio’s privacy service is an optional feature and Devvio is not a trusted authority in approving blockchain transactions.
Devvio implements its fraud, theft, and loss solutions with an escrow-like functionality called DevvProtect. You can read more about DevvProtect in the Devv Bluepaper.
Devvio’s fraud/theft/loss solution (which we refer to as DevvProtect) will be customizable. Users can have different wallets with different escrow time periods to prevent theft. On an individual transaction, one can set the escrow time period. A good use case would be to have a wallet with a long term escrow period, a wallet with a medium term escrow period, a wallet with a short term escrow period, and a wallet with a smaller balance and no DevvProtect protection for everyday use.
Each of fraud, theft, and loss protections have different logic. In the case of a stolen private key, and subsequently stolen assets, if the user’s stolen funds were in a DevvProtected wallet, then the funds automatically go into escrow. If the user discovers the theft before the escrow time period is up, then Devvio can verify the user’s ID with standard concepts like two factor authentication, or other services in today’s world, in order to return stolen funds. After Devvio verifies one’s identity, it can create a transaction that effectively reverses the theft (technically it is a separate transaction moving the funds out of escrow, since the blockchain is immutable). If there is ever a question on ID or tight timing, Devvio can extend the escrow time. Keep in mind Devvio cannot initiate a transaction. It can only can return funds that are in escrow (and will only do so under a user’s directions). DevvProtect is optional, and anyone who doesn’t want to use it does not have to.
It’s hard to quantify in a broad statement of course, but we will point out a few related concepts in analyzing that concept. The Devv blockchain is a regular blockchain like others — it is immutable, public, pseudonymous, transactions are protected by public/private keypairs, etc. Devvio’s DevvProtections are just a service that can help prevent fraud/theft/loss. All of the features for protection from fraud/theft/loss and privacy are optional. People will need to keep their private keys safe (same as other blockchains, and same as bank account information).
No, you can send a transaction as DevvProtect (escrow) at any point from a wallet that has been verified by Devvio. You can also create wallets that have a more permanent level of escrow on them (a DevvProtected wallet is needed for theft protection, for example).
We have not finalized the business model around Devvio’s services. However, we can give a feel on what we’re envisioning. We expect that in many situations users will not need to pay for services. We believe a model similar to credit cards will work well, where sellers get extra benefits by accepting Devv or DevvFiat and customers don’t pay for those features. In the case of a user who wants protections for a craigslist payment, for example, might have a fee in that kind of situation.
Yes, the plan is to let people set up alerts on any transactions if they have a DevvProtect wallet. That’s a big part of the point — DevvProtect gives people time to detect fraud/theft/loss but at some point the escrow releases and there is no further way to get funds back.
When a wallet itself is a DevvProtect wallet, one cannot change the escrow time. If you to keep some or all of your funds in a wallet that protects them then you make the entire wallet a DevvProtect wallet and anything coming out of the wallet goes into escrow defined by the wallet’s settings.
Devvio’s smart coin approach is described in more detail in the Devv Bluepaper.
Yes! We think our Our Smart Coin approach is going to blow people’s minds (like Ethereum did when it was introduced). We are going to release a new Redpaper detailing our Smart Coin approach soon. We feel it is an introduction to a new blockchain philosophy that is based on an ultra efficient transactions and security at scale. Blockchains are good at two things, robustness and trustlessness. The implication there is that blockchain should primarily be used for maintaining assets and as much processing as can be made to be off-chain, should be handled off-chain. Also, a Smart Contract system needs to be secure at scale. BaaS customers will be able to use a compositional programming approach to combine Smart Coin functionalities through a DAG to get the capabilities they need. Smart Coins on T2’s will interact with third party implementations through Oracles. Only T2’s interact with the T1.
Why did you choose to not have Turing complete smart contracts? Will this decision hinder the capability of constructing complex smart contracts?
Turing complete smart contracts are a mistake in our view. They aren’t secure at scale, aren’t scalable, and are complicated to implement. Our approach is dramatically less expensive, much safer and much more secure, and will be easy to implement — as well as scalable. Our Smart Coins themselves are built on C++ (Turing complete) so there are no limitations on what we can implement with our approach.
Right now we’re using C++. We’ll support other languages over time too.