Daoism SystemsDoinGud: Building a DeSI Protocol with Multilevel Governance
The organic connection between grassroots movements and Decentralized Impact is breaking new ground with the adoption of blockchain technology and DAO governance. This is the story of DoinGud, a project that leverages decentralization and transparency towards doing good. Charity organizations, communities, and individuals can join the DoinGud ecosystem by forming their own DAOs and coordinate over social causes. Featuring a Decentralized Impact protocol operated by a multilevel governance sys...
Daoism SystemsModular Futures for Custom DAO Development
I. The DAO landscapeOur understanding of decentralized autonomous organizations is constructed from the current landscape of us e-cases: DeFi protocols, NFT collector clubs, public goods, and a great assortment of other interest groups coordinating over common purpose. However, from a technical standpoint, we have yet to see the internet-native cyborgic system described in Vitalik’s 2014 essay: “The idea of a decentralized autonomous organization is easy to describe: it is an entity that live...
Daoism SystemsDaoism Systems Manifesto
The internet has changed. At its dawn, many had hoped that unparalleled access to information and communication would unify humanity towards a paradigm shift for global liberation: collective betterment seemed to be on the rise. Instead, the digital frontier has been colonized by large corporations, governments, and commercial ventures, exploited for its key resources at unimaginable scale and depth. Centralized platforms have gentrified social and information networks, harvesting data en mas...
Daoism Systems is the blockchain R&D company focusing on avant-gardе on-chain applications.
Daoism SystemsDoinGud: Building a DeSI Protocol with Multilevel Governance
The organic connection between grassroots movements and Decentralized Impact is breaking new ground with the adoption of blockchain technology and DAO governance. This is the story of DoinGud, a project that leverages decentralization and transparency towards doing good. Charity organizations, communities, and individuals can join the DoinGud ecosystem by forming their own DAOs and coordinate over social causes. Featuring a Decentralized Impact protocol operated by a multilevel governance sys...
Daoism SystemsModular Futures for Custom DAO Development
I. The DAO landscapeOur understanding of decentralized autonomous organizations is constructed from the current landscape of us e-cases: DeFi protocols, NFT collector clubs, public goods, and a great assortment of other interest groups coordinating over common purpose. However, from a technical standpoint, we have yet to see the internet-native cyborgic system described in Vitalik’s 2014 essay: “The idea of a decentralized autonomous organization is easy to describe: it is an entity that live...
Daoism SystemsDaoism Systems Manifesto
The internet has changed. At its dawn, many had hoped that unparalleled access to information and communication would unify humanity towards a paradigm shift for global liberation: collective betterment seemed to be on the rise. Instead, the digital frontier has been colonized by large corporations, governments, and commercial ventures, exploited for its key resources at unimaginable scale and depth. Centralized platforms have gentrified social and information networks, harvesting data en mas...
Daoism Systems is the blockchain R&D company focusing on avant-gardе on-chain applications.
Share Dialog
Share Dialog
Subscribe to Daoism Systems
Subscribe to Daoism Systems
This document provides a technical overview of the dSafe SDK. Here we’ve collected an outline of the SDK's goals, functionalities, architecture, and other aspects.
The dSafe SDK aims to offer a decentralized alternative to the Safe Transaction Service. By leveraging ComposeDB for data storage, the primary objective is to enhance security, reliability, and transparency in managing Safe transactions.
Deploy new Safe and store its details in ComposeDB.
Create a new transaction message, sign it, and store it in both ComposeDB and Safe Transaction Service.
Retrieve all stored transaction messages from ComposeDB.
Add confirmation to existing transaction messages.
Execute transaction messages that meet the threshold.
Decode transaction message data.
Manage delegates: fetch, add, and delete.
Fetch Safe details and transactions.
Support forwarding of requests to Safe Transaction API for API endpoints that are not yet implemented. (Similar to Reverse Proxy but on SDK side)
Efficient performance with quick execution.
Secure data handling and input validation.
Maintainable code with comprehensive documentation.
Cross-framework compatibility (independent of framework like React, Vite etc).
Optimized package size for quick installations.
Clear error handling and messaging.
The SDK will convert the following Safe Transaction Service API endpoints into SDK methods:
The SDK will adopt a modular design, ensuring scalability and maintainability. The directory structure will be organized into core functionalities and utilities, with comprehensive testing and documentation.
/dSafeSDK
|-- /src
| |-- /core
| | |-- index.ts
| | |-- dataDecoder.ts
| | |-- delegates.ts
| | |-- multisigTransactions.ts
| | |-- safes.ts
| |-- /utils
| | |-- helpers…
|-- /tests
| |-- /unit
| |-- /integration
|-- package.json
|-- tsconfig.json
|-- README.md
/core: This directory contains the main logic for the SDK. Each file corresponds to a set of related functionalities, e.g., dataDecoder.ts contains functions related to data decoding.
/utils: This directory contains utility functions that are used across the SDK. For instance, apiHelper.ts might contain functions to make HTTP requests, crypto.ts for cryptographic operations, and validators.ts for input validation.
/tests: Contains unit and integration tests. The /unit directory will have tests for individual functions, while /integration will test the interaction between different parts of the SDK.
Potential risks include:
Integration challenges with ComposeDB and Safe Transaction Service.
Unidentified bugs emerging in production.
Performance bottlenecks.
Security vulnerabilities.
Risks Prevention:
Maintain open communication channels with all stakeholders.
Implement a robust testing strategy, including unit, integration, and stress tests.
Use version control best practices.
Provide comprehensive documentation.
Engage with the developer community for feedback.
Monitor the SDK's performance and usage post-deployment.
The dSafe SDK represents a significant step towards decentralizing Safe transactions. Through its integration with ComposeDB and the Safe Transaction Service, it promises to offer developers and stakeholders a robust, secure, and transparent toolset.
This document provides a technical overview of the dSafe SDK. Here we’ve collected an outline of the SDK's goals, functionalities, architecture, and other aspects.
The dSafe SDK aims to offer a decentralized alternative to the Safe Transaction Service. By leveraging ComposeDB for data storage, the primary objective is to enhance security, reliability, and transparency in managing Safe transactions.
Deploy new Safe and store its details in ComposeDB.
Create a new transaction message, sign it, and store it in both ComposeDB and Safe Transaction Service.
Retrieve all stored transaction messages from ComposeDB.
Add confirmation to existing transaction messages.
Execute transaction messages that meet the threshold.
Decode transaction message data.
Manage delegates: fetch, add, and delete.
Fetch Safe details and transactions.
Support forwarding of requests to Safe Transaction API for API endpoints that are not yet implemented. (Similar to Reverse Proxy but on SDK side)
Efficient performance with quick execution.
Secure data handling and input validation.
Maintainable code with comprehensive documentation.
Cross-framework compatibility (independent of framework like React, Vite etc).
Optimized package size for quick installations.
Clear error handling and messaging.
The SDK will convert the following Safe Transaction Service API endpoints into SDK methods:
The SDK will adopt a modular design, ensuring scalability and maintainability. The directory structure will be organized into core functionalities and utilities, with comprehensive testing and documentation.
/dSafeSDK
|-- /src
| |-- /core
| | |-- index.ts
| | |-- dataDecoder.ts
| | |-- delegates.ts
| | |-- multisigTransactions.ts
| | |-- safes.ts
| |-- /utils
| | |-- helpers…
|-- /tests
| |-- /unit
| |-- /integration
|-- package.json
|-- tsconfig.json
|-- README.md
/core: This directory contains the main logic for the SDK. Each file corresponds to a set of related functionalities, e.g., dataDecoder.ts contains functions related to data decoding.
/utils: This directory contains utility functions that are used across the SDK. For instance, apiHelper.ts might contain functions to make HTTP requests, crypto.ts for cryptographic operations, and validators.ts for input validation.
/tests: Contains unit and integration tests. The /unit directory will have tests for individual functions, while /integration will test the interaction between different parts of the SDK.
Potential risks include:
Integration challenges with ComposeDB and Safe Transaction Service.
Unidentified bugs emerging in production.
Performance bottlenecks.
Security vulnerabilities.
Risks Prevention:
Maintain open communication channels with all stakeholders.
Implement a robust testing strategy, including unit, integration, and stress tests.
Use version control best practices.
Provide comprehensive documentation.
Engage with the developer community for feedback.
Monitor the SDK's performance and usage post-deployment.
The dSafe SDK represents a significant step towards decentralizing Safe transactions. Through its integration with ComposeDB and the Safe Transaction Service, it promises to offer developers and stakeholders a robust, secure, and transparent toolset.
<100 subscribers
<100 subscribers
No activity yet