Categories
Blockchain Software Technology

Blockchain education: Meet our meetup!

We’re just wrapped up the second edition of Poznań Blockchain Meetup. While the first edition was strictly technical, this time speakers focused on more varied blockchain matters. These included legal considerations, token types and the wider perspective on blockchain design. We’re glad to promote a more well-rounded approach to blockchain education. Here are some presentations and pics from the meetup.

As the organizers, we have to say this first. Blockchain education is something important to us. And we’re so proud that our meetup is seeing such interest. We’re hopefully on the way to creating a real local ecosystem, considering that not only devs are turning up to listen to the talks. So we’re encouraging non-experts in tech to come and join us in September for #3, both as speakers and as audience.

Let’s talk about #2 first, shall we? Here’s a quick summary of the three presentations.

Blockchain education – technology

The first talk Trustless off-chain computing in DApps,  was a more advanced technological tutorial. But what else can we expect from our Head of Blockchain? Only top-notch blockchain education. By the way, he’s written some great articles for our blog (about blockchain regulation or the benefits of a decentralized organization). Check them out if you’d rather read than listen. He’s also one of our blockchain training experts. Marcin demonstrated how you can retain trustlessness and data immutability while implementing applications that need a lot of computing power. Ordinarily, blockchain tends to be slow as it wasn’t designed to handle massive amounts of operations. See how he deals with those limitations here:

Trustless off chain computing on the blockchain from Espeo Software

Blockchain education – legal

The second presentation handled some legal matters. Adam Polanowski, a practicing lawyer, showed the meetup crowd how to differentiate between various types of tokens. He also spoke about the legal requirements behind ICOs. Of course, this segment of blockchain education works best in direct contact with your lawyer, however, Adam’s remarks were very helpful, and a good starting point for more in-depth considerations. Legal matters around blockchain are worth keeping up to date with, considering how much in trouble one can be in this rapidly evolving ICO landscape.

Initial Coin Offerings – legal requirements and types of tokens from Espeo Software

Back to basics

Software dev Michał Chatłas offered a wider look at blockchain design and the reasons behind using blockchain. The gist of his talk ‘Distributed, immutable, secure…’ is that there is a lot to consider before deciding on blockchain as a solution. Blockchain offers a lot – but the implementation has to be well thought-out. Take a look at his presentation – the flowcharts should be particularly helpful. Is blockchain the future? We think so. Is blockchain the future for you? See the presentation first.

Distributed, immutable, secure… from Espeo Software

Poznań Blockchain Meetup #3 plans

Make sure you don’t miss our third meetup. We’re planning it for early/mid September. Oh, by the way, you can become a speaker too – if you’ve got what it takes. Interested? Drop an email to blockchain.meetup@espeo.eu. If you’re looking for more personalized blockchain education, just so you know – we’re offering tailored blockchain training.

Categories
Blockchain Entrepreneurship Public

How blockchain regulation should look

Despite what you might read online, not all blockchain regulation is bad. Regulations are, in general, necessary. They help businesses thrive on markets that suffer from information asymmetry. What’s more, they also make the industry landscape clearer and sanction the government’s approach towards it. Regulations also protect customers’ interests if access to information is limited or if there’s a constraint on competition between market actors. However, blockchain regulation can be done wrong, as we’ve seen in some cases. Let’s raise some questions and try to look for solutions: from green addresses to exemptions.

Thinking cross-nationally

Regulations are usually national. There are certain cross-national regulations, but they happen only to some extent. You don’t want people financing terrorism, for example. However, it can be futile to try and regulate companies that operate through using blockchain technologies only on the national level . That’s because companies can change the jurisdiction of their inc. to avoid unnecessarily harsh blockchain regulation. It would be very beneficial for the whole industry to create cross-national non-profit organizations and self-governing bodies that can address policy blind spots . Their members can range from industry representatives to government representatives. They could be tasked with suggesting and promoting good regulatory practices across the members and jurisdictions they represent.

Educating

