From e0f56d8a4f20348602c64df45da924a75aa5f4af Mon Sep 17 00:00:00 2001 From: Joni Pirovich <152162579+cryptococounsel@users.noreply.github.com> Date: Wed, 27 Nov 2024 12:48:10 +1100 Subject: [PATCH 01/10] Create DAOIP-9.md --- DAOIPs/DAOIP-9.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 DAOIPs/DAOIP-9.md diff --git a/DAOIPs/DAOIP-9.md b/DAOIPs/DAOIP-9.md new file mode 100644 index 00000000..13159fab --- /dev/null +++ b/DAOIPs/DAOIP-9.md @@ -0,0 +1,59 @@ +--- +daoip: 9 +title: Legal Communication +description: +author: Joni Pirovich (), Joshua Tan (@thelastjosh) +discussions-to: https://github.com/metagov/daostar/discussions/272 +status: Draft +type: +category: +created: 2024-11-26 +--- + +Simple summary +An official mechanism for DAOs to receive and send legal communications, as well as to display legal information to the public. +Motivation +The goal of this specification is to define a clear, easy method, legalURI, for communicating legal information to and from online communities—whether a DAO or other form of entity—that may or may not be recognised as legal or tax persons but that do have an on-chain presence. + +You can think of legalURI as roughly equivalent to the standard “Terms and Conditions” or “Privacy Statement” that one finds at the bottom of many websites. +Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +To comply with this specification you MUST publish a daoURI or entityURI following the EIP-4824 / DAOIP-2 DAO JSON LD Schema and add a field called “legalURI”. This URI MAY point anywhere, e.g. to a markdown file with information, a single email address such as legal@communityname.io, a webpage with terms and conditions, an IPFS file, or another smart contract address. + +```json +{ + "@context": "http://www.daostar.org/schemas", + "type": "DAO", + "name": "", + "description": "", + "legalURI": "" +} +``` + +You MAY point legalURI back to the daoURI address, which would indicate that all data published through daoURI constitutes legally-approved communication. +Rationale +This specification is intended to help online communities collate and share data and information that is relevant for legal and compliance purposes, as well as to have an official line of communication to both members and to external parties. Doing so fosters transparency and trust within the community and the broader public. + + +Having an official channel ensures that important legal communications are promptly received and addressed. DAOs can set up: +an email address dedicated to legal matters (e.g. legal@communityname.io) +a Telegram handle specifically for legal correspondence. +a dedicated channel on the official Discord server for legal notices. +Making legal information accessible to all participants is also vital. DAOs might use: +a webpage on the DAO's official site to host legal documents and updates; and/or +a designated channel on the official Discord server where legal information is posted and regularly updated. +Legal communications can include: +Requests for information from regulators or private parties. +Notices of legal proceedings initiated against the DAO or its members. +Submissions to regulators, such as policy positions or compliance documentation. +Providing clear legal information helps participants understand their rights and obligations. Examples include: +Jurisdictional disclaimers: Specifying regions where participation is restricted due to legal constraints. +Terms of participation: Outlining codes of conduct, constitutions, or operating rules for DAO members. +Terms of use for protocols: Detailing how participants can interact with the DAO governed activities and protocols. +Feature and risk disclosures: Informing participants about the functionalities and potential risks of the DAO governed protocols. +Tax treatment summaries: Offering general guidance on how interactions with the protocol may be taxed in different jurisdictions. +Tax information statements: Providing documents like spreadsheets of crypto activity per address to assist with tax compliance, such as those aligning with the OECD’s Crypto-Asset Reporting Framework. +Distribution statements: Sharing records of DAO Treasury payments or staking rewards distributed to participants. +Copyright +Copyright and related rights waived via CC0. From cfa1b9810b1fc128a12f5b529ae153296ed377ec Mon Sep 17 00:00:00 2001 From: Joshua Tan Date: Tue, 26 Nov 2024 17:52:08 -0800 Subject: [PATCH 02/10] Update and rename DAOIP-9.md to daoip-9.md formatting issues --- DAOIPs/{DAOIP-9.md => daoip-9.md} | 50 +++++++++++++++++-------------- 1 file changed, 28 insertions(+), 22 deletions(-) rename DAOIPs/{DAOIP-9.md => daoip-9.md} (59%) diff --git a/DAOIPs/DAOIP-9.md b/DAOIPs/daoip-9.md similarity index 59% rename from DAOIPs/DAOIP-9.md rename to DAOIPs/daoip-9.md index 13159fab..91a68934 100644 --- a/DAOIPs/DAOIP-9.md +++ b/DAOIPs/daoip-9.md @@ -10,13 +10,15 @@ category: created: 2024-11-26 --- -Simple summary +## Simple summary An official mechanism for DAOs to receive and send legal communications, as well as to display legal information to the public. -Motivation + +## Motivation The goal of this specification is to define a clear, easy method, legalURI, for communicating legal information to and from online communities—whether a DAO or other form of entity—that may or may not be recognised as legal or tax persons but that do have an on-chain presence. You can think of legalURI as roughly equivalent to the standard “Terms and Conditions” or “Privacy Statement” that one finds at the bottom of many websites. -Specification + +## Specification The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. To comply with this specification you MUST publish a daoURI or entityURI following the EIP-4824 / DAOIP-2 DAO JSON LD Schema and add a field called “legalURI”. This URI MAY point anywhere, e.g. to a markdown file with information, a single email address such as legal@communityname.io, a webpage with terms and conditions, an IPFS file, or another smart contract address. @@ -32,28 +34,32 @@ To comply with this specification you MUST publish a daoURI or entityURI followi ``` You MAY point legalURI back to the daoURI address, which would indicate that all data published through daoURI constitutes legally-approved communication. -Rationale -This specification is intended to help online communities collate and share data and information that is relevant for legal and compliance purposes, as well as to have an official line of communication to both members and to external parties. Doing so fosters transparency and trust within the community and the broader public. +## Rationale +This specification is intended to help online communities collate and share data and information that is relevant for legal and compliance purposes, as well as to have an official line of communication to both members and to external parties. Doing so fosters transparency and trust within the community and the broader public. Having an official channel ensures that important legal communications are promptly received and addressed. DAOs can set up: -an email address dedicated to legal matters (e.g. legal@communityname.io) -a Telegram handle specifically for legal correspondence. -a dedicated channel on the official Discord server for legal notices. +- an email address dedicated to legal matters (e.g. legal@communityname.io) +- a Telegram handle specifically for legal correspondence. +- a dedicated channel on the official Discord server for legal notices. + Making legal information accessible to all participants is also vital. DAOs might use: -a webpage on the DAO's official site to host legal documents and updates; and/or -a designated channel on the official Discord server where legal information is posted and regularly updated. +- a webpage on the DAO's official site to host legal documents and updates; and/or +- a designated channel on the official Discord server where legal information is posted and regularly updated. + Legal communications can include: -Requests for information from regulators or private parties. -Notices of legal proceedings initiated against the DAO or its members. -Submissions to regulators, such as policy positions or compliance documentation. +- Requests for information from regulators or private parties. +- Notices of legal proceedings initiated against the DAO or its members. +- Submissions to regulators, such as policy positions or compliance documentation. + Providing clear legal information helps participants understand their rights and obligations. Examples include: -Jurisdictional disclaimers: Specifying regions where participation is restricted due to legal constraints. -Terms of participation: Outlining codes of conduct, constitutions, or operating rules for DAO members. -Terms of use for protocols: Detailing how participants can interact with the DAO governed activities and protocols. -Feature and risk disclosures: Informing participants about the functionalities and potential risks of the DAO governed protocols. -Tax treatment summaries: Offering general guidance on how interactions with the protocol may be taxed in different jurisdictions. -Tax information statements: Providing documents like spreadsheets of crypto activity per address to assist with tax compliance, such as those aligning with the OECD’s Crypto-Asset Reporting Framework. -Distribution statements: Sharing records of DAO Treasury payments or staking rewards distributed to participants. -Copyright -Copyright and related rights waived via CC0. +- Jurisdictional disclaimers: Specifying regions where participation is restricted due to legal constraints. +- Terms of participation: Outlining codes of conduct, constitutions, or operating rules for DAO members. +- Terms of use for protocols: Detailing how participants can interact with the DAO governed activities and protocols. +- Feature and risk disclosures: Informing participants about the functionalities and potential risks of the DAO governed protocols. +- Tax treatment summaries: Offering general guidance on how interactions with the protocol may be taxed in different jurisdictions. +- Tax information statements: Providing documents like spreadsheets of crypto activity per address to assist with tax compliance, such as those aligning with the OECD’s Crypto-Asset Reporting Framework. +- Distribution statements: Sharing records of DAO Treasury payments or staking rewards distributed to participants. + +## Copyright +Copyright and related rights waived via [CC0](https://eips.ethereum.org/LICENSE). From db670f1fcaf059fc0da0afc67c7ef778b92b8453 Mon Sep 17 00:00:00 2001 From: Joni Pirovich <152162579+cryptococounsel@users.noreply.github.com> Date: Sat, 30 Nov 2024 10:08:24 +1100 Subject: [PATCH 03/10] Create daoip-10 --- DAOIPs/daoip-10 | 109 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 DAOIPs/daoip-10 diff --git a/DAOIPs/daoip-10 b/DAOIPs/daoip-10 new file mode 100644 index 00000000..90df9530 --- /dev/null +++ b/DAOIPs/daoip-10 @@ -0,0 +1,109 @@ +--- +daoip: 10 +title: Tax Reporting +description: +author: Joni Pirovich (), Joshua Tan (@thelastjosh), Dion Seymour () +discussions-to: https://github.com/metagov/daostar/discussions/272 +status: Draft +type: +category: +created: 2024-11-29 +--- +## Simple summary +A data standard for the presentation of DAO tax information to the public and protocol users. +## Motivation +The goal of this specification is to define a data standard that DAOs can adopt to collate on-chain information and make it publicly available in a form that assists tax administrations in assessing the tax risks associated with DAOs and that assists users to manage their tax obligations from DAO and protocol interactions. + +Tax administrations around the world care about assessing tax risk, whereas users need to calculate their taxes. Users therefore need more detailed data than tax administrations do. This standard thus makes a distinction between the data fields presented for tax administrations versus users. + +The specification has been modelled from the crypto “transfer types” used by the OECD in their Crypto-Asset Reporting Framework XML schema with some modifications for the idiosyncrasies around DAOs. For reference the transfer types specified in the OECD CARF XML schema are: staking, crypto loan, wrapping, collateral, airdrop, staking income, mining income, transfer from another reporting crypto asset service provider, sale of goods or services, other and unknown. + +Filling out the data in this specification is roughly equivalent to the content of a report produced by a crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. +## Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +To comply with this specification you MUST publish a daoURI or entityURI following the EIP-4824 / DAOIP-2 DAO JSON LD Schema and add a field called “taxURI”. This URI MAY point anywhere, e.g. to a markdown file with information, an excel file or webpage. + +```json +{ + "@context": "https://www.daostar.org/schemas", + "type": "DAO", + "name": "", + "description": "", + "taxURI": "" +} +``` + +This standard requires DAOs to present tax information via their taxURI in a standardized form. The structure of data to be presented at the taxURI is intended to be roughly equivalent to the structure of a report produced by a reporting crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. + +You MAY point taxURI back to the daoURI address, which would indicate that all data published through daoURI constitutes DAO-approved communication in respect of this standard. + +Third parties MAY present tax information in respect of a DAO or DAOs using this standard but if the information is not presented by a DAO through a DAO’s taxURI or daoURI then the information does not constitute a DAO-approved communication. + +The tax data should include the fields as set out below. +### Presentation header +PresentingDAOIN: A field that identifies the daoURI which is the identification number of the DAO presenting the tax data about crypto transfers in and out of the DAO and the protocol/s it governs +Warning: A field that allows input of specific cautionary instructions about the use of data presented +Contact: A field allowing input of specific contact information relating to the DAO, or third party engaged or in receipt of grant funding by the DAO, to prepare and present the data +PresentationID: A field for a unique identifier created by the DAO that identifies the particular data presented +PresentationType: A field that specifies the type of data presented, i.e. whether new data (Type 1), or if corrected data (Type 2), or if deleted data (Type 3) +PresentationPeriod: A field that identifies the last day of the presentation period (e.g. a tax year or other period) to which the data presented relates in yyyy-MM-DD format +Timestamp: A field that identifies the date and time when the data was compiled in yyy-MM-DD’T’hh:mm:ss.nnn format. +### Data for tax administrations +CountryNumber: A field that specifies the number of countries from which on-chain activity with the DAO or any protocol/s it governs originates +CountryList: A field allowing input of all countries identified from which on-chain activity with the DAO or any protocol/s it governs originates using the 2-character alphabetic country code and country name list based on the ISO 3166-1 Alpha 2 standard +TypeofSupply: A field allowing input of the type of supply of crypto-tokens native to the DAO +DAOTotalSupply(crypto-tokens): A field that specifies the total supply of crypto-tokens native to the DAO, circulating and non-circulating at the end of the presentation period +DAOCirculatingSupply(crypto-tokens): A field that specifies the total circulating supply of crypto-tokens native to the DAO at the end of the presentation period +DAOStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) +DAOStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) +DAOStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to persons that have staked crypto-tokens in the format NN-TICKER (e.g. 10-ETH) +DAOStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units reserved for transfer as staking rewards but yet unpaid in the format NN-TICKER (e.g. 1-ETH) +DAOCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to borrowers in the format NN-TICKER (e.g. 100-DAI) +DAOCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from borrowers in the format NN-TICKER (e.g. 100-DAI) +DAOCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from borrowers in the format NN-TICKER (e.g. 10-DAI) +DAOWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +DAOWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +DAOCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral to a protocol in the format NN-TICKER (e.g. 300-WETH) +DAOCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the users in the format NN-TICKER (e.g. 300-WETH) +DAOAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as a free distribution to persons that may or may not have interacted with the DAO or its protocol/s, in the format NN-TICKER (e.g. 1,000-UNI) +DAOTransfertoFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury for the purpose of conversion to fiat currency +DAOTransferfromFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred into a DAO’s on-chain treasury in the format NN-TICKER (e.g. 100-ETH) +DAOReceipts(crypto-tokens): A field that specifies the number of crypto-tokens transferred into a DAO’s on-chain treasury or the protocols it governs as other receipts in the format NN-TICKER (e.g. 100-ETH) +DAOSpend(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocols it governs to third party suppliers in the format NN-TICKER (e.g. 100-ETH) +DAOGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient in the format NN-TICKER (e.g. 100-ETH) +DAORevenueIn(crypto-tokens): A field that specifies the number of crypto-token units received by a DAO’s on-chain treasury or the protocol/s it governs as revenue in the format NN-TICKER (e.g. 100-ETH) +DAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions in the format NN-TICKER (e.g. 100-ETH) +### Data for users +Each data field should be populated per on-chain address. + +UserStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) +UserStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) +UserStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to the user that has staked crypto-tokens in the format NN-TICKER (e.g. 1-ETH) +UserStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units accrued as staking rewards but yet unpaid to the user in the format NN-TICKER (e.g. 1-ETH) +UserCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to the borrower in the format NN-TICKER (e.g. 100-DAI) +UserCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from a borrower in the format NN-TICKER (e.g. 100-DAI) +UserCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from a borrower in the format NN-TICKER (e.g. 10-DAI) +UserWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred from a user to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +UserWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol to the user in the format NN-TICKER (e.g. 100-ETH) +UserCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral by a user to a protocol in the format NN-TICKER (e.g. 300-WETH) +UserCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the user in the format NN-TICKER (e.g. 300-WETH) +UserAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred to a person as a free distribution, in the format NN-TICKER (e.g. 1,000-UNI) +UserGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient user +UserDAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions to a user + +Note 1: DAO’s that actively manage their Treasury should consider additional data fields particular to the treasury management activities. + +Note 2: It is assumed that DAOs have not adopted a tax position as to interest, dividend or other applicable withholding taxes. The absence of data fields in this standard for withholding tax or other taxes is not to be relied upon as advice or any indication that withholding or other taxes are not required to be collected and paid by the DAO or its participants. Each DAO and person involved in a DAO is responsible for seeking their own independent legal and tax advice, and may include additional such fields or other fields as necessary and appropriate. + +Note 3: DAOs and persons involved in DAOs are responsible for determining the relevant data required to be collected, the relevant tax administrations to report and pay taxes to, and the relevant format and times at which to provide relevant data to users and participants. + +Note 4: Guidance and commentary regarding each of the data fields, and further or different data fields, is intended to be developed through the feedback process. +Rationale +OECD member countries have started implementing CARF into their domestic legal frameworks, with most becoming effective from 2026. DAOs have been consumed with regulatory questions, but as these questions begin to be resolved through court cases, tax issues are returning to the fore. + +There continues to be a question for interpretation about whether a DAO is a reporting crypto-asset service provider. However, in preparation for CARF switching on in various jurisdictions, every DAO should understand whether CARF applies to them, in what jurisdictions, whether it aligns with what the DAO can present, and what alternatives may be better suited for a DAO and its community to ensure tax reporting and tax compliance. + +Eventually, block explorers such as Etherscan and platforms such as Dune Analytics may be able to present this information automatically from on-chain transactions. Given the fact that most tax-relevant data for DAOs is or could be on-chain, we hope that either a future version of this specification or a follow-up to it will address ways of standardizing on-chain transactions. +## Copyright +Copyright and related rights waived via [CCO](https://eips.ethereum.org/LICENSE). From 5281ef23195724cca13bb5574d4539b955564c40 Mon Sep 17 00:00:00 2001 From: Joshua Tan Date: Fri, 29 Nov 2024 15:11:07 -0800 Subject: [PATCH 04/10] Update and rename daoip-10 to daoip-10.md formatting fixes --- DAOIPs/daoip-10 | 109 ------------------------------------------- DAOIPs/daoip-10.md | 112 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 112 insertions(+), 109 deletions(-) delete mode 100644 DAOIPs/daoip-10 create mode 100644 DAOIPs/daoip-10.md diff --git a/DAOIPs/daoip-10 b/DAOIPs/daoip-10 deleted file mode 100644 index 90df9530..00000000 --- a/DAOIPs/daoip-10 +++ /dev/null @@ -1,109 +0,0 @@ ---- -daoip: 10 -title: Tax Reporting -description: -author: Joni Pirovich (), Joshua Tan (@thelastjosh), Dion Seymour () -discussions-to: https://github.com/metagov/daostar/discussions/272 -status: Draft -type: -category: -created: 2024-11-29 ---- -## Simple summary -A data standard for the presentation of DAO tax information to the public and protocol users. -## Motivation -The goal of this specification is to define a data standard that DAOs can adopt to collate on-chain information and make it publicly available in a form that assists tax administrations in assessing the tax risks associated with DAOs and that assists users to manage their tax obligations from DAO and protocol interactions. - -Tax administrations around the world care about assessing tax risk, whereas users need to calculate their taxes. Users therefore need more detailed data than tax administrations do. This standard thus makes a distinction between the data fields presented for tax administrations versus users. - -The specification has been modelled from the crypto “transfer types” used by the OECD in their Crypto-Asset Reporting Framework XML schema with some modifications for the idiosyncrasies around DAOs. For reference the transfer types specified in the OECD CARF XML schema are: staking, crypto loan, wrapping, collateral, airdrop, staking income, mining income, transfer from another reporting crypto asset service provider, sale of goods or services, other and unknown. - -Filling out the data in this specification is roughly equivalent to the content of a report produced by a crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. -## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. - -To comply with this specification you MUST publish a daoURI or entityURI following the EIP-4824 / DAOIP-2 DAO JSON LD Schema and add a field called “taxURI”. This URI MAY point anywhere, e.g. to a markdown file with information, an excel file or webpage. - -```json -{ - "@context": "https://www.daostar.org/schemas", - "type": "DAO", - "name": "", - "description": "", - "taxURI": "" -} -``` - -This standard requires DAOs to present tax information via their taxURI in a standardized form. The structure of data to be presented at the taxURI is intended to be roughly equivalent to the structure of a report produced by a reporting crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. - -You MAY point taxURI back to the daoURI address, which would indicate that all data published through daoURI constitutes DAO-approved communication in respect of this standard. - -Third parties MAY present tax information in respect of a DAO or DAOs using this standard but if the information is not presented by a DAO through a DAO’s taxURI or daoURI then the information does not constitute a DAO-approved communication. - -The tax data should include the fields as set out below. -### Presentation header -PresentingDAOIN: A field that identifies the daoURI which is the identification number of the DAO presenting the tax data about crypto transfers in and out of the DAO and the protocol/s it governs -Warning: A field that allows input of specific cautionary instructions about the use of data presented -Contact: A field allowing input of specific contact information relating to the DAO, or third party engaged or in receipt of grant funding by the DAO, to prepare and present the data -PresentationID: A field for a unique identifier created by the DAO that identifies the particular data presented -PresentationType: A field that specifies the type of data presented, i.e. whether new data (Type 1), or if corrected data (Type 2), or if deleted data (Type 3) -PresentationPeriod: A field that identifies the last day of the presentation period (e.g. a tax year or other period) to which the data presented relates in yyyy-MM-DD format -Timestamp: A field that identifies the date and time when the data was compiled in yyy-MM-DD’T’hh:mm:ss.nnn format. -### Data for tax administrations -CountryNumber: A field that specifies the number of countries from which on-chain activity with the DAO or any protocol/s it governs originates -CountryList: A field allowing input of all countries identified from which on-chain activity with the DAO or any protocol/s it governs originates using the 2-character alphabetic country code and country name list based on the ISO 3166-1 Alpha 2 standard -TypeofSupply: A field allowing input of the type of supply of crypto-tokens native to the DAO -DAOTotalSupply(crypto-tokens): A field that specifies the total supply of crypto-tokens native to the DAO, circulating and non-circulating at the end of the presentation period -DAOCirculatingSupply(crypto-tokens): A field that specifies the total circulating supply of crypto-tokens native to the DAO at the end of the presentation period -DAOStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) -DAOStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) -DAOStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to persons that have staked crypto-tokens in the format NN-TICKER (e.g. 10-ETH) -DAOStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units reserved for transfer as staking rewards but yet unpaid in the format NN-TICKER (e.g. 1-ETH) -DAOCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to borrowers in the format NN-TICKER (e.g. 100-DAI) -DAOCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from borrowers in the format NN-TICKER (e.g. 100-DAI) -DAOCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from borrowers in the format NN-TICKER (e.g. 10-DAI) -DAOWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) -DAOWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) -DAOCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral to a protocol in the format NN-TICKER (e.g. 300-WETH) -DAOCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the users in the format NN-TICKER (e.g. 300-WETH) -DAOAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as a free distribution to persons that may or may not have interacted with the DAO or its protocol/s, in the format NN-TICKER (e.g. 1,000-UNI) -DAOTransfertoFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury for the purpose of conversion to fiat currency -DAOTransferfromFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred into a DAO’s on-chain treasury in the format NN-TICKER (e.g. 100-ETH) -DAOReceipts(crypto-tokens): A field that specifies the number of crypto-tokens transferred into a DAO’s on-chain treasury or the protocols it governs as other receipts in the format NN-TICKER (e.g. 100-ETH) -DAOSpend(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocols it governs to third party suppliers in the format NN-TICKER (e.g. 100-ETH) -DAOGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient in the format NN-TICKER (e.g. 100-ETH) -DAORevenueIn(crypto-tokens): A field that specifies the number of crypto-token units received by a DAO’s on-chain treasury or the protocol/s it governs as revenue in the format NN-TICKER (e.g. 100-ETH) -DAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions in the format NN-TICKER (e.g. 100-ETH) -### Data for users -Each data field should be populated per on-chain address. - -UserStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) -UserStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) -UserStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to the user that has staked crypto-tokens in the format NN-TICKER (e.g. 1-ETH) -UserStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units accrued as staking rewards but yet unpaid to the user in the format NN-TICKER (e.g. 1-ETH) -UserCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to the borrower in the format NN-TICKER (e.g. 100-DAI) -UserCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from a borrower in the format NN-TICKER (e.g. 100-DAI) -UserCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from a borrower in the format NN-TICKER (e.g. 10-DAI) -UserWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred from a user to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) -UserWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol to the user in the format NN-TICKER (e.g. 100-ETH) -UserCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral by a user to a protocol in the format NN-TICKER (e.g. 300-WETH) -UserCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the user in the format NN-TICKER (e.g. 300-WETH) -UserAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred to a person as a free distribution, in the format NN-TICKER (e.g. 1,000-UNI) -UserGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient user -UserDAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions to a user - -Note 1: DAO’s that actively manage their Treasury should consider additional data fields particular to the treasury management activities. - -Note 2: It is assumed that DAOs have not adopted a tax position as to interest, dividend or other applicable withholding taxes. The absence of data fields in this standard for withholding tax or other taxes is not to be relied upon as advice or any indication that withholding or other taxes are not required to be collected and paid by the DAO or its participants. Each DAO and person involved in a DAO is responsible for seeking their own independent legal and tax advice, and may include additional such fields or other fields as necessary and appropriate. - -Note 3: DAOs and persons involved in DAOs are responsible for determining the relevant data required to be collected, the relevant tax administrations to report and pay taxes to, and the relevant format and times at which to provide relevant data to users and participants. - -Note 4: Guidance and commentary regarding each of the data fields, and further or different data fields, is intended to be developed through the feedback process. -Rationale -OECD member countries have started implementing CARF into their domestic legal frameworks, with most becoming effective from 2026. DAOs have been consumed with regulatory questions, but as these questions begin to be resolved through court cases, tax issues are returning to the fore. - -There continues to be a question for interpretation about whether a DAO is a reporting crypto-asset service provider. However, in preparation for CARF switching on in various jurisdictions, every DAO should understand whether CARF applies to them, in what jurisdictions, whether it aligns with what the DAO can present, and what alternatives may be better suited for a DAO and its community to ensure tax reporting and tax compliance. - -Eventually, block explorers such as Etherscan and platforms such as Dune Analytics may be able to present this information automatically from on-chain transactions. Given the fact that most tax-relevant data for DAOs is or could be on-chain, we hope that either a future version of this specification or a follow-up to it will address ways of standardizing on-chain transactions. -## Copyright -Copyright and related rights waived via [CCO](https://eips.ethereum.org/LICENSE). diff --git a/DAOIPs/daoip-10.md b/DAOIPs/daoip-10.md new file mode 100644 index 00000000..60a853bf --- /dev/null +++ b/DAOIPs/daoip-10.md @@ -0,0 +1,112 @@ +--- +daoip: 10 +title: Tax Reporting +description: +author: Joni Pirovich (), Joshua Tan (@thelastjosh), Dion Seymour () +discussions-to: https://github.com/metagov/daostar/discussions/272 +status: Draft +type: +category: +created: 2024-11-29 +--- +## Simple summary +A data standard for the presentation of DAO tax information to the public and protocol users. +## Motivation +The goal of this specification is to define a data standard that DAOs can adopt to collate on-chain information and make it publicly available in a form that assists tax administrations in assessing the tax risks associated with DAOs and that assists users to manage their tax obligations from DAO and protocol interactions. + +Tax administrations around the world care about assessing tax risk, whereas users need to calculate their taxes. Users therefore need more detailed data than tax administrations do. This standard thus makes a distinction between the data fields presented for tax administrations versus users. + +The specification has been modelled from the crypto “transfer types” used by the OECD in their Crypto-Asset Reporting Framework XML schema with some modifications for the idiosyncrasies around DAOs. For reference the transfer types specified in the OECD CARF XML schema are: staking, crypto loan, wrapping, collateral, airdrop, staking income, mining income, transfer from another reporting crypto asset service provider, sale of goods or services, other and unknown. + +Filling out the data in this specification is roughly equivalent to the content of a report produced by a crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. +## Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +To comply with this specification you MUST publish a daoURI or entityURI following the EIP-4824 / DAOIP-2 DAO JSON LD Schema and add a field called “taxURI”. This URI MAY point anywhere, e.g. to a markdown file with information, an excel file or webpage. + +```json +{ + "@context": "https://www.daostar.org/schemas", + "type": "DAO", + "name": "", + "description": "", + "taxURI": "" +} +``` + +This standard requires DAOs to present tax information via their taxURI in a standardized form. The structure of data to be presented at the taxURI is intended to be roughly equivalent to the structure of a report produced by a reporting crypto-asset service provider under the OECD’s CARF, or a dividend statement from a company, or a distribution statement from a trust that sets out the raw information necessary for tax compliance by an investor. + +You MAY point taxURI back to the daoURI address, which would indicate that all data published through daoURI constitutes DAO-approved communication in respect of this standard. + +Third parties MAY present tax information in respect of a DAO or DAOs using this standard but if the information is not presented by a DAO through a DAO’s taxURI or daoURI then the information does not constitute a DAO-approved communication. + +The tax data should include the fields as set out below in a flatfile. +### Presentation header +- PresentingDAOIN: A field that identifies the daoURI which is the identification number of the DAO presenting the tax data about crypto transfers in and out of the DAO and the protocol/s it governs +- Warning: A field that allows input of specific cautionary instructions about the use of data presented +- Contact: A field allowing input of specific contact information relating to the DAO, or third party engaged or in receipt of grant funding by the DAO, to prepare and present the data +- PresentationID: A field for a unique identifier created by the DAO that identifies the particular data presented +- PresentationType: A field that specifies the type of data presented, i.e. whether new data (Type 1), or if corrected data (Type 2), or if deleted data (Type 3) +- PresentationPeriod: A field that identifies the last day of the presentation period (e.g. a tax year or other period) to which the data presented relates in yyyy-MM-DD format +- Timestamp: A field that identifies the date and time when the data was compiled in yyy-MM-DD’T’hh:mm:ss.nnn format. + +### Data for tax administrations +- CountryNumber: A field that specifies the number of countries from which on-chain activity with the DAO or any protocol/s it governs originates +- CountryList: A field allowing input of all countries identified from which on-chain activity with the DAO or any protocol/s it governs originates using the 2-character alphabetic country code and country name list based on the ISO 3166-1 Alpha 2 standard +- TypeofSupply: A field allowing input of the type of supply of crypto-tokens native to the DAO +- DAOTotalSupply(crypto-tokens): A field that specifies the total supply of crypto-tokens native to the DAO, circulating and non-circulating at the end of the presentation period +- DAOCirculatingSupply(crypto-tokens): A field that specifies the total circulating supply of crypto-tokens native to the DAO at the end of the presentation period +- DAOStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) +- DAOStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the protocol/s governed by the DAO in the format NN-TICKER (e.g. 100-ETH) +- DAOStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to persons that have staked crypto-tokens in the format NN-TICKER (e.g. 10-ETH) +- DAOStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units reserved for transfer as staking rewards but yet unpaid in the format NN-TICKER (e.g. 1-ETH) +- DAOCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to borrowers in the format NN-TICKER (e.g. 100-DAI) +- DAOCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from borrowers in the format NN-TICKER (e.g. 100-DAI) +- DAOCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from borrowers in the format NN-TICKER (e.g. 10-DAI) +- DAOWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +- DAOWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +- DAOCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral to a protocol in the format NN-TICKER (e.g. 300-WETH) +- DAOCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the users in the format NN-TICKER (e.g. 300-WETH) +- DAOAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as a free distribution to persons that may or may not have interacted with the DAO or its protocol/s, in the format NN-TICKER (e.g. 1,000-UNI) +- DAOTransfertoFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury for the purpose of conversion to fiat currency +- DAOTransferfromFiat(crypto-tokens): A field that specifies the number of crypto-token units transferred into a DAO’s on-chain treasury in the format NN-TICKER (e.g. 100-ETH) +- DAOReceipts(crypto-tokens): A field that specifies the number of crypto-tokens transferred into a DAO’s on-chain treasury or the protocols it governs as other receipts in the format NN-TICKER (e.g. 100-ETH) +- DAOSpend(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocols it governs to third party suppliers in the format NN-TICKER (e.g. 100-ETH) +- DAOGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient in the format NN-TICKER (e.g. 100-ETH) +- DAORevenueIn(crypto-tokens): A field that specifies the number of crypto-token units received by a DAO’s on-chain treasury or the protocol/s it governs as revenue in the format NN-TICKER (e.g. 100-ETH) +- DAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions in the format NN-TICKER (e.g. 100-ETH) + +### Data for users +Each data field should be populated per on-chain address. + +- UserStakingTransfersIn(crypto-tokens): A field that specifies the number of crypto-token units transferred into the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) +- UserStakingTransfersOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of the staking protocol governed by the DAO in the format NN-TICKER (e.g. 1-ETH) +- UserStakingRewardsPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred as rewards to the user that has staked crypto-tokens in the format NN-TICKER (e.g. 1-ETH) +- UserStakingRewardsUnpaid(crypto-tokens): A field that specifies the number of crypto-token units accrued as staking rewards but yet unpaid to the user in the format NN-TICKER (e.g. 1-ETH) +- UserCryptoLoanOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from the protocol to the borrower in the format NN-TICKER (e.g. 100-DAI) +- UserCryptoLoanIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as repayments to the protocol from a borrower in the format NN-TICKER (e.g. 100-DAI) +- UserCryptoLoanInterest(crypto-tokens): A field that specifies the number of crypto-token units transferred as interest or interest-like payments to the protocol from a borrower in the format NN-TICKER (e.g. 10-DAI) +- UserWrappingIn(crypto-tokens): A field that specifies the number of crypto-token units transferred from a user to a wrapping protocol used in a DAO-governed protocol in the format NN-TICKER (e.g. 100-ETH) +- UserWrappingOut(crypto-tokens): A field that specifies the number of crypto-token units transferred from a wrapping protocol used in a DAO-governed protocol to the user in the format NN-TICKER (e.g. 100-ETH) +- UserCryptoLoanCollateralIn(crypto-tokens): A field that specifies the number of crypto-token units transferred as collateral by a user to a protocol in the format NN-TICKER (e.g. 300-WETH) +- UserCryptoLoanCollateralOut(crypto-tokens): A field that specifies the number of crypto-token units that were held by a protocol as collateral and that are transferred from the protocol to the user in the format NN-TICKER (e.g. 300-WETH) +- UserAirdropPaid(crypto-tokens): A field that specifies the number of crypto-token units transferred to a person as a free distribution, in the format NN-TICKER (e.g. 1,000-UNI) +- UserGrantPayment(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury to a third party grant recipient user +- UserDAORevenueOut(crypto-tokens): A field that specifies the number of crypto-token units transferred out of a DAO’s on-chain treasury or the protocol/s it governs as revenue distributions to a user + +Note 1: DAO’s that actively manage their Treasury should consider additional data fields particular to the treasury management activities. + +Note 2: It is assumed that DAOs have not adopted a tax position as to interest, dividend or other applicable withholding taxes. The absence of data fields in this standard for withholding tax or other taxes is not to be relied upon as advice or any indication that withholding or other taxes are not required to be collected and paid by the DAO or its participants. Each DAO and person involved in a DAO is responsible for seeking their own independent legal and tax advice, and may include additional such fields or other fields as necessary and appropriate. + +Note 3: DAOs and persons involved in DAOs are responsible for determining the relevant data required to be collected, the relevant tax administrations to report and pay taxes to, and the relevant format and times at which to provide relevant data to users and participants. + +Note 4: Guidance and commentary regarding each of the data fields, and further or different data fields, is intended to be developed through the feedback process. + +## Rationale +OECD member countries have started implementing CARF into their domestic legal frameworks, with most becoming effective from 2026. DAOs have been consumed with regulatory questions, but as these questions begin to be resolved through court cases, tax issues are returning to the fore. + +There continues to be a question for interpretation about whether a DAO is a reporting crypto-asset service provider. However, in preparation for CARF switching on in various jurisdictions, every DAO should understand whether CARF applies to them, in what jurisdictions, whether it aligns with what the DAO can present, and what alternatives may be better suited for a DAO and its community to ensure tax reporting and tax compliance. + +Eventually, block explorers such as Etherscan and platforms such as Dune Analytics may be able to present this information automatically from on-chain transactions. Given the fact that most tax-relevant data for DAOs is or could be on-chain, we hope that either a future version of this specification or a follow-up to it will address ways of standardizing on-chain transactions. +## Copyright +Copyright and related rights waived via [CCO](https://eips.ethereum.org/LICENSE). From 5432b51ad1098b2b3cb7c2e703892fc0a510d4aa Mon Sep 17 00:00:00 2001 From: Joshua Tan Date: Sun, 1 Dec 2024 09:04:54 -0800 Subject: [PATCH 05/10] Update daoip-2.md to reflect most recent EIP-4824 edits --- DAOIPs/daoip-2.md | 125 +++++++++------------------------------------- 1 file changed, 23 insertions(+), 102 deletions(-) diff --git a/DAOIPs/daoip-2.md b/DAOIPs/daoip-2.md index 36068b16..47986542 100644 --- a/DAOIPs/daoip-2.md +++ b/DAOIPs/daoip-2.md @@ -16,20 +16,20 @@ An API standard for decentralized autonomous organizations (DAOs), focused on re ## Motivation -DAOs, since being invoked in the Ethereum whitepaper, have been vaguely defined. This has led to a wide range of patterns but little standardization or interoperability between the frameworks and tools that have emerged. Standardization and interoperability are necessary to support a variety of use-cases. In particular, a standard daoURI, similar to tokenURI in [ERC-721](./eip-721), will enhance DAO discoverability, legibility, proposal simulation, and interoperability between tools. More consistent data across the ecosystem is also a prerequisite for future DAO standards. +DAOs, since being invoked in the Ethereum whitepaper, have been vaguely defined. This has led to a wide range of patterns but little standardization or interoperability between the frameworks and tools that have emerged. Standardization and interoperability are necessary to support a variety of use-cases. In particular, a standard daoURI, similar to tokenURI in [ERC-721](https://eips.ethereum.org/EIPS/eip-721), will enhance DAO discoverability, legibility, proposal simulation, and interoperability between tools. More consistent data across the ecosystem is also a prerequisite for future DAO standards. ## Specification The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. -Every contract implementing this EIP MUST implement the [ERC-4824](./eip-4824) interface below: +Every contract implementing this EIP MUST implement the `IERC4824` interface below: ```solidity pragma solidity ^0.8.1; /// @title ERC-4824 DAOs /// @dev See -interface IERC-4824 { +interface IERC4824 { event DAOURIUpdate(address daoAddress, string daoURI); /// @notice A distinct Uniform Resource Identifier (URI) pointing to a JSON object following the "ERC-4824 DAO JSON-LD Schema". This JSON file splits into four subsidiary URIs: membersURI, proposalsURI, activityLogURI, and governanceURI. The membersURI SHOULD point to a JSON file that conforms to the "ERC-4824 Members JSON-LD Schema". The proposalsURI SHOULD point to a JSON file that conforms to the "ERC-4824 Proposals JSON-LD Schema". The activityLogURI SHOULD point to a JSON file that conforms to the "ERC-4824 Activity Log JSON-LD Schema". The governanceURI SHOULD point to a flatfile, normatively a .md file. Each of the JSON files named above MAY be statically-hosted or dynamically-generated. The content of subsidiary JSON files MAY be directly embedded as a JSON object directly within the top-level DAO JSON, in which case the relevant field MUST be renamed to remove the "URI" suffix. For example, "membersURI" would be renamed to "members", "proposalsURI" would be renamed to "proposals", and so on. @@ -53,99 +53,20 @@ The DAO JSON-LD Schema mentioned above: } ``` -A DAO MAY inherit the interface above or it MAY create an external registration contract that is compliant with this EIP. If a DAO creates an external registration contract, the registration contract MUST store the DAO’s primary address. +A DAO MAY inherit the `IERC4824` interface above or it MAY create an external registration contract that is compliant with this EIP. Whether the DAO inherits the above interface or it uses an external registration contract, the DAO SHOULD define a method for and implement some access control logic to enable efficient updating for daoURI. If a DAO creates an external registration contract, the registration contract MUST store the DAO’s primary address, typically the address of the primary governance contract. See the reference implementation of external registration contract in the attached assets folder to this EIP. -```solidity -pragma solidity ^0.8.1; - -/// @title ERC-4824 Common Interfaces for DAOs -/// @dev See -/// @title ERC-4824: DAO Registration -contract ERC-4824Registration is IERC-4824, AccessControl { - bytes32 public constant MANAGER_ROLE = keccak256("MANAGER_ROLE"); - - string private _daoURI; - - address daoAddress; - - constructor() { - daoAddress = address(0xdead); - } - - /// @notice Set the initial DAO URI and offer manager role to an address - /// @dev Throws if initialized already - /// @param _daoAddress The primary address for a DAO - /// @param _manager The address of the URI manager - /// @param daoURI_ The URI which will resolve to the governance docs - function initialize( - address _daoAddress, - address _manager, - string memory daoURI_, - address _ERC-4824Index - ) external { - initialize(_daoAddress, daoURI_, _ERC-4824Index); - _grantRole(MANAGER_ROLE, _manager); - } - - /// @notice Set the initial DAO URI - /// @dev Throws if initialized already - /// @param _daoAddress The primary address for a DAO - /// @param daoURI_ The URI which will resolve to the governance docs - function initialize( - address _daoAddress, - string memory daoURI_, - address _ERC-4824Index - ) public { - if (daoAddress != address(0)) revert AlreadyInitialized(); - daoAddress = _daoAddress; - _setURI(daoURI_); - - _grantRole(DEFAULT_ADMIN_ROLE, _daoAddress); - _grantRole(MANAGER_ROLE, _daoAddress); - - ERC-4824Index(_ERC-4824Index).logRegistration(address(this)); - } - - /// @notice Update the URI for a DAO - /// @dev Throws if not called by dao or manager - /// @param daoURI_ The URI which will resolve to the governance docs - function setURI(string memory daoURI_) public onlyRole(MANAGER_ROLE) { - _setURI(daoURI_); - } - - function _setURI(string memory daoURI_) internal { - _daoURI = daoURI_; - emit DAOURIUpdate(daoAddress, daoURI_); - } - - function daoURI() external view returns (string memory daoURI_) { - return _daoURI; - } - - function supportsInterface( - bytes4 interfaceId - ) public view virtual override returns (bool) { - return - interfaceId == type(IERC-4824).interfaceId || - super.supportsInterface(interfaceId); - } -} -``` - -Whether the DAO inherits the above interface or it uses an external registration contract, it SHOULD define a method for and implement some access control logic to enable efficient updating for daoURI. - -If a given field has no value (for example, `description`), it SHOULD be removed rather than left with an empty or `null` value. +When reporting information in the DAO JSON-LD Schema, if a given field has no value (for example, `description`), it SHOULD be removed rather than left with an empty or `null` value. ### Indexing -If a DAO inherits the ERC-4824 interface from a 4824-compliant DAO factory, then the DAO factory SHOULD incorporate a call to an indexer contract as part of the DAO's initialization to enable efficient network indexing. If the DAO is [ERC-165](./eip-165)-compliant, the factory can do this without additional permissions. If the DAO is _not_ compliant with ERC-165, the factory SHOULD first obtain access control rights to the indexer contract and then call logRegistration directly with the address of the new DAO and the daoURI of the new DAO. Note that any user, including the DAO itself, MAY call logRegistration and submit a registration for a DAO which inherits the ERC-4824 interface and which is also ERC-165-compliant. +If a DAO inherits the `IERC4824` interface from a 4824-compliant DAO factory, then the DAO factory SHOULD incorporate a call to an indexer contract as part of the DAO's initialization to enable efficient network indexing. If the DAO is [ERC-165](./eip-165)-compliant, the factory can do this without additional permissions. If the DAO is _not_ compliant with ERC-165, the factory SHOULD first obtain access control rights to the indexer contract and then call `logRegistration` directly with the address of the new DAO and the daoURI of the new DAO. Note that any user, including the DAO itself, MAY call `logRegistration` and submit a registration for a DAO which inherits the `IERC4824` interface and which is also ERC-165-compliant. ```solidity pragma solidity ^0.8.1; -error ERC-4824InterfaceNotSupported(); +error ERC4824InterfaceNotSupported(); -contract ERC-4824Index is AccessControl { +contract ERC4824Index is AccessControl { using ERC165Checker for address; bytes32 public constant REGISTRATION_ROLE = keccak256("REGISTRATION_ROLE"); @@ -164,8 +85,8 @@ contract ERC-4824Index is AccessControl { } function logRegistration(address daoAddress) external { - if (!daoAddress.supportsInterface(type(IERC-4824).interfaceId)) - revert ERC-4824InterfaceNotSupported(); + if (!daoAddress.supportsInterface(type(IERC4824).interfaceId)) + revert ERC4824InterfaceNotSupported(); emit DAOURIRegistered(daoAddress); } } @@ -178,7 +99,7 @@ daoURIs may be published directly in the DAO's contract or through a call to a c ### Members -Members JSON-LD Schema. Every contract implementing this EIP SHOULD implement a membersURI pointing to a JSON object satisfying this schema. +Members JSON-LD Schema. Every contract implementing this EIP SHOULD implement a membersURI pointing to a JSON object satisfying this schema. Below, DID refers to [Decentralized Identifiers](https://www.w3.org/TR/2022/REC-did-core-20220719/). ```json { @@ -195,7 +116,7 @@ Members JSON-LD Schema. Every contract implementing this EIP SHOULD implement a } ``` -For example, for an address on Ethereum Mainnet, the CAIP-10 address would be of the form `eip155:1:0x1234abcd`, while the DID address would be of the form `did:ethr:0x1234abcd`. +For example, for an address on Ethereum Mainnet, the [CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/ad0cfebc45a4b8368628340bf22aefb2a5edcab7/CAIPs/caip-10.md) address would be of the form `eip155:1:0x1234abcd`, while the DID address would be of the form `did:ethr:0x1234abcd`. ### Proposals @@ -229,7 +150,7 @@ In particular, any on-chain proposal MUST be associated to an id of the form CAI } ``` -When deferenced, `contentURI` should return the content (i.e. the text) of the proposal. Similarly, `discussionURI` should return a discussion link, whether a forum post, Discord channel, or Twitter thread. +When deferenced, contentURI should return the content (i.e. the text) of the proposal. Similarly, discussionURI should return a discussion link, whether a forum post, Discord channel, or Twitter thread. ### Activity Log @@ -258,9 +179,9 @@ Activity Log JSON-LD Schema. Every contract implementing this EIP SHOULD impleme Contracts JSON-LD Schema. Every contract implementing this EIP SHOULD implement a contractsURI pointing to a JSON object satisfying this schema. -`contractsURI` is especially important for DAOs with distinct or decentralized governance occurring across multiple different contracts, possibly across several chains. Multiple addresses may report the same daoURI. +contractsURI is especially important for DAOs with distinct or decentralized governance occurring across multiple different contracts, possibly across several chains. Multiple addresses may report the same daoURI. -To prevent spam or spoofing, all DAOs adopting this specification SHOULD publish through `contractsURI` the address of every contract associated to the DAO, including but not limited to those that inherit the ERC-4824 interface or those that interact with an ERC-4824 registration factory contract. Note that this includes the contract address(es) of any actual registration contracts deployed through a registration factory. +To prevent spam or spoofing, all DAOs adopting this specification SHOULD publish through contractsURI the address of every contract associated to the DAO, including but not limited to those that inherit the `IERC4824` interface or those that interact with a registration factory contract. Note that this includes the contract address(es) of any actual registration contracts deployed through a registration factory. ```json { @@ -290,7 +211,7 @@ The content of subsidiary JSON files MAY be directly embedded as a JSON object d Fields which are not appended with URI MAY be appended with a URI, for example `name` and `description` may be renamed to `nameURI` and `descriptionURI`, in which case the dereferenced URI MUST return a JSON-LD object containing the `"@context": "https://www.daostar.org/schemas"` field and the original key-value pair. -For example, `descriptionURI` should return: +For example, descriptionURI should return: ```json { "@context": "https://www.daostar.org/schemas", @@ -302,7 +223,7 @@ For example, `descriptionURI` should return: Entities which are not DAOs or which do not wish to identify as DAOs MAY still publish daoURIs. If so, they SHOULD use a different value for the `type` field than "DAO", for example "Organization", "Foundation", "Person", or, most broadly, "Entity". -Entities which are not DAOs or which do not wish to identify as DAOs MAY also publish metadata information through an off-chain `orgURI` or `entityURI`, which are aliases of `daoURI`. If these entities are reporting their URI through an on-chain smart contract or registration, however, they MUST retain the ERC-4824 `daoURI` interface in order to enable network indexing. +Entities which are not DAOs or which do not wish to identify as DAOs MAY also publish metadata information through an off-chain orgURI or entityURI, which are aliases of daoURI. If these entities are reporting their URI through an on-chain smart contract or registration, however, they MUST retain `IERC4824`'s daoURI in order to enable network indexing. The Entity JSON-LD Schema: @@ -344,9 +265,9 @@ We encourage extensions of the Membership JSON-LD Schema, e.g. for DAOs that wis ### proposalsURI -Proposals have become a standard way for the members of a DAO to trigger on-chain actions, e.g. sending out tokens as part of grant or executing arbitrary code in an external contract. In practice, however, many DAOs are governed by off-chain decision-making systems on platforms such as Discourse, Discord, or Snapshot, where off-chain proposals may function as signaling mechanisms for an administrator or as a prerequisite for a later on-chain vote. (To be clear, on-chain votes may also serve as non-binding signaling mechanisms or as “binding” signals leading to some sort of off-chain execution.) The schema we propose is intended to support both on-chain and off-chain proposals, though DAOs themselves may choose to report only on-chain, only off-chain, or some custom mix of proposal types. +Proposals have become a standard way for the members of a DAO to trigger on-chain actions, e.g. sending out tokens as part of a grant or executing arbitrary code in an external contract. In practice, however, many DAOs are governed by off-chain decision-making systems on platforms such as Discourse, Discord, or Snapshot, where off-chain proposals may function as signaling mechanisms for an administrator or as a prerequisite for a later on-chain vote. (To be clear, on-chain votes may also serve as non-binding signaling mechanisms or as “binding” signals leading to some sort of off-chain execution.) The schema we propose is intended to support both on-chain and off-chain proposals, though DAOs themselves may choose to report only on-chain, only off-chain, or some custom mix of proposal types. -**Proposal ID**. Every unique on-chain proposal MUST be associated to a proposal ID of the form CAIP10_ADDRESS + “?proposalId=” + PROPOSAL_COUNTER, where PROPOSAL_COUNTER is an arbitrary string which is unique per CAIP10_ADDRESS. Note that PROPOSAL_COUNTER may not be the same as the on-chain representation of the proposal; however, each PROPOSAL_COUNTER should be unique per CAIP10_ADDRESS, such that the proposal ID is a globally unique identifier. We endorse the CAIP-10 standard to support multi-chain / layer 2 proposals and the “?proposalId=” query syntax to suggest off-chain usage. +**Proposal ID**. In the specification, we state that every unique on-chain proposal must be associated to a proposal ID of the form CAIP10_ADDRESS + “?proposalId=” + PROPOSAL_COUNTER, where PROPOSAL_COUNTER is an arbitrary string which is unique per CAIP10_ADDRESS. Note that PROPOSAL_COUNTER may not be the same as the on-chain representation of the proposal; however, each PROPOSAL_COUNTER should be unique per CAIP10_ADDRESS, such that the proposal ID is a globally unique identifier. We endorse the CAIP-10 standard to support multi-chain / layer 2 proposals and the “?proposalId=” query syntax to suggest off-chain usage. **ContentURI**. In many cases, a proposal will have some (off-chain) content such as a forum post or a description on a voting platform which predates or accompanies the actual proposal. @@ -379,9 +300,9 @@ _Alternative names considered: description, readme, constitution_ ### contractsURI -Over the course of community conversations, multiple parties raised the need to report on, audit, and index the different contracts belonging to a given DAO. Some of these contracts are deployed as part of the modular design of a single DAO framework, e.g. the core, voting, and timelock contracts within Open Zeppelin / Compound Governor. In other cases, a DAO might deploy multiple multsigs as treasuries and/or multiple subDAOs that are effectively controlled by the DAO. `contractsURI` offers a generic way of declaring these many instruments so that they can be efficiently aggregated by an indexer. +Over the course of community conversations, multiple parties raised the need to report on, audit, and index the different contracts belonging to a given DAO. Some of these contracts are deployed as part of the modular design of a single DAO framework, e.g. the core, voting, and timelock contracts within Open Zeppelin / Compound Governor. In other cases, a DAO might deploy multiple multsigs as treasuries and/or multiple subDAOs that are effectively controlled by the DAO. contractsURI offers a generic way of declaring these many instruments so that they can be efficiently aggregated by an indexer. -`contractsURI` is also important for spam prevention or spoofing. Some DAOs may spread governance power and control across multiple different governance contracts, possibly across several chains. To capture this reality, multiple addresses may wish to report the same daoURI, or different daoURIs with the same name. However, unauthorized addresses may try to report the same daoURI or name. Additional contract information can prevent attacks of this sort by allowing indexers to weed out spam information. +contractsURI is also important for spam prevention or spoofing. Some DAOs may spread governance power and control across multiple different governance contracts, possibly across several chains. To capture this reality, multiple addresses may wish to report the same daoURI, or different daoURIs with the same name. However, unauthorized addresses may try to report the same daoURI or name. Additional contract information can prevent attacks of this sort by allowing indexers to weed out spam information. _Alternative names considered: contractsRegistry, contractsList_ @@ -393,9 +314,9 @@ Further, given the emergence of patterns such as subDAOs and DAOs of DAOs in lar ### **Community Consensus** -The initial draft standard was developed as part of the DAOstar One roundtable series, which included representatives from all major EVM-based DAO frameworks (Aragon, Compound, DAOstack, Gnosis, Moloch, OpenZeppelin, and Tribute), a wide selection of DAO tooling developers, as well as several major DAOs. Thank you to all the participants of the roundtable. We would especially like to thank Auryn Macmillan, Fabien of Snapshot, Selim Imoberdorf, Lucia Korpas, and Mehdi Salehi for their contributions. +The initial draft standard was developed as part of the DAOstar roundtable series, which included representatives from all major EVM-based DAO frameworks (Aragon, Compound, DAOstack, Gnosis, Moloch, OpenZeppelin, and Tribute), a wide selection of DAO tooling developers, as well as several major DAOs. Thank you to all the participants of the roundtable. We would especially like to thank Fabien of Snapshot, Jake Hartnell, Auryn Macmillan, Selim Imoberdorf, Lucia Korpas, and Mehdi Salehi for their contributions. -In-person events will be held at Schelling Point 2022 and at ETHDenver 2022, where we hope to receive more comments from the community. We also plan to schedule a series of community calls through early 2022. +In-person events for community comment were held at Schelling Point 2022, ETHDenver 2022, ETHDenver 2023, DAO Harvard 2023, DAO Stanford 2023 (also known as the Science of Blockchains Conference DAO Workshop). The team also hosted over 50 biweekly community calls as part of the DAOstar project. ## Backwards Compatibility From d9b4cef270d0acfda17e9d6cc38b157f7dfe1ef1 Mon Sep 17 00:00:00 2001 From: Joshua Tan Date: Sun, 1 Dec 2024 09:06:19 -0800 Subject: [PATCH 06/10] Create ERC4824Registration.sol --- .../daoip-2/contracts/ERC4824Registration.sol | 72 +++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 DAOIPs/assets/daoip-2/contracts/ERC4824Registration.sol diff --git a/DAOIPs/assets/daoip-2/contracts/ERC4824Registration.sol b/DAOIPs/assets/daoip-2/contracts/ERC4824Registration.sol new file mode 100644 index 00000000..0b5003fe --- /dev/null +++ b/DAOIPs/assets/daoip-2/contracts/ERC4824Registration.sol @@ -0,0 +1,72 @@ +pragma solidity ^0.8.1; + +/// @title ERC-4824: DAO Registration +contract ERC-4824Registration is IERC-4824, AccessControl { + bytes32 public constant MANAGER_ROLE = keccak256("MANAGER_ROLE"); + + string private _daoURI; + + address daoAddress; + + constructor() { + daoAddress = address(0xdead); + } + + /// @notice Set the initial DAO URI and offer manager role to an address + /// @dev Throws if initialized already + /// @param _daoAddress The primary address for a DAO + /// @param _manager The address of the URI manager + /// @param daoURI_ The URI which will resolve to the governance docs + function initialize( + address _daoAddress, + address _manager, + string memory daoURI_, + address _ERC-4824Index + ) external { + initialize(_daoAddress, daoURI_, _ERC-4824Index); + _grantRole(MANAGER_ROLE, _manager); + } + + /// @notice Set the initial DAO URI + /// @dev Throws if initialized already + /// @param _daoAddress The primary address for a DAO + /// @param daoURI_ The URI which will resolve to the governance docs + function initialize( + address _daoAddress, + string memory daoURI_, + address _ERC-4824Index + ) public { + if (daoAddress != address(0)) revert AlreadyInitialized(); + daoAddress = _daoAddress; + _setURI(daoURI_); + + _grantRole(DEFAULT_ADMIN_ROLE, _daoAddress); + _grantRole(MANAGER_ROLE, _daoAddress); + + ERC-4824Index(_ERC-4824Index).logRegistration(address(this)); + } + + /// @notice Update the URI for a DAO + /// @dev Throws if not called by dao or manager + /// @param daoURI_ The URI which will resolve to the governance docs + function setURI(string memory daoURI_) public onlyRole(MANAGER_ROLE) { + _setURI(daoURI_); + } + + function _setURI(string memory daoURI_) internal { + _daoURI = daoURI_; + emit DAOURIUpdate(daoAddress, daoURI_); + } + + function daoURI() external view returns (string memory daoURI_) { + return _daoURI; + } + + function supportsInterface( + bytes4 interfaceId + ) public view virtual override returns (bool) { + return + interfaceId == type(IERC-4824).interfaceId || + super.supportsInterface(interfaceId); + } +} From 7ca60c70fdd8162f5171cdd67df10be1613cea9e Mon Sep 17 00:00:00 2001 From: Joshua Tan Date: Sun, 1 Dec 2024 09:10:42 -0800 Subject: [PATCH 07/10] clean up link references --- DAOIPs/daoip-2.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/DAOIPs/daoip-2.md b/DAOIPs/daoip-2.md index 47986542..a151c9aa 100644 --- a/DAOIPs/daoip-2.md +++ b/DAOIPs/daoip-2.md @@ -22,7 +22,7 @@ DAOs, since being invoked in the Ethereum whitepaper, have been vaguely defined. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. -Every contract implementing this EIP MUST implement the `IERC4824` interface below: +Every contract implementing this DAOIP MUST implement the `IERC4824` interface below: ```solidity pragma solidity ^0.8.1; @@ -53,13 +53,13 @@ The DAO JSON-LD Schema mentioned above: } ``` -A DAO MAY inherit the `IERC4824` interface above or it MAY create an external registration contract that is compliant with this EIP. Whether the DAO inherits the above interface or it uses an external registration contract, the DAO SHOULD define a method for and implement some access control logic to enable efficient updating for daoURI. If a DAO creates an external registration contract, the registration contract MUST store the DAO’s primary address, typically the address of the primary governance contract. See the reference implementation of external registration contract in the attached assets folder to this EIP. +A DAO MAY inherit the `IERC4824` interface above or it MAY create an external registration contract that is compliant with this DAOIP. Whether the DAO inherits the above interface or it uses an external registration contract, the DAO SHOULD define a method for and implement some access control logic to enable efficient updating for daoURI. If a DAO creates an external registration contract, the registration contract MUST store the DAO’s primary address, typically the address of the primary governance contract. See the reference implementation of external registration contract in the attached assets folder to this DAOIP. When reporting information in the DAO JSON-LD Schema, if a given field has no value (for example, `description`), it SHOULD be removed rather than left with an empty or `null` value. ### Indexing -If a DAO inherits the `IERC4824` interface from a 4824-compliant DAO factory, then the DAO factory SHOULD incorporate a call to an indexer contract as part of the DAO's initialization to enable efficient network indexing. If the DAO is [ERC-165](./eip-165)-compliant, the factory can do this without additional permissions. If the DAO is _not_ compliant with ERC-165, the factory SHOULD first obtain access control rights to the indexer contract and then call `logRegistration` directly with the address of the new DAO and the daoURI of the new DAO. Note that any user, including the DAO itself, MAY call `logRegistration` and submit a registration for a DAO which inherits the `IERC4824` interface and which is also ERC-165-compliant. +If a DAO inherits the `IERC4824` interface from a 4824-compliant DAO factory, then the DAO factory SHOULD incorporate a call to an indexer contract as part of the DAO's initialization to enable efficient network indexing. If the DAO is [ERC-165](https://eips.ethereum.org/EIPS/eip-165)-compliant, the factory can do this without additional permissions. If the DAO is _not_ compliant with ERC-165, the factory SHOULD first obtain access control rights to the indexer contract and then call `logRegistration` directly with the address of the new DAO and the daoURI of the new DAO. Note that any user, including the DAO itself, MAY call `logRegistration` and submit a registration for a DAO which inherits the `IERC4824` interface and which is also ERC-165-compliant. ```solidity pragma solidity ^0.8.1; @@ -92,14 +92,14 @@ contract ERC4824Index is AccessControl { } ``` -If a DAO uses an external registration contract, the DAO SHOULD use a common registration factory contract linked to a common indexer to enable efficient network indexing. See the reference implementation of the factory contract in the attached assets folder to this EIP. +If a DAO uses an external registration contract, the DAO SHOULD use a common registration factory contract linked to a common indexer to enable efficient network indexing. See the reference implementation of the factory contract in the attached assets folder to this DAOIP. #### Indexing priority daoURIs may be published directly in the DAO's contract or through a call to a common registration factory contract. In cases where both occur, the daoURI (and all sub-URIs) published through a call to a registration factory contract SHOULD take precedence. If there are multiple registrations, the most recent registration SHOULD take precedence. ### Members -Members JSON-LD Schema. Every contract implementing this EIP SHOULD implement a membersURI pointing to a JSON object satisfying this schema. Below, DID refers to [Decentralized Identifiers](https://www.w3.org/TR/2022/REC-did-core-20220719/). +Members JSON-LD Schema. Every contract implementing this DAOIP SHOULD implement a membersURI pointing to a JSON object satisfying this schema. Below, DID refers to [Decentralized Identifiers](https://www.w3.org/TR/2022/REC-did-core-20220719/). ```json { @@ -120,7 +120,7 @@ For example, for an address on Ethereum Mainnet, the [CAIP-10](https://github.co ### Proposals -Proposals JSON-LD Schema. Every contract implementing this EIP SHOULD implement a proposalsURI pointing to a JSON object satisfying this schema. +Proposals JSON-LD Schema. Every contract implementing this DAOIP SHOULD implement a proposalsURI pointing to a JSON object satisfying this schema. In particular, any on-chain proposal MUST be associated to an id of the form CAIP10_ADDRESS + “?proposalId=” + PROPOSAL_COUNTER, where CAIP10_ADDRESS is an address following the CAIP-10 standard and PROPOSAL_COUNTER is an arbitrary identifier such as a uint256 counter or a hash that is locally unique per CAIP-10 address. Off-chain proposals MAY use a similar id format where CAIP10_ADDRESS is replaced with an appropriate URI or URL. @@ -154,7 +154,7 @@ When deferenced, contentURI should return the content (i.e. the text) of the pro ### Activity Log -Activity Log JSON-LD Schema. Every contract implementing this EIP SHOULD implement a activityLogURI pointing to a JSON object satisfying this schema. +Activity Log JSON-LD Schema. Every contract implementing this DAOIP SHOULD implement a activityLogURI pointing to a JSON object satisfying this schema. ```json { @@ -177,7 +177,7 @@ Activity Log JSON-LD Schema. Every contract implementing this EIP SHOULD impleme ### Contracts -Contracts JSON-LD Schema. Every contract implementing this EIP SHOULD implement a contractsURI pointing to a JSON object satisfying this schema. +Contracts JSON-LD Schema. Every contract implementing this DAOIP SHOULD implement a contractsURI pointing to a JSON object satisfying this schema. contractsURI is especially important for DAOs with distinct or decentralized governance occurring across multiple different contracts, possibly across several chains. Multiple addresses may report the same daoURI. @@ -330,4 +330,4 @@ Indexers that rely on the data returned by the URI should take caution if DAOs r ## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From de6ffcab0a48059218ed2890ff0c5a297962c96a Mon Sep 17 00:00:00 2001 From: eth-limo Date: Mon, 2 Dec 2024 13:11:50 -0500 Subject: [PATCH 08/10] Rework document sections with initial feedback --- DAOIPs/daoip-8.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/DAOIPs/daoip-8.md b/DAOIPs/daoip-8.md index 86e55743..4b750081 100644 --- a/DAOIPs/daoip-8.md +++ b/DAOIPs/daoip-8.md @@ -12,7 +12,7 @@ created: 2024-10-22 # Simple Summary -A set of applicable controls for increasing DAO security +A set of applicable controls for improving DAO security # Motivation @@ -38,13 +38,13 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL | Control | Description | | :--- | :--- | -| Data transparency | 1. `[MANDATORY]` The DAO should publish an up to date __governance document__, outlining the steps and stakeholders involved in governance.

