On release, the Zodiac package is supposed to be published to NPM and GitHub Packages.

Publishing to GitHub Packages fails:

Publishing to NPM works as expected.

I've made the issue in the zodiac-modifier-delay repo here https://github.com/gnosis/zodiac-modifier-delay/issues/24 but this should affect all modules.

see: safe-global/safe-smart-account#461

This will also resolve this compiler warning we're seeing when depending on Modifier.sol:

Warning: Unexpected NatSpec tag "notice" with value "Set correct size of returned array." in inline assembly.
   --> @gnosis.pm/zodiac/contracts/core/Modifier.sol:140:9:

Every time a new Reality Module is set up we must check the configuration parameters and send a notification in Discord if the configuration is not safe.

By extending OwnableUpgradeable we also extend open zeppelin Initializable contract, which provides the initializer modifier that we can use in setUp functions instead of having additional initialized var in FactoryFriendly contract.

We should update this in Zodiac, along with all of the modules.

• Zodiac
• Reality module
• Bridge module
• Exit module
  • Circulating supply
• Delay modifier
• Scope guard

Sometimes users want to deploy modules other than our predefined modules.
Our helper scripts for the ModuleProxyFactory do not allow this, so users are forced to write their own deploy scripts.
We should allow users to point to any address as their mastercopy.

the KnownContracts.FACTORY is kinda unknown on goerli 😅

https://github.com/gnosis/zodiac/blob/9e7d8c981817850a8a6e563919d35268e1f7917f/src/factory/constants.ts#L21
https://github.com/gnosis/zodiac/blob/9e7d8c981817850a8a6e563919d35268e1f7917f/src/factory/constants.ts#L50
https://goerli.etherscan.io/address/0x00000000062c52e29e8029dc2413172f6d619d85

Prize Bounty
$3,000 in Dai, three different prizes, see below.

Challenge Description

Ssshhh 🤫, Zodiac hasn't been announced. We wanted to give you a sneak peak, but please don't shout about it on Twitter just yet.

Zodiac is a standard for designing and building modular and composable DAOs and DAO tooling. The core pattern for Zodiac is the decoupling of accounts with decision making logic, in a way that is agnostic to the decision making mechanism.

Zodiac defines three contract types:

• Accounts: The address that holds balances, owns systems, executes transaction, is referenced externally, and ultimately represents your DAO. Our prototype for this is the Gnosis Safe, but it could be any contract that exposes the Executor interface.
• Modules: Contracts that are enabled by an Account and implement some decision making logic. They should import Module.sol.
• Modifiers: Contracts that sit between Modules and Accounts to modulate the Module's behaviour. They might enforce a timelock or limit the scope of addresses or functions a module is allowed to call, for example. Modifiers should import Modifier.sol

For this challenge, you should build a Zodiac compliant Module or Modifier.

Please reach out in the #gnosisDAO channel on chat.gnosis.io if you have any questions.

Submission Requirements

Submissions must be open source, so that judges can review the sources and implementation, and should include a demo video.

Judging Criteria

Prizes will be awarded to the project that create a novel and interesting module to the Gnosis Safe using the new Zodaic standard.
Projects must articulate what their module does, what problems it solves, how they imagine DAOs using it, and provide a video demo.

Winners will be decided by the Gnosis team.

$1,000 each to our three favorite Zodiac compliant Safe modules.

Winner Announcement Date

On or around September 14, 2021

Resources

Zodiac repo: https://github.com/gnosis/zodiac
Gnosis Safe Core SDK: https://github.com/gnosis/safe-core-sdk

Is your feature request related to a problem? Please describe.
More than one answer for a proposal question at Reality.eth

Describe the solution you'd like
We should first focus on sending a notification on every new answer.
We probably need a new sentinel and autotask triggered every time a LogNewQuestion is emitted where the user value is one of the Reality Modules (this new autotask must be given the question ID of the new question).
That autotask must create a sentinel that sends notifications on LogNewAnswer events for the question ID.

This requires #97

Things we need to get done before announcing Zodiac

• Complete audit of all Zodiac and module contracts. @auryn-macmillan

• Tag a github release of Zodiac. @auryn-macmillan

  • Publish new version of Zodiac to NPM @cbrzn

• Tag a new release of each of the modules @auryn-macmillan

  • Add singleton library to each module @cbrzn / @carlosfebres
  • Update yarn.lock in modules. @auryn-macmillan
  • Deploy master copies via the singleton factory. @cbrzn
  • Also deploy the module factory via the singleton factory. @auryn-macmillan
  • Update master copy addresses in Zodiac repo

• Deploy and publish the Safe app. @carlosfebres

  • Update master copy addresses in Safe App @carlosfebres
  • Also in any zodiac or module documentation @carlosfebres / @cbrzn
  • Update oracle address to Reality V3 in documentation and safe app. @cbrzn
  • finalize any design / front end changes (including new logos) @samepant / @carlosfebres

• Make sure SafeSnap supports the new version of the Reality module and RealityV3 contracts. @carlosfebres

• Make sure all documentation is up-to-date. @keikreutler

• Relax and enjoy the launch 🍻

Prize Bounty
$3,000 in Dai, three different prizes, see below.

Challenge Description

Ssshhh 🤫, Zodiac hasn't been announced. We wanted to give you a sneak peak, but please don't shout about it on Twitter just yet.

Zodiac is a standard for designing and building modular and composable DAOs and DAO tooling. The core pattern for Zodiac is the decoupling of accounts with decision making logic, in a way that is agnostic to the decision making mechanism.