As a technology, blockchain can’t be regulated or banned , as it’s only a concept/algorithm and a technical data structure. Entities (especially those non-formalized) operating purely on the blockchain that don’t interact with real-world companies can’t be regulated either. However, regulators should also be involved in education campaigns , spreading awareness of fully decentralized schemes or pointing to risks of suspicious schemes (example here).

Focusing on entities interacting with blockchain

Blockchain regulation should be focused on the entities that interact with blockchain technologies. They operate on the blockchain network, offering their services to other real-world consumers or companies. Regulation on this level shouldn’t be much different from what we have for similar non-blockchain services. This includes any financial operations, insurance, logistics, etc.

Allowing exemptions

As the technology is very innovative and can create positive change across many industries, there should be regulatory exemptions in place. Good examples include blockchain regulations in Switzerland or Gibraltar for small-scale operations. They’re measured, for example, by a maximum value of customers’ assets held by the operation without full license or by the exemption time. In these cases, the regulation is won’t limit innovation before it’s able to prove its positive value.

Self-regulation

Some fully decentralized schemes can and will impose self-regulation practices and extreme transparency . An entire industry built around providing analytical, monitoring and transparency services to existing fully decentralized schemes may emerge . This would increase the customers’ confidence in the schemes. So, regulators should also promote these practices – or companies offering them. Regulators and Central Banks can even go one step further and create national cryptocurrencies with self-regulating capabilities built right into their scheme. Decentralized services built on top of national cryptocurrencies can be considered safer by the end customers. Of course, if the scheme can self-enforce regulation best practices (proper KYC and AML).

Anonymous schemes

It’s possible that national governments and regulators may create their technical interfaces/APIs . For example, for proper tax calculation or for direct sales tax payment. So, those fully decentralized services offering their products to the citizens can become fully compliant with the local regulations even if they lack any real-world manifestation . Schemes like that can increase the customer’s safety. What’s more, they contribute to the view that customers can operate within the law even in the case of fully anonymous schemes . At the very minimum, regulators have to clarify their stance on the sales and VAT taxation applications to transactions conducted with blockchain .

Using green addresses

In some jurisdictions (like China), capital controls, especially the flow of capital abroad, are an important part of regulatory responsibilities. It’s hard to curb Bitcoin transactions as they’re naturally borderless. However, it’s possible to control all the participants that take part in converting fiat money to Bitcoin – and vice versa. There’s also the concept of Green Addresses. These are Bitcoin addresses that belong to a known and trusted financial institution which also manages the users’ bitcoin wallets. Whenever a user wants to make a transaction from a wallet to an external party, they can send it via its Green Address provider. Then, the outgoing transactions will look as if they’re coming from a trusted address of the Green Addresses provider. Regulators can require all transactions into and out of exchanges in a given jurisdiction to go via Green Addresses.

Fixing information asymmetry

The concept of information asymmetry exists in the general economy. For example, in used cars trading. Let’s say the buyer can’t really tell if a car is good or bad. The seller can easily hide some defects, which leads to increased distrust between two parties. Blockchain technologies can help, as they can provide irrefutable provenance proves. Every object can be traced back to its producer and all the previous owners. Additionally, you have trackable quality assessments and can see all the amendments and repairs ordered in the meantime. This information can’t be removed or hidden from the blockchain. Regulators could structure market transactions so that proper provenance collection is required for every newly built product from a certain market. This way, it gradually introduces complete reliability to this market and lowers information asymmetry.

Blockchain regulation catches up

These are only some of the issues that national regulators have to face. Some advancements were impossible to predict when regulators passed resolutions. It’s a difficult game of catching up. And if you feel you need to catch up with what’s currently allowed and what’s not, go for blockchain training.

Categories
Blockchain Financial Services

Blockchain legal issues with DAOs

In my first article, I covered the benefits and possible problems that come with joining a decentralized organization. Today I’ll focus on some blockchain legal issues concerning DAOs.