Data transparency is critical to an organization’s security. The governance document should clearly define the person(s) responsible for its upkeep, along with a channel to reach out to them if information is incorrect or outdated.

Along with key details on governance design, and operational rules, the governance document __SHOULD__ include information on all *__privileged roles__* (details on who can do what). For example, can anyone create a new proposal, can proposals be vetoed, are proposal execution autonomous, etc?

2. `[RECOMMENDED]` The DAO should maintain a repository of all DAO-related artifacts.

DAO-related artifacts include (but are not limited to) grant programs; list of all smart contracts; list of functional committees, councils and multisigs; trusted service providers; and financial reporting. We recommend using the EIP-4824 standard to facilitate this, as it allows decentralized control of data by the DAO.| -| Ownership of assets | `[MANDATORY]` The DAO should release a public list of all assets it owns and controls. The list could include crypto tokens, ENS names and other naming services, dApps, frontends, physical assets, etc. | -| Self defense, incident response, and vulnerability management | 1. `[MANDATORY]` The DAO must publish a self-defense and emergency management plan.

It is important to have an incident response plan, including details of what constitutes an emergency/incident. Note that the intention here is to prompt the creation of a plan - no critical details of the incident response plan need to be public. A template is available [here](https://www.michigan.gov/-/media/Project/Websites/msp/cjic/pdfs6/Example_Incident_Response_Policy.pdf?rev=4bf335b6d1344226a92a0947bc8688ec) (not Web3/DAO specific).

2. `[RECOMMENDED]` The DAO should publish a vulnerability management plan. Sample [template](https://frsecure.com/vulnerability-management-policy-template/) (not Web3/DAO specific). | +| Data transparency | 1. `[MANDATORY]` The DAO should publish an up to date __governance document__, outlining the steps and stakeholders involved in governance.

Data transparency is critical to an organization’s security. The governance document should clearly define the person(s) responsible for its upkeep, along with a channel to reach out to them if information is incorrect or outdated. The governance document should include but not limit to the following:

  • Mandatroy steps in the governance process (temp checks, RFCs, timelines, vote thresholds), type of election (ranked choice, single choice, first past the post, etc).
  • Rules of elections, and elected position descriptions and contact information.
Along with key details on governance design, and operational rules, the governance document __SHOULD__ include information on all *__privileged roles__* (details on who can do what). Privileged roles should include information pertaining to the powers delegated to said role and identify the addresses associated with each role. For example, can anyone create a new proposal, can proposals be vetoed, are proposal executions autonomous, etc?

In addition to the governance process, all official service providers and their respective responsibilities should be detailed along with contact information for each team.

2. `[RECOMMENDED]` The DAO should maintain a repository of all DAO-related artifacts.

DAO-related artifacts include (but are not limited to) grant programs; list of all smart contracts; list of functional committees, councils and multisigs; trusted service providers; and financial reporting. We recommend using the EIP-4824 standard to facilitate this, as it allows decentralized control of data by the DAO.| +| Ownership of assets | `[MANDATORY]` The DAO should make public a list of all assets it owns and controls. The list could include crypto tokens, ENS names and other naming services, dApps, frontends, physical assets, etc. | +| Self defense, incident response, auditing, and vulnerability management |It is imperative to have a course of action or otherwise defensive capability for responding to security incidents and events which pose a risk to the core operations of a DAO or it's technical assets. This includes things such as CVE remediation, DNS hijacking/infrastructure compromise, KPI definitions for security event monitoring and response. The intention here is to prompt the creation of a plan - no critical details of the incident response plan need to be public. A template for inspiration is available [here](https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf) (not Web3/DAO specific). While there are many overlapping security considerations with Web2 practices, it is important to take DAO specific concerns into account. Additionally, it is necessary to also consider proactive controls for things such as MFA requirements, IAM best practices and regular reviews/audits of permissions for developers or technical contributors.

1. `[MANDATORY]` The DAO must publish a self-defense and emergency management plan.

2. `[RECOMMENDED]` The DAO should publish a vulnerability management plan. Sample [template](https://frsecure.com/vulnerability-management-policy-template/) (not Web3/DAO specific). | | Vendor/service provider management Policy | 1. `[MANDATORY]` The DAO should publish a list of vendors/service providers it relies upon.

2. `[RECOMMENDED]` The DAO should publish a vendor management policy. [Inspiration here](https://frameworks.securityalliance.org/external-security-reviews/vendor-selection.html).

*Vendors include all 3rd party service providers that provide a good or service to the DAO, including software services that are not paid by the DAO, but used for operations, governance or other avenues*.| -| Proposal safety | `[RECOMMENDED]` It is recommended to:

  • Use a timelock before upgrading protocols that hold funds.
  • Simulate proposals before executing them.
  • Perform automated checks on proposals for common attacks.
| -| Physical security policy | `[MANDATORY]` The DAO should publish a physical security policy, and provide training to combat wrench attacks.

While enforcing this is difficult, the DAO is recommended to focus on educational content that describes measures to be taken by key delegates, multisig signers, members of the foundation, and other important stakeholders to ensure security while traveling to conferences and other events. Inspiration taken from [here](https://github.com/OffcierCia/Crypto-OpSec-SelfGuard-RoadMap). | -| Community management | `[MANDATORY]` The DAO should follow secure community management processes, to secure community accounts on Twitter, Discord, Telegram, and other applications. Template [here](https://frameworks.securityalliance.org/community-management/index.html). | +| Proposal safety | `[RECOMMENDED]` It is recommended to:

  • Use a timelock before upgrading protocols that hold funds.
  • Simulate proposals before executing them.
  • Perform automated checks on proposals for common attacks.
  • Quorum threshold definitions for core governance changes.
  • Auditing and review of governance mutating transactions by qualified contributors to ensure expected outcomes match voter preferences.
| +| Physical security training | `[MANDATORY]` The DAO should publish a physical security recommendation and provide training to combat wrench attacks.

The DAO is recommended to focus on educational content that describes measures to be taken by key delegates, multisig signers, members of the foundation, and other important stakeholders to ensure security while traveling to conferences and other events. Inspiration taken from [here](https://github.com/OffcierCia/Crypto-OpSec-SelfGuard-RoadMap). Key recommendations could include the following:

  • Hardware wallet management.
  • Laptop security.
  • Usage of public WiFi.
  • Social engineering defense.
  • AirBnB/hotel security.
| +| Community management | `[MANDATORY]` The DAO should follow secure community management processes, to secure community accounts on Twitter, Discord, Telegram, and other applications. This section is intended to be a companion to the incident response and emergency management recommendations. For example, a defined process for responding to and remediating a compromised social media account. Template [here](https://frameworks.securityalliance.org/community-management/index.html). | | Compliance | `[MANDATORY]` The DAO must keep a record of its compliance efforts, including policies, procedures, and audit results. It should make its best efforts to comply with the regulatory frameworks applicable to its areas of incorporation.

Note that regardless of DAO jurisdiction or its regulatory standing, assets such as websites, frontends, forums, etc. can be subject to various data privacy laws. It is recommended to make a concerted effort to adhere to regulatory obligations to prevent future burdens or headaches such as “DSARs” and “Right to be forgotten” requests.| ## Protocol Controls @@ -53,10 +53,10 @@ The following set of controls are authored for protocol DAOs, i.e DAOs that cont | Control | Description | | :--- | :--- | -| Data transparency | 1. `[MANDATORY]` Code that the DAO governs should be available somewhere publicly, even if it is not open source.

2. `[RECOMMENDED]` All DAO related smart contracts including protocol, token, governance and treasury related smart contracts, should be verified on block explorers, if the provision exists.

3. `[RECOMMENDED]` There should be publicly accessible documentation on the protocol components, along with flow diagrams, design choices, dependencies and a record of critical privileged roles. | +| Data transparency | 1. `[MANDATORY]` Code that the DAO governs should be available somewhere publicly.

2. `[RECOMMENDED]` All DAO related smart contracts including protocol, token, governance and treasury related smart contracts, should be documented, as well as verified on block explorers, if the provision exists. For example, there should be publicly accessible documentation on the protocol components, along with flow diagrams, design choices, dependencies and a record of critical privileged roles. | | Code security | `[MANDATORY]` Protocol code __MUST__ be audited, and a comprehensive report detailing vulnerabilities and suggested improvements should be publicly available for the latest protocol version.| -| Bug bounty program | 1. `[RECOMMENDED]` The DAO is recommended to operate a bug bounty program, should it handle user funds.

2. `[RECOMMENDED]` The DAO is recommended to execute a white hat [Safe Harbor agreement](https://github.com/security-alliance/safe-harbor) if the provision exists.| -| Key management | `[MANDATORY]` Use isolated and purpose specific hardware wallets for multisig key holders and delegates. | +| Bug bounty program | 1. `[RECOMMENDED]` The DAO is recommended to operate a bug bounty program.

2. `[RECOMMENDED]` The DAO is recommended to execute a white hat [Safe Harbor agreement](https://github.com/security-alliance/safe-harbor) if the provision exists.| +| Key management | `[MANDATORY]` Use isolated and purpose specific hardware wallets for multisig key holders and delegates. SAFEs or other account abstraction implementations should also be deployed in all operational areas. | | Operational security policy for key entities |`[RECOMMENDED]` The DAO should require entities, including its foundation, founding company, or service providers with a long-term service agreement, to publish and adhere to an operational security policy.

Inspiration for the policy is [here](https://docs.google.com/document/d/1Aggn3oqT3lpTFyVmlncBTOowdpTsrGtPqCmdKcQnEdA/edit?usp=sharing). As above, the intention is to prompt operational security for all stakeholders and not to publish critical information publicly. | | Subdomains for contracts and dApps | `[RECOMMENDED]` It is recommended to provide all contracts with ENS names. dApps should enforce ENS subdomain versioning schemas (v1, v2, etc) as mentioned [here](https://ethglobal.com/showcase/undefined-0ejxp).

This is a best practice for future management of organizational units when delegating responsibilities to working groups or other sub-organizations within the DAO. Additionally this provision helps ensure that versioning remains immutable and easy to understand.| From e5b28dcd9aa43b7dd04053cc41801a179ae7c55e Mon Sep 17 00:00:00 2001 From: eth-limo Date: Mon, 2 Dec 2024 17:01:52 -0500 Subject: [PATCH 09/10] Added Scope and Intent section --- DAOIPs/daoip-8.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/DAOIPs/daoip-8.md b/DAOIPs/daoip-8.md index 4b750081..fd7d3d9e 100644 --- a/DAOIPs/daoip-8.md +++ b/DAOIPs/daoip-8.md @@ -18,7 +18,19 @@ A set of applicable controls for improving DAO security DAO security is a multi-faceted concept. Because of their decentralized nature, security measures vary across DAOs. DAOIP-8 aims to establish a minimum viable security standard among DAOs. Our intention is to ensure that at least the controls defined in this guide are standard practice in all organizations, irrespective of their scale. In writing this, we have considered data transparency, decentralized ownership, proposal safety, vendor management, defense against governance attacks, physical security, code upgrades, and other angles. While the absence of some of these (for example, a physical security policy for delegates) can lead to a critical security incident, others (for example, data transparency) may not have an immediate side effect. Even so, it may lead to second-order effects (e.g., low data transparency → loss of quality contributors → governance takeover). Hence, all DAOs are recommended to make their best effort to follow the controls outlined below. -Please note that this guide is a work in progress. It should not be taken as the gold standard when it comes to DAO security, but rather as the minimum. Several sections (for example, _vendor management policy_, or _incident response_) need to be polished to fit the design of your DAO. Security practices in web2 organizations are generally more mature than in web3 organizations like DAOs. Therefore, many of the templates and inspiration documents referenced have web2 origins. We urge DAOs to modify them considering their unique properties. +Please note that this guide is a work in progress. It should not be taken as the gold standard when it comes to DAO security, but rather as the minimum. Several sections (for example, _vendor management policy_, or _incident response_) need to be polished to fit the design of your DAO. Security practices in Web2 organizations are generally more mature than in Web3 organizations like DAOs. Therefore, many of the templates and inspiration documents referenced have Web2 origins. We urge DAOs to modify them considering their unique properties. + +# Scope and Intent + +This document is intended to provide a set of recommended controls and best practices for DAOs to establish the basic foundations of a _Technical Governance_ framework. This guide is in no way exhaustive and does not explicitly focus on prescriptive implementation details, but rather defines and describes core precepts which can be further expounded upon by contributors and stakeholders. + +The intention is to tackle the dilemma of _Technical Governance_ as it relates to DAOs and their usage of services and technologies which are either directly or indirectly related to the DAO's operations, for example, GitHub or GitLab repositories, cloud services, and other third-party providers. These external dependencies introduce novel complexities without clear boundaries relating to technical asset ownership and management. In addition to more traditional Web2 assets, DAOs also need to take on-chain assets into account when considering their security posture by defining and implementing specific controls around code security, vulnerability management, incident response, auditing, etc. + +This guide encourages DAOs to ask the question: "If we can successfully govern a treasury, why can we not also govern our own technical footprint, operations, and security posture?" This resource aims to provide a starting point for DAOs to begin to answer this question. + +While complete decentralization is the ultimate goal, it is important to recognize that the DAO ecosystem is still in its infancy and explicitly relies upon a myriad of centralized infrastructures and services in order to operate. These aforementioned dependencies are not typically taken into consideration when discussing DAO governance and thus present unique challenges to DAOs in terms of security and operational risks. + +# Categories of Controls Controls below are categorized into: 1. `[MANDATORY]`: includes measures that are critical to ensuring DAO security. @@ -26,6 +38,8 @@ Controls below are categorized into: We recommend following both categories of controls to ensure maximum security in your DAO. +The first section is applicable for _all DAOs_, irrespective of their type. + The second section is for _protocol DAOs_, i.e., DAOs that control an on-chain protocol. All DAOs, whether or not they are a _protocol DAO_, are advised to consider the controls detailed in the first section. Community contributions are essential for the ongoing evolution of this guide. Kindly refer to the contribution guide below for instructions. From 729ce3dab94acefcaab31449d95dea2194459cee Mon Sep 17 00:00:00 2001 From: eth-limo Date: Mon, 2 Dec 2024 17:11:49 -0500 Subject: [PATCH 10/10] Renamed section to Technical Governance --- DAOIPs/daoip-8.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/DAOIPs/daoip-8.md b/DAOIPs/daoip-8.md index fd7d3d9e..2ab82ebd 100644 --- a/DAOIPs/daoip-8.md +++ b/DAOIPs/daoip-8.md @@ -20,9 +20,9 @@ DAO security is a multi-faceted concept. Because of their decentralized nature, Please note that this guide is a work in progress. It should not be taken as the gold standard when it comes to DAO security, but rather as the minimum. Several sections (for example, _vendor management policy_, or _incident response_) need to be polished to fit the design of your DAO. Security practices in Web2 organizations are generally more mature than in Web3 organizations like DAOs. Therefore, many of the templates and inspiration documents referenced have Web2 origins. We urge DAOs to modify them considering their unique properties. -# Scope and Intent +# Technical Governance -This document is intended to provide a set of recommended controls and best practices for DAOs to establish the basic foundations of a _Technical Governance_ framework. This guide is in no way exhaustive and does not explicitly focus on prescriptive implementation details, but rather defines and describes core precepts which can be further expounded upon by contributors and stakeholders. +In addition to the recommended best practices described above, this document is also intended to provide a set of recommended controls and best practices for DAOs to establish the basic foundations of a _Technical Governance_ framework. This guide is in no way exhaustive and does not explicitly focus on prescriptive implementation details, but rather defines and describes core precepts which can be further expounded upon by contributors and stakeholders. The intention is to tackle the dilemma of _Technical Governance_ as it relates to DAOs and their usage of services and technologies which are either directly or indirectly related to the DAO's operations, for example, GitHub or GitLab repositories, cloud services, and other third-party providers. These external dependencies introduce novel complexities without clear boundaries relating to technical asset ownership and management. In addition to more traditional Web2 assets, DAOs also need to take on-chain assets into account when considering their security posture by defining and implementing specific controls around code security, vulnerability management, incident response, auditing, etc.