Zodiac defines three contract types:

• Accounts: The address that holds balances, owns systems, executes transaction, is referenced externally, and ultimately represents your DAO. Our prototype for this is the Gnosis Safe, but it could be any contract that exposes the Executor interface.
• Modules: Contracts that are enabled by an Account and implement some decision making logic. They should import Module.sol.
• Modifiers: Contracts that sit between Modules and Accounts to modulate the Module's behaviour. They might enforce a timelock or limit the scope of addresses or functions a module is allowed to call, for example. Modifiers should import Modifier.sol

For this challenge, you should integrate the Gnosis Safe into an existing DAO framework: Aragon, Boardroom, Colony, Compound Governance, DAOhaus, DAOStack, Moloch, Talley, OZ Governance, etc.

The integration should make sure of the IExecutor interface on the Gnosis Safe to allow the DAO to control Gnosis Safe via the executeModuleTransaction() function. For any DAO framework that can execute arbitrary contract calls, there is no real contract work to be done, everything should work out of the box. So this challenge will be primarily front-end.

You can use the SafeSnap plugin for Snapshot integration as an example. The weenus test space is a live example that you can play with.

Please reach out in the #gnosisDAO channel on chat.gnosis.io if you have any questions.

Submission Requirements

Submissions must be open source, so that judges can review the sources and implementation, and should include a demo video.

Judging Criteria

Prizes will be awarded to the projects that create the most user friendly and production ready integrations into any of the DAO frameworks listed above. Submissions for integrations into other DAO frameworks will also be considered.
Projects must articulate what their module does, what problems it solves, how they imagine DAOs using it, and provide a video demo.

Winners will be decided by the Gnosis team.

$1,000 each to our three favorite integrations.

Winner Announcement Date

On or around September 14, 2021

Resources

Zodiac repo: https://github.com/gnosis/zodiac
Gnosis Safe Core SDK: https://github.com/gnosis/safe-core-sdk

According to the docs, we should be able to see this:
https://gnosis.github.io/zodiac/docs/tutorial-module-bridge/get-started

However, this is the actual "ALL APPS" view, with no Zodiac:

We've introduced some changes to ModuleProxyFactory.sol over the last year, meaning singleton-deployment now produces a different address. We should either:

1. revert the changes so that singleton-deployment produces the same address
2. mine a new vanity address using the current version and deploy it to each network, making sure to update everywhere relevant to the new factory address.

It would be good to have a github ci action for prs to check if all tests pass.

Description:

Gnosis Safe is the go to solution for Multisigs and blockchain vault, and Aragon provides governance solutions for communities.

For this challenge, you should integrate the Gnosis Safe into Aragon Client. The idea is that an Aragon DAO can add a Gnosis Safe vault to the DAO, and this safe can be controlled by it.

The integration should make sure of the IAvatar interface defined in the Zodiac standard on the Gnosis Safe to allow the DAO to control Gnosis Safe via the executeModuleTransaction() function. There is no real contract work to be done, everything should work out of the box. So this challenge will be primarily front-end, creating an Aragon app for Aragon Client.

You can use the SafeSnap plugin for Snapshot integration as an example, and the DAOHaus minion app for gnosis safe as well.

Prize: One prize of $4,000 paid in USDC

Time commitment: 1 week

Submission requirements: Code repository for a working Aragon Client App that fulfills the description (App created using Aragon UI and following Aragon guideline - https://hack.aragon.org/docs/tutorial)

Judging criteria: Fulfills all requirements, and provides the best UI.

Winner announcement date: 27th of November

Resources:

• Aragon Apps Tutorial
• Zodiac repo
• Zodiac docs
• Gnosis Safe Core SDK
• Ethers-multisend library (not production ready)
• React-multisend library (not production ready)

Describe the bug
I guess I broke it :(

[4/4] 🔨  Building fresh packages...
⠁
⠁
⠁
error /node_modules/@gnosis.pm/zodiac: Command failed.
Exit code: 127
Command: patch-package
Arguments:
Directory: /node_modules/@gnosis.pm/zodiac

Adding patch-package at the post-install step was a mistake as yarn is trying to execute that step even when installing the package as a dependency. Maybe we should try moving it to generate types step which is called when trying to make a build, so no post install will be called when adding the package to other pojects.

To Reproduce
just try to yarn add the package

Expected behavior
To succeed.

Screenshots / logs
If applicable, add screenshots and/or logs to help explain your problem.

Relevant environment details:

• OS: [e.g. iOS]
• Browser [e.g. chrome 22, safari]
• Node version [e.g. 14.17.4]
• etc

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
The preliminary question resolution as Reality.eth doesn't reflect the outcome returned by the Snapshot API.

Describe the solution you'd like
When a new answer comes in via the LogNewAnswer event from above, we must check that the answer in the event corresponds with the resolution in the Snapshot Space. Using the ENS from the template and the snapshot proposal hash to identify the related Snapshot proposal. The proposal hash is in the data section of the LogNewQuestion event

Requires #95 Since it's really an improvement of that.

Describe the bug
The titles on test contracts are wrong

example

There appears to be a TypeScript error with the Reality Module in the Zodiac App in Gnosis Safe. When I click the 'Add Module' button (after entering a valid TemplateId), there is no response, and the following error shows in DevTools:

Error deploying module: TypeError: Cannot read properties of undefined (reading 'realityETH')

The attached vid also shows the error.