Keeping things safe

  1. At its core, DAO was designed as an informal group of parties which operates entirely within the algorithm of its code . Theoretically, they can stay anonymous. However, it’s impossible that this code would cover every possible future case. There’s the obligations and interaction mechanisms between different DAOs and between different members and participants of the DAO. Moreover, if there’s no formalized legal structure in place for this entity, courts will impose one. A DAO most resembles a general partnership in which members/partners jointly represent DAO and are liable for its actions and obligations. The DAO may not have assets from which to indemnify third parties. So, it lacks assets or legal form. Therefore, the court could see the entity as fiction and could allow a lawsuit to proceed against individual members .
  2. A safe approach for DAO members would be to create a standard legal entity to which the DAO belongs. Every change in the DAO membership will have to be reflected in the entity membership/shareholding structure.
  3. A DAO can control cryptoassets. They can represent almost anything, including real-world assets, fiat money, valuable objects like cars, houses or precious metals. Those assets should be put under control of multisignature wallets (escrow) which DAO members have control over. Of course, proportionally to their DAO membership shares.
  4. There are initiatives in development that plan to setup “virtual jurisdiction” within which DAOs could operate. They could then cooperate with each other safely and with clearly defined rules. What’s more, they could have dedicated arbitration procedures in case of an unresolvable dispute.
  5. A DAO smart contract could also include a clause referring to a private court which specializes in smart contract disputes. It’s far better to determine preferred jurisdiction beforehand, than let a plaintiff or a government choose it afterwards.

Blockchain legal issues – DAO

  1. In the real world a ‘principal’ is liable for its agent’s actions . Check out agency theory for more. An individual developer or software company that created a DAO can be considered as principal in some scenarios. That principal can be held liable for the actions of the DAO (and its members) without having any control over them.
  2. Legal language is very different from procedural computer language. Usually, a software developer isn’t able to express all legal details accurately. Development of specialized smart contract law programming languages is still in its very early stages.
  3. There’s no common way, yet, to represent fiat money on the blockchain. Here’s an attempt. However, most of the traditional contracts still need to represent value using fiat money or precious metals . Possibly, Central Banks can also digitize fiat money on the blockchain. Until that happens, most of the DAOs operations will be very limited in scope.
  4. If we treat a DAO as a for-profit company, there is whole set of unanswered questions. For example:
    1. Can DAO members or DAO itself claim expenses against profits?
    2. If the DAO needs to buy a physical asset, whose name goes on the paperwork?
    3. If the DAO creates and patents intellectual property, who’s the registered owner?
    4. How a DAO can own an internet domain when domains still need to be registered to a person or company?
    5. How should taxes be paid if the DAO (or its members) make a profit?

Final remarks

Naturally, my article doesn’t constitute any blockchain legal advice. But these are certainly blockchain legal issues to consider. A DAO is definitely an interesting initiative that can fix real problems. Just make sure you’re prepared for every contingency. If you’re not sure you are – consider our blockchain training sessions. We’ll work through your problems.

Categories
Software Technology

Product Design in Agile Methodology

The standard design process divides the product preparation period into various phases, which (depending on what methodology was adopted) separate interface design and its implementation. The combination of both phases and the creation of the one team working in Agile methodology allows us to save time, speed up the implementation process and improve the quality of a product’s usability. This occurs when the collaborative team is competent in both design and implementation.

Not sharing either knowledge and/or experience during the completion of tasks in both these categories may result in the preparation of an interface whose implementation will cause unnecessary problems for programmers — this is the most likely and easy to avoid the problem. Similarly, the need to modify the accepted requirements of a project (due to the change in the scope or mode of application operation) increases the number of iterations and corrections at every stage of the process.


After identifying such issues in previous projects, the importance to include people with project competencies and experience in Agile methodology in the development team is obvious. Working on UX and UI applications in the scrum formula and its appropriate synchronization with the ongoing implementation at that time guarantees an immediate increase in the success of implementation and improved quality control in the visual layer.
 
Working on UX and UI applications

Scrum methodology in product design — how it looks in practice

The length of the product design sprint is usually adjusted to the length of the standard development sprint. Using the same tools to manage tasks, each planning session defines project goals, their priority and amount in a given sprint for a given number of people in the project team (usually there are one to three teams, depending on the complexity and development of the project, with competences in analysis, UX and UI design and independent work organization).
 
