11 | 
2 |
3 | # dOrg Ecosystem
4 |
5 | dOrg is a self-organizing Ethereum development agency.
6 |
7 | - [Website](https://dorg.tech) - client entry point
8 | - [Handbook](https://docs.dorg.tech) - agent entry point
9 | - [DAO](https://alchemy.daostack.io/dao/0x15344ecdc2c4edfcb092e284d93c20f0529fd8a6)
10 | - [DAO Launcher](https://launch.dorg.tech)
11 |
12 | ## This Repo
13 |
14 | - [brand](brand) - brand assets & guideline
15 | - [legal](legal) - legal agreements
16 | - [proposals](proposals) - public proposals for external engagements
17 | - [issues](https://github.com/dOrgTech/Ecosystem/issues) - open bounties for internal improvements
18 |
--------------------------------------------------------------------------------
/proposals/Alchemy/00-template.md:
--------------------------------------------------------------------------------
1 | # RFC-00: Template
2 |
3 | ## User Story
4 |
5 | ### Current
6 | A brief summary of the current user flow.
7 |
8 | ### New
9 | 1 or 2 sentences about the desired outcome.
10 |
11 | As a `[type of user]` I want to `[some goal]`, so that `[some reason]`.
12 |
13 | ## Impact on Adoption
14 |
15 | How will this lead to further adoption for DAOstack?
16 |
17 | ## Roadmap
18 |
19 | | Time | Workload | Description |
20 | |-|-|-|
21 | | X weeks | 1.0 FT | ... |
22 | | Y weeks | 1.0 FT | ... |
23 | | ... | ... | ... |
24 |
25 | ## Detailed Design
26 |
27 | This is the main section of the RFC. What does the proposal include? What are
28 | the proposed interfaces/APIs? How are different affected parties, such as users,
29 | developers or node operators affected by the change and how are they going to
30 | use it?
31 |
32 | ## Open Questions
33 |
34 | What are unresolved questions?
35 |
--------------------------------------------------------------------------------
/org.json:
--------------------------------------------------------------------------------
1 | {
2 | "name" : "dOrg",
3 | "description" : "A full-stack freelancer agency building and running on web3.",
4 | "address" : "0x15344ecdc2c4edfcb092e284d93c20f0529fd8a6",
5 | "homepage" : "https://dorg.tech",
6 | "email" : "contact@dorg.tech",
7 | "web" : {
8 | "Github" : "https://github.com/dOrgTech",
9 | "Keybase" : "https://keybase.io/team/dorg",
10 | "Twitter" : "https://twitter.com/dOrg_tech",
11 | "LinkedIn" : "https://www.linkedin.com/company/dorg-tech/",
12 | "Medium" : "https://medium.com/dorg-tech",
13 | },
14 | "legal" : {
15 | "name" : "dOrg, LLC",
16 | "address" : {
17 | "street": "76 St. Paul St, 7th Floor, P.O. Box 369",
18 | "city" : "Burlington",
19 | "region" : "VT",
20 | "postal" : "05402",
21 | "country" : "USA"
22 | },
23 | "business-id" : "0357139",
24 | "tax-id" :"84-2930500"
25 | },
26 | "config" : {
27 | "rep-rate" : 1,
28 | "admin-thresh" : 30000,
29 | "block-freq" : "bimonthly",
30 | "client-referral" : {
31 | "commission" : 0.1,
32 | "month-limit" : 12
33 | },
34 | "agent-referral" : {
35 | "commission" : 0.05,
36 | "month-limit" : 6
37 | },
38 | },
39 | "dependencies" : {
40 | "@daostack/arc" : "0.0.1-rc.33",
41 | },
42 | }
43 |
--------------------------------------------------------------------------------
/proposals/Alchemy/11-3box-comments.md:
--------------------------------------------------------------------------------
1 | # RFC-15: 3box Comments
2 |
3 | ## User Story
4 |
5 | ### Current
6 | Currently a user needs a 3box for an Alchemy profile but a Disqus account to comment on proposals.
7 |
8 | ### New
9 | As a User I want to comment on proposals without creating Disqus account, so that we can fluidly start discussions related to proposals.
10 |
11 | As a User I want to be able to see and post messages.
12 |
13 | ## Impact on Adoption
14 |
15 | Adding a decentralized messaging component inside proposals will reduce user frictions and increase user engagement. It will make the whole app a more integrated experience without reliance on centralized third-parties.
16 |
17 | ## Roadmap
18 |
19 | | Time | Workload | Description |
20 | |-|-|-|
21 | | 3 week | 1 FT | Steps 1-9 |
22 |
23 | ## Detailed Design
24 |
25 | Based of 3box documentation https://docs.3box.io/build/web-apps/messaging/persistent-threads
26 |
27 | We are going to use persistent threads for our messages.
28 |
29 | ### Steps to take
30 |
31 | 1. Configure "3box threads" on alchemy.
32 |
33 | 2. Authenticate to a 3box space where a thread is stored in order to perform operations such as creating a thread, joining a thread, posting messages, removing messages
34 |
35 | 3. Add ability to create new threads
36 |
37 | 4. Add ability to join a thread.
38 |
39 | 5. Add ability to view messages of a thread.
40 |
41 | 6. Add ability to post messages on a thread.
42 |
43 | 7. Add ability to delete message.
44 |
45 | 8. Add the ability to send messages to one specific proposal.
46 |
47 | 9. List messages that belong to each proposals.
48 |
49 | ## Open Questions
50 |
51 | - Do we want the ability to update and delete messages?
52 |
53 | - Do we want to include the DAO Wall? (DAO forum unrelated to particular proposals)
54 |
55 | - There is a feature to add moderators. Do we want that as well?
56 |
--------------------------------------------------------------------------------
/proposals/Alchemy/06-ens-manager.md:
--------------------------------------------------------------------------------
1 | # RFC-06: ENS Manager
2 |
3 | ## User Story
4 |
5 | ### Current
6 |
7 | User must navigate between `EthRegistrar`, `EnsRegistry` and `EnsPublicResolver` plug-ins to call individual functions on respective ENS contracts. There is no place in Alchemy to view the DAO's ENS Names.
8 |
9 | ENS Names don't render in the Member List or Proposals.
10 |
11 | ### New
12 |
13 | User enters "ENS Dashboard", where they can manage all domains owned by the DAO. Editing or adding any new domains will trigger a proposal on the respective ENS contract.
14 |
15 | If the ENS Dashboard is not added, there will be a button on this section that will create all 3 plug-in manager proposals.
16 |
17 | Throughout the UI, ENS Names render properly.
18 |
19 | ## Impact on Adoption
20 |
21 | This would significantly improve DAOstack's interoporability with the web3 ecosystem which is increasingly utilizing ENS.
22 |
23 | ## Roadmap
24 |
25 | | Time | Workload | Description |
26 | |-|-|-|
27 | | 1 week | 1.0 FT | Dashboard UI - Design |
28 | | 2 weeks | 1.0 FT | Dashboard UI - Implementation |
29 | | 2 weeks | 1.0 FT | Registration/Update Functionality + Interacting with ENS Contracts |
30 |
31 | ## Detailed Design
32 |
33 | 1. Dashboard UI - new section accessible through side bar for viewing and managing ENS domains
34 |
35 | - Table with registered ENS Names
36 |
37 | - Each entry has "edit" button that triggers a modal with basic options like set resolver or content hash. Advanced tab shows all possible actions.
38 |
39 | - Button to register a new ENS Name
40 |
41 | 2. Registration/Update Functionality: Actions in the dashboard generate proposals in the respective plug-in.
42 |
43 | 3. Reading from ENS Contracts
44 |
45 | - ENS Name Resolution: Allow proposal recipients to be ENS Names
46 |
47 | - Reverse Resolution: Display ENS Name wherever addresses are displayed (DAO members or proposal)
48 |
49 | ## Open Questions
50 |
51 | None
52 |
--------------------------------------------------------------------------------
/proposals/Alchemy/04-documentation-overhaul.md:
--------------------------------------------------------------------------------
1 | # RFC-04: Documentation overhaul
2 |
3 | ## User Story
4 |
5 | ### Current
6 | Learning to develop new features and integrations for Alchemy is a complicated task. Developers that are new to this software commonly have a hard time finding how they can:
7 | - setup their local environment
8 | - how to add new functionality (generic actions)
9 | - how to setup a test DAO
10 | - how to modify the test DAO
11 |
12 | This is partly because there is not a lot of simple documentation that can help guide the developer. Currently, developers can:
13 | - Go to the Alchemy repository, which has its own [documentation](https://github.com/daostack/alchemy/tree/dev/docs).
14 | - The previous documentation it's hard to understand (Why? Because there's no a clear path to take) and the user doesn't know where to start. We should clarify what are the different case of uses and how you should start your local environment.
15 | - Additionally the alchemy documentation is out of date.
16 | - There's no mention of Hackers Kit so some users don't even know it exists.
17 |
18 | ### New
19 |
20 | As a developer I want to go to Alchemy and see good documentation, so I can save time and just go to tackle the problem I came to resolve. This way I don't need to understand the entire app to build my functionality.
21 |
22 | ## Impact on Adoption
23 |
24 | This will allow more developers to build on the stack, and improve the usability of the platform, making DAOstack more robust.
25 |
26 | ## Roadmap
27 |
28 | | Time | Workload | Description |
29 | |-|-|-|
30 | | 1 week | 2.0 FT | Improve Alchemy documentation, creating a simple step by step guide for new developers who'd like to modify or extend Alchemy, move this to the Hacker's Kit with additional learning materials. |
31 |
32 | ## Detailed Design
33 |
34 | We want to make a clear and easy to understand documentation.
35 |
36 | First of all, remove the documentation from the Alchemy repository and make the DAO Hackers Kit the only source of truth of how to develop on Alchemy, this way, if there's a modification, we only edit the Hackers Kit, making it easier to avoid misinformation between the two repositories.
37 |
38 | The sections that will be covered are:
39 | - Set up: How to start your local environment and how you can work with ganache (local) or rinkeby (testnet). Starting up your own subgraph or working with docker? Why and when do what (Depending on developer objective)
40 |
41 | - Development: Add a DAO to your local subgraph, as well as adding and removing schemes into already existing DAOs
42 |
43 | - Upgrades: Create a new generic scheme and add it into your DAO
44 |
45 | - Tests: How to set up you environment to run integration tests
46 |
47 | ## Open Questions
48 |
--------------------------------------------------------------------------------
/proposals/Alchemy/05-abridged-integration.md:
--------------------------------------------------------------------------------
1 | # RFC-05: Abridged Integration
2 |
3 | ## User Story
4 |
5 | ### Current
6 | If a new user wants to interact with Alchemy, they needs to download a browser extension in order to be able to log in into the dApp and also needs to buy ether if they wants to create a proposal/stake/vote.
7 |
8 | ### New
9 | As a new user I want to login with my email and password. I will not be required to download any additional browser extensions to interact with the blockchain. I will also be able to buy crypto with my fiat money (credit / debit cards).
10 |
11 | ## Impact on Adoption
12 |
13 | This will lower the bar for new user onboarding dramatically, as it will be similar to a traditional web2 application's onboarding process. More details on this way of thinking about web3 onboarding can be found here: https://medium.com/abridged-io/layer-2-first-developer-flow-the-first-2-minutes-217c2bfd5868
14 |
15 | ## Roadmap
16 |
17 | | Time | Workload | Description |
18 | |-|-|-|
19 | | 4 weeks | 1.0 FT | Create the actions for login/sign up, for this actions we are going to create a class to manage the auth methods to allow the user web3 attributes (address) to interact with alchemy functionalities |
20 | | 1 week | 1.0 FT | Implement Crypto On-Ramps with Ramp Instant |
21 |
22 | ## Detailed Design
23 |
24 | - Create views for traditional auth - Register and Login
25 | - We are going to modify the web3reducer to handle the "traditional users", creating a new enum which is going to be `userType`, this way can differentiate how the did the user authenticate into the application; and a method
26 | - When the user signs up, we are going to initialize [Archanova SDK](https://github.com/netgum/archanova/blob/develop/docs/sdk/configuration.md) to store user credentials on the database.
27 | - When the user logs in for the first time, a unique ENS Label is going to be generated, and a new account is going to be created; after that, a device will be connected to the account (which is the device where the user is logging in). At last, a encrypted key store is going to be generated and saved into the db, so when the user logs in again, we pass it to the initialization of the SDK and they can get back is account. NOTE: If user loses his password they can not take his account back.
28 | - Implement the [`submitAccountTransaction`](https://playground.archanova.run/#send_account_transaction) method from the sdk so the user can vote/stake/propose.
29 |
30 | - Create a "Buy crypto" module for web2 (traditional users), so they can pay for gas tx; here the user can pay for ETH with fiat
31 | - We are going to use [Ramp instant SDK](https://instant.ramp.network/) to allow new users to buy ether with USD or EUR.
32 |
33 | This is an example app with abridged integration: https://github.com/odyssy-automaton/moloch-pokemol
34 |
35 | ## Open Questions
36 |
37 | None
--------------------------------------------------------------------------------
/proposals/Alchemy/09-dao-components.md:
--------------------------------------------------------------------------------
1 | # RFC-09: DAOcomponents
2 |
3 | ## User Story
4 |
5 | As a small team developing a widely used protocol (DeversiFi, Bancor, Orchid, Totle, Compound), I am considering to use DAOstack to transition protocol governance to users and major stakeholders.
6 |
7 | As the administrator of a large hackathon, meetup, or events community (Odyssey, ETHGlobal, FestDAO, Crypto Mondays, Bitcoin Malaysia, 1 Mil Devs), I am considering to use DAOstack to transition community governance to members.
8 |
9 | I want my users to interact with the DAO from within my website or app instead of sending them to Alchemy so that I control the end-to-end user experience.
10 |
11 | ### Current
12 | Use the [Client library](https://github.com/daostack/client) directly. With this approach there is a large learning curve, and it's not obvious how to integrate the library with a React application.
13 |
14 | The library does complex asynchronous actions, and handling that elegantly within your React applications is additional work that each application will have to do on their own.
15 |
16 | Additionally the application will have to do additional work to reduce boilerplate code, as different sub pieces of the UI will need a shared context (Members, Proposals, etc).
17 |
18 | ### New
19 |
20 | With DAOcomponents, I can DAO-enable my React app by adding just 2 components. The library seamlessly handles all loading, error handling, re-rendering, or boilerplate for me under the hood.
21 |
22 | ## Impact on Adoption
23 |
24 | - Horizontally scale the stack by making it an order of magnitude easier to interact with from other front-ends.
25 |
26 | - Generate buzz & attract major crypto protocols to use DAOstack by showing how they can integrate it into their existing front-ends with a few lines of code.
27 |
28 | ## Roadmap
29 |
30 | | Time | Workload | Description |
31 | |-|-|-|
32 | | 2 weeks | 1.0 FT | Update for client 2.0 |
33 | | 3 weeks | 1.0 FT | Demo App + Documentation |
34 |
35 | ## Detailed Design
36 |
37 | Here's a short tutorial that shows how simple this is:
38 |
39 | 1. Add DAOcomponents to your React project...
40 | `npm i --save daocomponents`
41 |
42 | 2. Connect to the Arc protocol + your DAO...
43 | `App.jsx`
44 | ```html
45 | 
27 |
28 |
29 | Size of menu item should be bigger
30 | 
31 |
32 |
33 | Size of menu item should be bigger and dao holdings should be better aligned
34 | 
35 |
36 |
37 | Scheme cards border should be resized to fit mobile screens
38 | 
39 |
40 |
41 | Proposal cards should be resized to fit mobile screens
42 | 
43 |
44 | Params hash should be wrapped inside the box versus overflowing the box
45 | 
46 |
47 | There is a lot of dead space between the "New Genesis Protocol" button and the icon
48 | 
49 |
50 | Copy to Clipboard icons should fit inside the box
51 | 
52 |
53 | To much dead space in my opinion here
54 | 
55 |
56 | Either resize the box or make it so that copyclipboard and address/params hash fit the box
57 | 
58 |
59 | Buttons should be aligned better
60 | 
61 |
62 | Text should fit inside the box
63 | 
64 |
65 | Inputs should not be overflowed
66 | 
67 |
68 | This is how it should fit in mobile versus the above
69 | 
70 |
71 | Tooltip for menu items should be positioned better
72 | 
73 |
74 | ProfileInfo Box should be resized to fit mobile screen
75 | 
76 |
77 | ## Open Questions
78 |
79 | None
--------------------------------------------------------------------------------
/proposals/Alchemy/02-voting-configuration-editor.md:
--------------------------------------------------------------------------------
1 | # RFC-02: Voting configuration editor
2 |
3 | ## User Story
4 |
5 | ### Current
6 | Editing a DAO plugin's voting machine configuration is currently super complicated. Users do not have an easy to use interface within Alchemy for doing this. Currently, a user must:
7 |
8 | - Find the address of the Genesis Protocol contract they want to use with their scheme.
9 | - Add the voting parameters they want to use to the contract if they aren't already present. This can cause problems because the parameters need to be validated (sent in certain order, max-min values); and this will make the tx fail.
10 | - Save the params hash for their parameters.
11 |
12 | From here there are two possible paths, based on if the scheme is universal or non-universal. For universal schemes the user would need to:
13 | - Call [setParameters](https://github.com/daostack/arc/blob/master/contracts/universalSchemes/ContributionReward.sol#L99) on the universal scheme with the voting machine address and their voting params hash.
14 | - Save the scheme's params hash.
15 | - Create a scheme registrar proposal to "edit" the existing scheme, and insert the scheme's params hash that was save previously.
16 |
17 | For non-universal schemes the user would need to:
18 | - Instantiate a new instance of the scheme that they want to modify.
19 | - Call `initialize(...)` on this new instance with the voting machine's address and params hash.
20 | - Add the non-universal scheme to the subgraph.
21 | - Create 2 scheme registrar proposals, one to remove the old scheme, and one to add the new scheme.
22 |
23 | NOTE: The "non-universal" workflow will be improved with Arc Hives in the "new" version of alchemy. For the sake of this proposal, we'll focus on the universal workflow. 80% of the code for editing params of non-universal schemes can be reused in the "new" alchemy. The only thing that will change will be how the new params are applied to the scheme.
24 |
25 | ### New
26 | As a non technical user of the DAO I want to manage and set up my organization in a particular way. If the DAO wants to change the configuration as it grows and evolves, we will be able to do it through the UI, making it easier to add a new voting configuration for the desired scheme.
27 |
28 | All I would have to do is go to the "information" tab of a scheme, click "edit" on the voting machine configuration, make my changes and click "apply". This will trigger a proposal in the DAO to apply these changes.
29 |
30 | 
31 |
32 | ## Impact on Adoption
33 | Users will start to appreciate how versatile the Genesis Protocol is in allowing their fund to curate quality proposals and scale effectively over time.
34 |
35 | Additionally, this will remedy issues that a lot of DAO founders had initially with DAOstack where they were unable to change their DAO's configuration post launch.
36 |
37 | ## Roadmap
38 |
39 | | Time | Workload | Description |
40 | |-|-|-|
41 | | 2 weeks | 1.0 FT | Client Updates: Voting Machine Form (`@dorgtech/daocreator-lib` has this already), Set Voting machine Params, Get Voting Params Hash |
42 | | 2 weeks | 1.0 FT | Alchemy Updates: Edit Voting Params Button + Form Fields, Save Voting Params Button, Post Scheme Registrar Proposal |
43 |
44 | ## Detailed Design
45 |
46 | We want to modify the existing "plugin information" view to allow for users to make edits to the genesis protocol form, and "save" those changes to their DAO. This will prompt the users with 3 transactions:
47 |
48 | - Add the parameters to the voting machine (Genesis protocol contract instance).
49 | - Add the parameters to the universal scheme.
50 | - Create a proposal on Plugin Manager to edit the plugin being modified.
51 |
52 | We need to do this with every scheme, one by one, we are going to start with the universal ones (Funding and Voting Power & Plugin Manager).
53 |
54 | ## Open Questions
55 |
56 | None
57 |
--------------------------------------------------------------------------------
/proposals/Alchemy/03-nft-support.md:
--------------------------------------------------------------------------------
1 | # RFC-03: NFT Support
2 |
3 | ## User Story
4 |
5 | ### Current
6 | Alchemy currently lacks the ability to display, transfer, create and sell NFTs (ERC721s and ERC1151).
7 |
8 | ### New
9 | As an artist, I want to collaborate with other artists and create/sell NFT art on OpenSea (to share profit) with a storefront or through bundling.
10 | As an organisation, I want to award NFTs (badges/awards).
11 | As a user, I want to be able to see what NFTs a DAO owns and use them to create a revenue model.
12 |
13 | ## Impact on Adoption
14 | This would allow large brands to run promos using DAOs that issue NFTs. It could also serve as a bridge to on-board the large community of NFT enthusiasts / artists on platforms such as OpenSea.
15 |
16 | ## Roadmap
17 | | Time | Workload | Description |
18 | |-|-|-|
19 | | 2 weeks | 1.0 FT | Adds a basic view to the Alchemy DAO dashboard for viewing owned NFTs (with basic metadata support for images). Adds transfer support through new nft support scheme that is accessed either through the scheme create proposal menu or through the new view. |
20 | | 3 weeks | 1.0 FT | Adds a view for deployed NFTs that displays basic information and allows the creation of new tokens and the updating of their metadata using the new creation scheme. |
21 | | 2 weeks | 1.0 FT | Polish previous additions with feedback rounds. Adds built in support for 3rd party sellers (mintbase/opensea). Adds special support for certain tokens such as ENS. |
22 |
23 | ## Detailed Design
24 |
25 | This proposal outlines how with the addition of 2 new generic schemes, users will be able to add NFT functionality to their DAOs.
26 |
27 | #### 1 - NFT Support Scheme
28 |
29 | ##### Functionality
30 | - Gives DAOs the ability to transfer NFTs (whitelisted NFTs are selectable from drop-down, with optional manual override for unwhitelisted tokens)
31 | - Gives DAOs the ability to list owned tokens for sale on OpenSea and accept existing orders (in Eth or ERC20s)
32 | - Gives DAOs the ability to whitelist NFTs (The front end will be aware of whitelisted NFTs)
33 |
34 | ##### Architecture
35 | - The NFT Support generic scheme needs to be created
36 | - The NFT view needs to be created to show owned NFTs
37 | - Query metadata (image, name, sale status, owned status, etc...)
38 | - Updates on whitelisted NFT transfers
39 | - Custom views for special NFTs (eg. ENS)
40 | - The NFT Support proposal forms need to be created
41 | - Whitelisting
42 | - Transfering
43 | - Sale listing
44 | - Offer handling
45 | - Updating metadata (for DAO owned NFTs)
46 |
47 | #### 2 - NFT Creation Scheme:
48 |
49 | ##### Functionality
50 | - Gives DAOs the ability to deploy new NFT Contracts
51 | - Gives DAOs the ability to create new NFTs from these contracts
52 | - The created NFTs can be transfered
53 | - The created NFTs can be listed for sale on OpenSea (in Eth or ERC20s)
54 | - The created NFTs can have their metadata updated
55 |
56 | ##### Architecture
57 | - The NFT Creation generic scheme needs to be created
58 | - The generic NFT contracts that will be deployed by this scheme need to be created
59 | - The Created NFT view needs to be created to show created NFT contracts
60 | - Query metadata (image, name, count, etc...)
61 | - The NFT creation proposal forms need to be created
62 | - Deploying new NFT contracts
63 | - Minting new NFTs from existing NFT contracts
64 | - Sale handling
65 | - Offer handling
66 | - Updating metadata
67 |
68 | ## Open Questions
69 | - Which token standards should be supported?
70 | - Are there "super" NFT contracts where single contract addresses are used for multiple NFTs.
71 | - Are there many NFTs that fail to follow the token standards?
72 | - Where will created NFT metadata be stored?
73 | - Which contract model should be used for the NFT Creation Scheme (NFT specific contract, DAO specific NFT contract, or a super generic NFT contract used by all DAOs)
74 |
--------------------------------------------------------------------------------
/proposals/DAOstack/01-Milestone.md:
--------------------------------------------------------------------------------
1 | *An overview of dOrg's progress in the 1st month (Oct 1 - 31) of our six month engagement with Genesis DAO.*
2 |
3 | *For context, [see the recurring proposal here](00-Recurring-Funding.md).*
4 |
5 | # DAOcreator
6 |
7 | *In addition to several UX and functionality improvements, we got mainnet deployments working and finished specifying DAOcreator beta.*
8 |
9 | - **Mainnet deployments** now supported inside the app!
10 | - Detailed warnings and instructions
11 |
12 | 
13 |
14 | - Full, exportable deployment log
15 |
16 | 
17 |
18 | - **Import DAO** now supported
19 |
20 | 
21 |
22 | - Improved [import members from CSV sanitation](https://github.com/dOrgTech/DAOcreator/issues/215)
23 | - [Subgraph PR](https://github.com/daostack/subgraph/pull/215) and [DAOtracker PR](https://github.com/daostack/arc/pull/640) fixed and merged - this lays the groundwork for automated Alchemy support!
24 | - Beta release redesign specified and timelined
25 |
26 | ### Future
27 |
28 | - Automated Alchemy support (Integrate DAOtracker to the migration scripts and subgraph)
29 | - Design and iterate on new design mock-ups with community research
30 | - Begin implementing functional version of DAOcreator beta from wireframes
31 |
32 | # Use Cases & Integration
33 |
34 | - **Gasless Rep Redeem**: Allows ReputationFromToken to be redeemed without needing any gas in order to support seemless onboarding for future dHacks and DAOfests. [[problem](https://github.com/dOrgTech/Ecosystem/issues/17)] [[solution](https://github.com/dOrgTech/TxPayerService)]
35 | - Began specifying [Reputation simulation app](https://github.com/dOrgTech/Ecosystem/issues/19) for DAOs to visualize and model changes in Rep over time.
36 |
37 | 
38 |
39 | - **_prtcl Alchemy Integration**: We've kicked off this project, and development should start around November 11th. Genesis proposal viewable [here](https://alchemy.daostack.io/dao/0x294f999356ed03347c7a23bcbcf8d33fa41dc830/proposal/0xcbdc3612e6d73cb47cdb4c44e1db18213eb0cf8c17f4870b8beca33cffbd7d3f).
40 |
41 | ### Future
42 |
43 | - Finish testing and ship Gasless Rep Redeem
44 | - Finish specifying and start implementing Rep simulation
45 | - Continue to assist in the _prtcl integration
46 |
47 | # Ecosystem
48 |
49 | - Started [DAOstack-collab](https://github.com/dOrgTech/daostack-collab/) repo on github to support joint roadmaps across technical teams in the ecosystem → forked into [DAOstack's Ecosystem repo](https://github.com/daostack/Ecosystem)
50 | - Helped to begin specifying good "first time issues" for new open-source contributors (several of which have been more fully elaborated on [here](https://github.com/daostack/Ecosystem/issues))
51 | - Launched the [DAOfest DAO](https://alchemy.daostack.io/dao/0x8990e11b69403Ea53Ef2B32434bBD7dBf84B5234) with Felipe
52 | - Presented to the Bucharest Blockchain Group on how DAOstack can be used to manage a legal entity and responsibly fundraise [[event](https://www.eventbrite.com/e/blockchain-based-llc-and-funding-tools-for-daos-tickets-74091444505)] [[presentation](https://docs.google.com/presentation/d/1fs3cufwBT4dBWqi0VB0UaVCarkauFORdBwpSXGZTSkI/edit?usp=sharing)]
53 | - Pro Bono DAO advising one legal-tech consulting agency and one mobile design agency in launching their own (dOrg style) small DAOs. We believe a proliferation of small DAOs on the platform is equally important as having several large DAOs.
54 |
55 | ### Future
56 |
57 | - Help bountify additional tasks for open-source
58 | - Help anyone else in the community launch a DAO
59 |
60 | # DAO Admin
61 |
62 | *This past period we focused heavily on bookkeeping and tax prep.*
63 |
64 | - 90% through reconciling all of dOrg's transactions with Veriledger. These will allow us to create the first official 'DAO Financial Statements'
65 | - Submitted dOrg tax election to IRS
66 | - Reseraching tax-exempt benefits for Rep holders– such as reimbursements for Healthcare, Coworking and Data expenses.
67 |
68 | ### Future
69 |
70 | - Create tax guidelines for the dOrg DAO contractors
71 | - Define reimbursement protocol for dOrg DAO contractors
72 |
--------------------------------------------------------------------------------
/brand/icon.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/proposals/DAOstack/06-Milestone.md:
--------------------------------------------------------------------------------
1 | *An overview of dOrg's progress in the 6th month (Mar 1 - 31) of our six month engagement with Genesis DAO.*
2 |
3 | *For context, [see the recurring proposal here](00-Recurring-Funding.md).*
4 |
5 | # DAOcreator
6 |
7 | - [Embeded new DAOcreator into Alchemy](https://github.com/daostack/alchemy/pull/1506)
8 |
9 |
10 |
11 |
24 | 
25 | 
26 |
18 | 
19 |
37 | 
38 |
62 | 
63 |
67 | 
68 |
77 | 
78 |
10 | 
11 |
17 | 
18 | 
19 |
45 | 
46 |
51 | 
52 |
61 | 
62 |
67 | 
68 |
92 | 
93 |
97 | 
98 |
11 | 
12 | 
13 |
40 | 
41 |
50 | 
51 | 
52 | 
53 |
78 |
79 | - **Identity DAO - MVP Complete**: We've completed our first 4 month engagment with GoodDollar, and an initial MVP of the Identity DAO is functional including:
80 | - [Identity Registry Contract](https://github.com/dOrgTech/ID-DAO/blob/dev/dao/contracts/IdentityRegistry.sol)
81 | - ["Human Reputation Claim" Scheme](https://github.com/dOrgTech/ID-DAO/blob/dev/dao/contracts/HumanReputationClaim.sol)
82 | - [DAO Deployment Scripts](https://github.com/dOrgTech/ID-DAO/blob/dev/dao/migrations/2_deploy_contracts.js)
83 | - [Javascript Client Library](https://github.com/dOrgTech/ID-DAO/tree/dev/client) Which Supports...
84 | - ID-DAO Proposals
85 | - Registry Lookup
86 | - Identity Definition Download & Upload
87 | - Identity Definition Creation & Validation
88 | - [Onboarding Tool](https://github.com/dOrgTech/ID-DAO/tree/dev/init-humans) For "Initial Humanity Set"
89 | - GoodDollar [dApp](https://github.com/dOrgTech/GoodDAPP/tree/dorg-id-dev) & [Server](https://github.com/dOrgTech/GoodServer/tree/dorg-id-dev) Integration
90 |
91 | - **[Nectar DAO Bootstrap U.I.](https://github.com/dorgtech/nectarDAO-Bootstrapper) - Launch-ready**: Rigorous testing, functionality and UX improvements in collaboration with DeversiFi and DAOstack core
92 |
93 |
94 | 
95 | 
96 | 
97 |