radicle-contracts
radicle-contracts copied to clipboard
radicle-dev
Radicle contracts on Ethereum
We should extend the `Resolver` used with the following interface https://github.com/ensdomains/ens-contracts/blob/abd49876b11041b1a39fa4ad2c07f979b024a3d4/contracts/resolvers/profiles/IExtendedResolver.sol _Reference:_ https://docs.ens.domains/ens-improvement-proposals/ensip-10-wildcard-resolution
https://eips.ethereum.org/EIPS/eip-2612
We should move big features into their own sub-folder, as it's getting a bit hard to manage. For now, just creating a `Funding` folder and a `Registrar` folder will make...
According to: https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/ and https://blog.trailofbits.com/2020/12/16/breaking-aave-upgradeability/
See https://github.com/radicle-dev/radicle-contracts/pull/28#discussion_r498750089 It may be interesting, for additional trust, to allow for signed revocations. The question is, in what situation would you revoke a `link` key, while still controlling it?
After testing the storage of the signature component with a `bytes32` tuple instead of a `byte[64]` array, it looks like we can save a lot of gas. This should be...
To allow any compatible contract to be deployed as an "Org", we should clearly define an Org interface that can be implemented by developers, and by our default org contract....
Changes in the contract APIs should be reflected in the TypeScript contract bindinings for `ethers`. However, these changes are not picked up by `yarn test` when run for the first...
See https://github.com/radicle-dev/radicle-upstream/pull/952#discussion_r494080368 for context.