The most important assumption is to plan the work of the product design team at least 1 sprint in advance to that of the development team – to which the planning and backlog grooming is most often used. Thanks to this, everyone gains a wider perspective than just their current tasks, developers gain the possibility to take an active part in the process of usability and interface design, while designers get clear feedback in the context of the feasibility of the developed projects and their usability.
 
Depending on the complexity of the project, the demo takes place with the help of a clickable prototype or presentation of individual components or views in the presence of the whole team. Tasks that have not been accomplished pass to the next sprint. The main goal is always to provide developers with the materials to work well in advance, including usability testing and gathering feedback from users and customers.
 
Product design - Espeo Software

Client-centric design process

Synchronizing the adaptation of Agile methodology to the design process and collaborative work with the development team (but with appropriate methodologies), automatically changes the perception of the entire project. The common definition of a backlog, a lively discussion about functionality and people with different competencies focused on achieving the same goal – providing the best possible quality of implementation – is definitely a recipe for success. This unusual approach allows us to focus on details and individual components of the project at hand, and also ensures that throughout the implementation the main assumptions are remembered and a wider perspective maintained.
 
The use of Agile methodology in the Product Design process also has one additional advantage, which is the need for close cooperation and frequent testing of the prototype with target users. This is due to the fact that we mainly work on the creation of a UI system that will be easily adaptable for different functional scenarios, and that concentrates on understanding users to solve and satisfy their problems and needs. This approach that focuses on users guarantees that the system we develop will also be easily adaptable in other, alternative applications should there be a need to develop them (a good example here is LindaAI).
 
One of the interesting and most effective exercises that should be used in the analysis phase is User Story Mapping – this is regardless of whether we are working on a new product, where we focus on solving real problems of users, or we are working on a new instance of an existing project, where our goal is to make sure that our changes and introduced features have a positive impact on business indicators and user behavior.

This exercise allows us to define:

  • Who is the intended user/recipient of the product?
  • What needs to be done with the product that is being worked on?
  • What is the implementation of key scenarios?
Team work in mobile application desining - Espeo Software

The whole is done with the help of whiteboard, sticky notes and the joint work of the entire team. The actions performed by the user of our application are divided into the next steps of the project so that we get accurately mapped functional paths in the product, with selected MVP, the division into releases and the ability to easily transfer data from the analysis phase to the backlog. What is more, the effects of our work can also be used to determine the conversion hopper (by identifying the most important activities on the site), control before extending the scope during work (thanks to easy migration to the backlog) and guarantees clarity in the common understanding of the product throughout the team.

Cross-functional teams

It is worth noting that project competencies between the development and design teams are purposely reiterated throughout the duration of the project. In the phase of analysis and research, the technical insight of developers is undoubtedly a great value, which at the start limits the number of potential problems. Most often, immediately after the analysis phase, the level of project work increases, so that the development team has already started with a specific number of ready and tested design solutions and that thanks to the aforementioned synchronization throughout the implementation, the designers can deliver further modules and components for implementation. The intensity of design work usually decreases at the final stage of implementation, where designers can take care of quality control. The whole cycle is repeated for each subsequent release of the product.
 
We must always be ready to change priorities. The ability to analyze the visual layer and support in improving usability often requires additions to the standard scope of work in a given sprint of time, which will be used to help the development team solve current problems during implementation. Designers and analysts very often have the widest view of the project, so their competences can naturally expand – but we should always be focused on the goals defined within the sprint.

In Espeo we use the following set of tools:

Slack as a basic communication channel inside the team (except for project meetings)

inVision as the main tool for building prototypes of interfaces and testing them with users

Zeplin as the main tool for the transfer of materials for the implementation of the development team

Summing up

The adaptation of the project team to Agile methodology and the creation of a collaborative work environment, where there is the smooth exchange of information, had a positive impact on the quality of implementation (not only in the visual layer).
 
Improving this process is the key to building a complete set of competencies in a team that is able to efficiently deliver well-prepared solutions, focused on meeting the goals set by business and solving problems faced by users.
 

See also: