Magic Powered is a web3 collective working on dev tooling and dapps
Magic Powered is a web3 collective working on dev tooling and dapps
Subscribe to Magic Powered
Subscribe to Magic Powered
<100 subscribers
<100 subscribers
Share Dialog
Share Dialog
By 2021 NEAR became a new fast L1 blockchain ecosystem, with a top 20 coin by the market cap. Using RUST as the main language and just basic voting / multisig smart contracts available. The task stated was to develop and maintain the Dapp for governance / DAOs use cases called Astro DAO for the foundation and other ecosystem users based on the reference implementation. Magic Powered took the role of the core ecosystem developer for 1.5 years, this is one of the products developed together with the foundation.
At the very beginning of the project, near infrastructure has no “easy to use” solution for indexing the on-chain data. All our attempts to build such an indexer based on the existing open-source framework were not successful and according to other users we could spend months to make it up and running and it would require enormous maintenance effort. Attempt to use DB with historical data provided by the community was limited by the bandwidth and was not reliable for production usage. We ended with a hybrid solution that was polling transactions from a dedicated read DB replica, parsed it and populated our own storage.
In one of the stages, a new interface concept was developed by a 3rd party, which had nice ideas though was premature for the development in terms of developer readiness. Somewhere it also led to 14 different designs of the same element in different journeys – a big overhead in testing and maintenance.
By 2021 NEAR became a new fast L1 blockchain ecosystem, with a top 20 coin by the market cap. Using RUST as the main language and just basic voting / multisig smart contracts available. The task stated was to develop and maintain the Dapp for governance / DAOs use cases called Astro DAO for the foundation and other ecosystem users based on the reference implementation. Magic Powered took the role of the core ecosystem developer for 1.5 years, this is one of the products developed together with the foundation.
At the very beginning of the project, near infrastructure has no “easy to use” solution for indexing the on-chain data. All our attempts to build such an indexer based on the existing open-source framework were not successful and according to other users we could spend months to make it up and running and it would require enormous maintenance effort. Attempt to use DB with historical data provided by the community was limited by the bandwidth and was not reliable for production usage. We ended with a hybrid solution that was polling transactions from a dedicated read DB replica, parsed it and populated our own storage.
In one of the stages, a new interface concept was developed by a 3rd party, which had nice ideas though was premature for the development in terms of developer readiness. Somewhere it also led to 14 different designs of the same element in different journeys – a big overhead in testing and maintenance.
Magic powered has to adapt it and release a new version compatible with existing smart contracts.
Initial app design and user flows were not inconsistent with the smart contract and architecture available. Due to a lack of documentation, some of the user flows were recreated from the scratch taking into consideration existing capabilities.
Magic Powered was strongly engaged in the ecosystem and evolved the engagement model from an open-source grantee to a long-term development partner with a dedicated team/allocation-based model. The model also included the strict deadlines environment as that was a crucial part of the ecosystem and many teams relied on it. Thus our team had to take some risks and deal with complex challenges blocking the development.
In one of the cases, our team has helped to find a critical vulnerability that could affect the whole ecosystem (a security audit wasn’t a part of the initial scope). It relied on communication and tight work with the foundation helped a lot to achieve the needed result.
Team:
Max Kudinov – UX Lead
Dmitry Karpov – Tech Lead
Nastia Emerald - senior designer,
Alena Shorenko - junior designer;
Vicky Plashevska - design lead;
3-10 Full Stack Dev + DevOps in different time
QA Engineers
In order to prioritise and develop the most needed features first we created a power-user group in telegram and was researching and supported the requests from it. The group quickly has grown to 400+ people and all the teammates were there constantly communicating with the market and other developers. Here are a few of the improvements made in the process of the adaptation.
We applied user-centred design principles such as simplicity, consistency, and accessibility, which make ASTRO easy to use for a wide range of users. These principles include the use of intuitive navigation, clear and concise language, and visually appealing design elements. Other design patterns applied include responsive design to optimize for different screen sizes, clear and easy-to-understand dashboard displays, and easy-to-use forms for making transactions. Additionally, the platform also employs security-focused design patterns to help ensure the safety of users' funds and personal information.
Navigation system improvements:
Clear and concise: Used clear and concise language to label navigation items and keep the number of items to a minimum to avoid overwhelming users.
Group of related items: Organized navigation items into logical groups to help users quickly find what they're looking for.
Prioritization of items: Highlighted the most important items by placing them in a prominent location or making them more visually distinct.
Intuitive icons: Used easily recognizable icons to help users quickly identify navigation items.
Clear and consistent tooltips: to provide users with clear prompts when they interact with the navigation system or components to help them understand their current location, update statuses, and how to access other areas of the platform.
Proposal Creation flow improvements through the prism of WYSIWYG:
WYSIWYG is an acronym that stands for "What You See Is What You Get." It is a type of user interface that allows you to see how the final output will look while you are creating or editing content.
In simple terms, WYSIWYG means that what you see on the screen is a close representation of what the final output will look like, whether it be a document, a website, or a proposal. This makes it easier for users to see the results of their work in real-time and make changes as needed, without having to switch between different views or modes.
Our middle was initially based on polling architecture and was organized as a set of microservices based on the NestJS framework and Postgres as storage. Over time this solution evolved into a more cost-efficient solution based on AWS Lambdas and DynamoDB / Opensearch.
The big challenge was to replicate/adapt the relational DB structure and use it as a single point of truth. The Openseach (Managed ElasticSearch) sit in front of the UI and provided extended capabilities of querying/filtering semi-structured data.
Open Source infrastructure has extreme importance but also is a heavily subsidised effort. In order to add sustainability to its maintenance a number of commercial-based pilots were launched to diversify the budgeting:
Membrane – token-gated solution to web2 APIs (analogue to Collab.Land)
Stargate – Developers’portal for NEAR
Moonbase bot – maps DAO roles in Discord based on the tokens
DAO stats – aggregation service to provide KPI based dashboard for the entire DAOs ecosystem
Auction – p2p marketplace for NFTs
Near.js library
We’ve developed and supported one of the core projects in the NEAR ecosystem (correlation with the token performance)
Dapp was used by all eco players (Foundation, Aurora, grantees etc…)
The code base evolves and adds up in complexity after 18+ months of development
A number of side products were developed and got traction from customers and investors
Want to learn more about us?
Magic powered has to adapt it and release a new version compatible with existing smart contracts.
Initial app design and user flows were not inconsistent with the smart contract and architecture available. Due to a lack of documentation, some of the user flows were recreated from the scratch taking into consideration existing capabilities.
Magic Powered was strongly engaged in the ecosystem and evolved the engagement model from an open-source grantee to a long-term development partner with a dedicated team/allocation-based model. The model also included the strict deadlines environment as that was a crucial part of the ecosystem and many teams relied on it. Thus our team had to take some risks and deal with complex challenges blocking the development.
In one of the cases, our team has helped to find a critical vulnerability that could affect the whole ecosystem (a security audit wasn’t a part of the initial scope). It relied on communication and tight work with the foundation helped a lot to achieve the needed result.
Team:
Max Kudinov – UX Lead
Dmitry Karpov – Tech Lead
Nastia Emerald - senior designer,
Alena Shorenko - junior designer;
Vicky Plashevska - design lead;
3-10 Full Stack Dev + DevOps in different time
QA Engineers
In order to prioritise and develop the most needed features first we created a power-user group in telegram and was researching and supported the requests from it. The group quickly has grown to 400+ people and all the teammates were there constantly communicating with the market and other developers. Here are a few of the improvements made in the process of the adaptation.
We applied user-centred design principles such as simplicity, consistency, and accessibility, which make ASTRO easy to use for a wide range of users. These principles include the use of intuitive navigation, clear and concise language, and visually appealing design elements. Other design patterns applied include responsive design to optimize for different screen sizes, clear and easy-to-understand dashboard displays, and easy-to-use forms for making transactions. Additionally, the platform also employs security-focused design patterns to help ensure the safety of users' funds and personal information.
Navigation system improvements:
Clear and concise: Used clear and concise language to label navigation items and keep the number of items to a minimum to avoid overwhelming users.
Group of related items: Organized navigation items into logical groups to help users quickly find what they're looking for.
Prioritization of items: Highlighted the most important items by placing them in a prominent location or making them more visually distinct.
Intuitive icons: Used easily recognizable icons to help users quickly identify navigation items.
Clear and consistent tooltips: to provide users with clear prompts when they interact with the navigation system or components to help them understand their current location, update statuses, and how to access other areas of the platform.
Proposal Creation flow improvements through the prism of WYSIWYG:
WYSIWYG is an acronym that stands for "What You See Is What You Get." It is a type of user interface that allows you to see how the final output will look while you are creating or editing content.
In simple terms, WYSIWYG means that what you see on the screen is a close representation of what the final output will look like, whether it be a document, a website, or a proposal. This makes it easier for users to see the results of their work in real-time and make changes as needed, without having to switch between different views or modes.
Our middle was initially based on polling architecture and was organized as a set of microservices based on the NestJS framework and Postgres as storage. Over time this solution evolved into a more cost-efficient solution based on AWS Lambdas and DynamoDB / Opensearch.
The big challenge was to replicate/adapt the relational DB structure and use it as a single point of truth. The Openseach (Managed ElasticSearch) sit in front of the UI and provided extended capabilities of querying/filtering semi-structured data.
Open Source infrastructure has extreme importance but also is a heavily subsidised effort. In order to add sustainability to its maintenance a number of commercial-based pilots were launched to diversify the budgeting:
Membrane – token-gated solution to web2 APIs (analogue to Collab.Land)
Stargate – Developers’portal for NEAR
Moonbase bot – maps DAO roles in Discord based on the tokens
DAO stats – aggregation service to provide KPI based dashboard for the entire DAOs ecosystem
Auction – p2p marketplace for NFTs
Near.js library
We’ve developed and supported one of the core projects in the NEAR ecosystem (correlation with the token performance)
Dapp was used by all eco players (Foundation, Aurora, grantees etc…)
The code base evolves and adds up in complexity after 18+ months of development
A number of side products were developed and got traction from customers and investors
Want to learn more about us?
No activity yet