-
-
-## DAO Contributors Structure
-
-The organizational structure of contributors which receive grants from the DAO
-is often comprised of hierarchical teams and subDAOs both of which manage,
-streamline, and secure the success of their deliverables to API3.
-
-### Hierarchical Teams
-
-More granular tasks are conducted through hierarchical team structures for
-scalable governance.
-
-A best-practice workflow is to form off-chain teams and apply for grants to
-execute one-time projects or time-defined operations that will benefit API3. The
-team makes the grant application with a multisig that has the team members
-assigned as users, and the DAO permissionlessly transfers the grant to the
-multisig if the grant proposal is accepted and passed by the DAO contract logic.
-
-This team-based governance scheme is scalable in terms of gas costs, as it
-requires fewer proposals to be voted on at the DAO level. It is also more
-scalable in practical terms, as it does not require the constant attention of
-all governing parties to a wide variety of minute details. Furthermore, it
-allows critical operations such as dAPI management to be executed swiftly and
-based on expert opinion. As API3 operations expand, this governance hierarchy
-may demand additional layers in the form of subDAOs.
-
-To learn more about hierarchical team structures
- see Section 5.3
-of the API3 Whitepaper.
-
-### subDAO
-
-The DAO is leveraged to selectively allocate funds and decisions in line with
-the mission of API3. When a task reaches a scale that can no longer be fulfilled
-by a team, it is assigned to a subDAO.
-
-> 
-
-## Principles
-
-API3 focuses on two principles for effective governance:
-
-- Least Privilege
-- Transparency
-
-### Least Privilege
-
-To limit the amount of damage a malicious or incompetent team may cause, each
-team's authority must be constrained to a bare minimum, which is also known as
-the “principle of least privilege”. For example, a dAPI management team should
-never be able to completely recompose a dAPI that is under use, but should only
-be able to switch individual oracles in and out with a long enough cool-down
-period to discourage abuse of authority. Similarly, milestones and deliverables
-should be utilized to grant teams only the funds needed to carry out their
-specific responsibilities.
-
-### Transparency
-
-Each team is expected to produce sufficiently detailed progress reports that
-enable the DAO's participants to evaluate team performance with respect to
-proposed goals. These public reports have the additional benefit of increased
-accountability as dAPI users and the general public can audit API3 operations.
diff --git a/archives/members/assets/images/dao-dashboard.png b/archives/members/assets/images/dao-dashboard.png
deleted file mode 100644
index 5c173c1..0000000
Binary files a/archives/members/assets/images/dao-dashboard.png and /dev/null differ
diff --git a/archives/members/assets/images/executable-proposal.png b/archives/members/assets/images/executable-proposal.png
deleted file mode 100644
index 4c24cdd..0000000
Binary files a/archives/members/assets/images/executable-proposal.png and /dev/null differ
diff --git a/archives/members/assets/images/ipfs-proposals.png b/archives/members/assets/images/ipfs-proposals.png
deleted file mode 100644
index 8f0a040..0000000
Binary files a/archives/members/assets/images/ipfs-proposals.png and /dev/null differ
diff --git a/archives/members/assets/ipfs-proposals.drawio b/archives/members/assets/ipfs-proposals.drawio
deleted file mode 100644
index c5b1eb8..0000000
--- a/archives/members/assets/ipfs-proposals.drawio
+++ /dev/null
@@ -1 +0,0 @@
-0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48.
-
-6. Enter the **Contract Target Signature**.
-
- > Defines the signature of the function to call within the target contract.
- > For the target contract USDC mentioned above use
-
-
-
- > `transfer(address,uint256)`. Do not use any spaces
- > in the signature: leading, trailing or otherwise.
-
-7. Enter an **ETH Value**.
-
- > You can use zero if the target function is not `payable`.
-
-8. Enter **Parameters** which are the arguments that will be used to satisfy the
- signature of the target contract function in step #6.
-
- > In the case of step #5 above, the address
- > `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` is for the USDC contract. You
- > will be calling its `transfer` function, as indicated in step #6, should
- > the proposal pass.
-
- > The arguments must be provided in JSON array format where the values are
- > stringified. `["0xF4EB52Cf9D31a...d1663d78ddDEE9","499999000000"]`
-
- In the example directly above, the respective Agent (primary or secondary )
- would be calling the USDC contract
- (`0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`) to transfer 499,999 USDC to
- `0xF4EB52Cf9D31a...d1663d78ddDEE9`. Note that since
- `transfer(address,uint256)` function transfers funds from the sender to the
- specified address, the USDC is asked to be supplied from the Agent's balance.
-
- USDC uses 6 decimal places of precision as opposed to 18 that many other
- ERC20 tokens use. Consequently, multiply the desired $USD by 10^6 to get the
- USDC amount to enter.
-
-9. When you are ready, click the **Create** button at the bottom of the page.
-
-> The proposal is then added to the proposal list and can be voted on.
-
-10. Return to the [API3 forum](https://forum.api3.org/c/official-proposals/5)
- and add a comment to your post with a link to your newly created proposal.
- This will help and encourage community members to vote.
-
-## Proposal Execution
-
-A proposal is ready for execution if:
-
-1. The proposal hasn't already been executed, and
-2. the proposal's voting period has ended, and
-3. the total "yes" vote exceeds the "no" vote, and
-4. (for Secondary type proposals) at least 15% of all voting power has voted
- "yes" on the proposal.
-
-Primary type proposals require 50% of all voting power to have voted "yes" on
-the proposal. Both primary and secondary type proposals execute immediately once
-50% of all voting power has voted "yes" on them.
-
-
-
-## Using ENS Names
-
-You are encouraged to use the [ENS app](https://app.ens.domains/) to register a
-name and associate it with an Ethereum account. Then, while entering your
-proposal parameters, you can use this ENS name instead of the account address.
-Before making the transaction that will create the proposal, the DAO dashboard
-will look up the address that the ENS name is pointing to and use the raw
-address in the proposal. Therefore, changing the address that the ENS name is
-pointing to after this look up operation **WILL NOT** have an effect on the
-proposal.
-
-For voters to see your ENS name instead of the raw address on the proposal
-details page, you will have to use the [ENS app](https://app.ens.domains/) to
-set a reverse record pointing to your ENS name (i.e., you need to have your raw
-address point to the ENS name). If your proposal will make a
-`transfer(address,uint256)` call to an ERC20 token contract where `address` is
-the address of a _multisig_ wallet, you can
-[set a reverse record with the multisig](https://medium.com/the-ethereum-name-service/you-can-now-manage-ens-names-with-gnosis-safe-9ddcb7e6c4ac)
-to your ENS name. See Parameters in
-[this proposal](https://api3.eth/#/history/secondary-31) for an example.
-
-## Using IPFS for Proposals
-
-Consider this use case: You posted on the [API3 forum](https://forum.api3.org/)
-about a potential proposal. You received positive feedback and decide to
-formally create a proposal using the DAO dashboard. In the proposal's
-description field you provide a link back to the forum so people can again see
-the proposal details. How does the voter know that it's the exact same proposal
-they had read earlier in the forum? IPFS addressing content by its hash is
-convenient here, because any change you'll make to your proposal will change its
-hash.
-
-
-
-There are hosting services for IPFS such as [Pinata](https://www.pinata.cloud)
-and [Fleek](https://fleek.co) to name a few. To host a proposal description on
-Pinata's IPFS site:
-
-1. Create a PDF version of the proposal.
-1. Upload the PDF to Pinata or your preferred IPFS hosting provider. To do so
- using Pinata, select the **Files** menu from the sidebar on your personal
- Pinata dashboard, then select the **Add Files** button. Drag the desired file
- into the upload dialog.
-1. After the file is uploaded, Pinata will create a URL with the IPFS hash for
- the PDF. Simply click on the file's link to display the PDF and copy its URL
- from the browser URL bar.
-1. Add the URL to your forum posting and later to the description field of your
- DAO dashboard proposal.
-
-Remember that the URL the voter sees in the DAO dashboard proposal description
-field is final and should match the URL on the forum.
-
-**Updating a PDF**
-
-You can update your PDF if needed before creating a formal proposal using the
-DAO dashboard. First, upload the new version to your IPFS provider; since the
-content has changed, it will get a new hash. Next, update the link in your forum
-posting. Lastly, create the proposal using the DAO dashboard. Since the proposal
-contains the IPFS hashed link in the description field, the PDF should be
-considered final and changing the hashed link in the forum at this point would
-caution the voter.
diff --git a/archives/members/sidebar.js b/archives/members/sidebar.js
deleted file mode 100644
index 0bd7932..0000000
--- a/archives/members/sidebar.js
+++ /dev/null
@@ -1,27 +0,0 @@
-module.exports = [
- {
- text: 'Overview',
- link: '/dao/',
- },
-
- {
- text: 'Members',
- collapsed: false,
- items: [
- {
- text: 'Overview',
- link: '/dao/',
- },
- ],
- },
- {
- text: 'Technical',
- collapsed: true,
- items: [
- {
- text: 'Contracts',
- link: '/dao/',
- },
- ],
- },
-];
diff --git a/archives/members/staking.md b/archives/members/staking.md
deleted file mode 100644
index 8847726..0000000
--- a/archives/members/staking.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Staking Tokens
-pageHeader: Members
-outline: deep
----
-
-
-
-> 1. [Staking](/overview/pool.md#staking): Grants membership in the API3 DAO and
-> rights to inflationary
-> 1. [Collateral](/overview/pool.md#collateral): Backs service coverage that
-> protect users from damages caused by dAPI malfunctions.
-> 1. [Governance](/overview/pool.md#governance): Grants direct representation in
-> the API3 DAO.
-
-Note that it is critical for these three utilities to coincide. All governing
-entities must receive staking rewards for them to govern in a way that maximizes
-revenue. All governing entities must have their funds used as collateral for
-them to govern in a way that minimizes **_security_** risks. "_Security_" refers
-to a "guarantee or reliability of dAPI service"
-
-Reference section
-5.4 _API3 Tokenomics_ of the API3 whitepaper.
-
-### Staking
-
-The staking utility incentivizes participation in the DAO and alignment of
-incentives. By staking your API3 tokens into the DAO pool, you receive
-governance voting rights and take part in providing API3 users with quantifiable
-_security_ in the form of service coverage. The DAO pool also grants you
-inflationary rewards and exposes you to the risk of service coverage claims.
-
-> 
-
-> Staked tokens in the DAO pool grant -> governance voting rights, inflationary rewards and are used to fund the coverage -> service which exposes staked tokens to the risks of service coverage claims.
- -#### Benefits - -- Generates [inflationary rewards](/overview/rewards.md) by decreasing the - circulating supply of API3 tokens through revenue burn from service coverage - fees. -- Improved token inflation protection compared to unstaked tokens. -- Voting privileges on DAO proposals. - -#### Risks - -- Staked tokens in the DAO pool are used to cover potential financial losses - from dAPI malfunctions that the dAPI consumer might incur. - -To stake your tokens, see the guide [Staking Tokens](/members/staking.md). You -can stake as many times as you’d like. Your percentage of all the tokens in the -DAO pool are directly related to your percentage of the rewards and the risks. -If you stake 10% of the pool you earn 10% of rewards and will pay 10% of service -coverage claims. - -### Collateral - -The collateral utility has the participants share the DAO's operational risk and -incentivizes them to minimize it. - -If staking tokens only yielded inflationary [rewards](/overview/rewards.md), the -sole governance incentive would be to maximize the revenue. This would be done -by increasing the number of dAPI users aggressively, and the amount that is -secured by the dAPIs with it. Doing so puts excessive pressure on a dAPI which -is more likely to malfunction due to an attack. Therefore, this is not a -sustainable governance strategy for decentralized data feeds. - -Exposing the governing parties to the risk would align their incentives with -that of the DAO. The governing parties need to be penalized when a dAPI -malfunction occurs using an onchain service coverage that provides dAPI users -with quantifiable and trustless security guarantees. Service Coverage uses -staked tokens of the DAO pool as collateral, which means that when a dAPI -malfunction is confirmed through the dispute resolution protocol, user damages -will be covered from the pool's staked tokens. - -See Section 5.4.2, -_Collateral_, of the API3 whitepaper. - -### Governance - -The governance utility gives the participants the ability to enact and manage -staking and collateral. - -The only way to gain representation in the DAO is to stake API3 tokens in the -pool. Staked tokens give their holders the right to take part in the governance -of the API3 ecosystem through the DAO. To vote token holders must stake their -API3 tokens in the pool, which also gives them access to weekly inflationary -[rewards](/overview/rewards.md). - -All governing parties will be exposed to all risks and rewards of API3, and will -govern to optimize them. Inflationary rewards and the staked tokens being used -as collateral will create a positive feedback loop in terms of governance -quality. Initial token holders will have to stake and expose themselves to risk -if they do not want to lose value to inflation. If they misgovern and lose -collateral through service coverage claims, these tokens will get returned to -the open market, from where they will be acquired by new governing parties. In -contrast, if initial token holders govern well and cause token scarcity in the -market, the representation distribution will be protected. In other words, -governance tokens being used as collateral results in a robust Darwinian -structure that improves itself and is able to recover from failures. - -## Monetization - -In general the industry standard for API provider subscription fees are commonly -paid monthly or annually, as this scheme suits both API providers and their -clients. API3 follows the same scheme for dAPIs. - -### dAPI monetization - -To gain access to a dAPI, a dApp will pay a recurring subscription fee, which -may be fixed or customized for the dApp based on a specific use case. These -prices will be determined by the respective team. The payment can be made in any -cryptocurrency, which will be received by the DAO in API3 tokens through a -liquidity pool-based decentralized exchange. - -### API provider compensation - -API providers will be compensated periodically at fixed rates, which will fit -their existing pricing models. This will be done using stable coins wherever -possible, some API providers categorically reject handling cryptocurrency as -payment. In such cases, the DAO will provide a grant that will be paid out in -return of the proof that the API provider is compensated in fiat by the grantee. diff --git a/archives/overview/rewards.md b/archives/overview/rewards.md deleted file mode 100644 index 1d3336b..0000000 --- a/archives/overview/rewards.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Inflationary Rewards -pageHeader: Overview -outline: deep ---- - -
-
-> Fees from revenue are converted to API3 tokens and burned. Inflationary rewards are minted to stakers by the DAO contract. Successful service coverage claims are paid to covered claimants from the pool of staked tokens.
- -## Earning Rewards - -Earning inflationary rewards is simple: everyone who has staked API3 tokens into -the DAO pool contract to participate in governance will earn rewards as they are -minted to the DAO pool. When you schedule tokens to be unstaked, you stop -earning rewards for those tokens. - -Remember that when you stake, you receive non-transferable pool shares equal to -the current total number of pool shares divided by the total number of tokens -staked. Since the reward adds additional tokens to the pool, one pool share does -not always correspond to one token. - -## Incentives of Rewards - -In essence, inflationary rewards entice token holders to stake and avoid -relative dilution of their tokens. However, staking is risky due to the staked -tokens being used as collateral for service coverage policies, which encourages -the staker to participate in governance to ensure that the risk is minimized. As -a combination of the two, an inflationary governance token used as collateral -attracts all token holders to participate in governance, which is ideal because -it maximizes the decentralization of governance. Inflationary rewards are -automatically minted weekly by the DAO governance smart contract. Furthermore, -inflationary rewards are locked for a year, which results in governing parties -sharing the project’s long term interests. - - - -## Reward Calculation And Distribution - -The staking reward will float to have the total staked amount reach equilibrium -at the target. In other words, the staking reward is programmed to increase -while the staked amount is below the target, and vice versa. There is no -pre-determined schedule. - -Reward amount is represented as APR (annual percentage rate) in API3 tokens. You -can derive APY (annual percentage yield) using an -[online calculator](https://www.omnicalculator.com/finance/apy). There is a -governable "APR update step", which is the step size each week the APR will be -updated with. Also there are governable minimum and maximum APR values, but -these (especially maximum APR) are there as safety measures. In general, -governing the stake target will be the primary tool for regulating rewards. - -Rewards are added as staked API3 tokens into the DAO pool each time the -`mintReward` function is called. `mintReward` is callable by anyone, once per -"epoch" (and single epoch length is 1 week). When it is called, an amount of -API3 tokens is minted and added to the DAO pool: - -> ``` -> rewardAmount = totalStakedTokens * APR * epochLengthInSeconds / yearInSeconds / 100 -> ``` -> -> (see the -> [smart contract source](https://github.com/api3dao/api3-dao/blob/main/packages/pool/contracts/RewardUtils.sol#L24) -> for more information). - -In addition, each time `mintReward` is called, the annual percentage (the reward -rate) is updated up or down by the APR update step size (1%), according to -whether the total number of staked tokens is above or below its target. The -initial target is 50%, so if the total number of staked tokens is less than 50% -of the total token supply when `mintReward` is called, APR will be raised by 1% -for the next reward mint (and vice versa). Thus, APR will constantly be -adjusted, but it will always stay between a designated maximum and minimum. - -:::info Example - -Rewards Distribution User X stakes 600 tokens and user Y stakes 400, so there is -a 60% (X) 40% (Y) split ownership in the 1000 token DAO pool. For a particular -week the reward mint is 1% (10 total tokens) and the pool is now 1010 tokens. X -at 60% now has 606 tokens and Y has 404. Remember that the 10 reward tokens are -locked for a period of one year. - -::: - -## Reward Withdrawal - -Rewards withdrawals are baked into default withdrawals, except that rewards are -locked for 1 year after minting. As a staker, your pool shares will always -reflect a proportional claim on the pool of staked tokens, including any rewards -that have been minted. When you unstake and withdraw your tokens, you will -receive: - -- your tokens, -- plus any share of the rewards you earned, -- minus rewards that were added to the pool within the last year, which will - remain staked. - -_To summarize reward withdrawal:_ you will not be able to withdraw your rewards -for a year. Since rewards get minted every week, you can think of this as a -rolling unlock (the rewards you receive this week will get unlocked 1 year -later, the rewards you will receive next week will get unlocked 1 year 1 week -later, etc.) This 1 year-lock is the secret sauce to good decentralized -governance, it essentially aligns the incentives of the stakers/governors with -the ones of the DAO/project/token for a whole year. diff --git a/archives/page.md b/archives/page.md deleted file mode 100644 index 13a6eaf..0000000 --- a/archives/page.md +++ /dev/null @@ -1,759 +0,0 @@ -# Overview - -## What is the API3 DAO? - -API3 delegates much of its governance to the vote of a Decentralized Autonomous -Organization (DAO). API3 is a collaborative effort to build, manage and monetize -data feeds at scale. To achieve delegated governance and distribute grants in a -fully decentralized way, the incentives and processes of the participants are -reconciled through the governance, security, and value capture utilities of the -API3 token and its powers in the API3 DAO. - -## Governance - -The DAO votes on high-level matters such as staking incentives and -collateralization (parameters of the DAO smart contract itself), as well as -grant proposals that directly transfer DAO treasury assets to contributors of -API3. - -The API3 ecosystem is a single token environment, using its native token (API3). -Check out the Medium post -[API3 Tokenomics Update](https://medium.com/api3/api3-tokenomics-update-f032d6e49b30) -for an in-depth overview on API3 tokenomics. To participate in governance, you -need to stake API3 tokens in the DAO’s staking pool. - -## Rewards - -Through staking API3 tokens in the pool, you gain access to weekly -[rewards](https://docs.api3.org/explore/dao-members/rewards.md) (unlocked -after one year) and are also granted voting rights on active DAO proposals and -rewards. - -Why one year? Since rewards get minted every week, you can think of this as a -rolling unlock (the rewards you receive this week will get unlocked 1 year -later, the rewards you will receive next week will get unlocked 1 year 1 week -later, etc.) This 1 year-lock is the secret sauce to good decentralized -governance, it essentially aligns the incentives of the stakers/governors with -the ones of the DAO/project/token for a whole year. - -To read more about rewards, visit the -Rewards Calculation and Distribution section. - -## DAO Contributors - -Contributors receive grants from the DAO and are often composed of hierarchical -teams which manage, streamline, and secure the success of their deliverables to -API3. - -A best-practice workflow is to form off-chain teams and apply for grants to -execute one-time projects or time-defined operations that will benefit API3. The -team makes the grant application with a multisig that has the team members -assigned as owners, and the DAO permissionless-ly transfers the grant to the -multisig if the proposal is accepted and passed by the DAO contract logic. - -This team-based governance scheme is scalable in terms of gas costs, as it -requires fewer proposals to be voted on at the DAO level, and in practical terms -as it does not require the constant attention of all governing parties to a wide -variety of minute details. Furthermore, it allows critical operations such as -data feed management to be executed swiftly and based on expert opinion. - -## DAO Tracker - -The [DAO Tracker](https://tracker.api3.org/) is a community-developed tool that -provides additional insight into the DAObeyond what is offered by the -intentionally minimalist DAO Dashboard. It features data about all aspects of -the DAO, including staking and reward data, members, proposals, and the API3 DAO -treasury. - -Its [open source codebase](https://github.com/api3dao/api3-tracker) was -developed by GitHub user EnormousCloud. - -# Using the DAO Dashboard - -The [DAO Dashboard](https://dao.api3.org/) is the portal to participate in the -API3 DAO. It is aimed at API3 members and others that want to interact with the -DAO or modify/reuse any of its infrastructure. The DAO requires a web3 wallet, -such as [MetaMask](https://metamask.io/download/), to be integrated with your -browser. Be sure your wallet is connected to the Ethereum mainnet. - -## Staking Tokens - -(staking page overview video) - -Staking API3 tokens in the -[staking pool](https://docs.api3.org/explore/dao-members/dao-pool.md) makes -you eligible for rewards and governance rights. - -The DAO uses an adaptive reward system to incentivize staking. Rewards will -increase to incentivize staking when the total staked is below the staking -target, and decrease to reduce token emissions when the total staked is above -the staking target. To see the current funding status, you can see the -percentage of target met. - -### 1. Deposit Tokens - -(deposit and withdraw video) - -Before tokens can be staked you must deposit them in the staking pool. Doing so -will remove them from your wallet and place them into the staking pool under the -control of its smart contracts. Your Balance reflects the amount of tokens you -have deposited and not yet staked. Withdrawable (and unstaked) tokens can be -removed from the staking pool at any time and returned to your wallet. - -To deposit tokens, click the Deposit button. If this is your first time -depositing, you’ll have to authorize the staking pool smart contract first by -clicking Approve. Note that deposited tokens are not staked. They will not earn -rewards or grant you governance rights. - -You can only withdraw tokens that are not staked. The Balance section displays -the maximum amount that can be withdrawn under “Withdrawable”. To withdraw -tokens, click the Withdraw button. The tokens withdrawn are returned to your -wallet. - -### 2. Stake Tokens - -(stake and earn video) - -To stake tokens, click the Stake button. The number of tokens available to stake -depends on the number of tokens deposited and are available to withdraw as -displayed in the Balance box as under “Withdrawable”. - -### 3. Claim Rewards - -(unstake and claim video) - -You will not be able to withdraw your rewards for a year after receiving them. -Since rewards get minted every week, you can think of this as a rolling unlock -(the rewards you receive this week will get unlocked 1 year later, the rewards -you will receive next week will get unlocked 1 year 1 week later, etc.) This 1 -year-lock is the secret sauce to good decentralized governance, it essentially -aligns the incentives of the stakers/governors with the ones of the -DAO/project/token for a whole year. Unstake tokens to claim your unlocked -rewards. Note that unstaking will revoke your most recent weekly reward payment, -and scheduling tokens to be unstaked stops earning rewards for those tokens. - -To protect the DAO from proposal spam, unstaking is subject to a seven day -waiting period. To initiate unstaking, click “Initiate Unstake”. - -After the unstaking has been initiated, the interface will display the pending -amount of tokens that are being unstaked and a countdown timer. Tokens cannot be -unstaked until the timer is complete. - -Once the seven day timer has run out, there are two ways to complete the -process: - -1. **Unstake & Withdraw: **This option will immediately unstake your tokens and - deposit them into your wallet. -2. **Unstake: **This option will unstake your tokens while keeping them - deposited in the DAO. From here you can use the Withdraw link to move the - tokens to your wallet at any time or stake them again. - -## Working with Proposals - -(proposals and history video) - -Proposals are an important part of DAO governance, and can be used to fund DAO -projects or ratify DAO-level decisions like updating the stake target. Staking -tokens in the pool gives you governance rights to create and vote on proposals. -Use the Governance page to create proposals, browse active proposals, view the -treasury, and delegate your votes. - -### Proposal Creation - -To create a proposal, there are two requirements: - -1. You haven't created a proposal in the last 7 days. -2. You need at least 0.1% of the staking pool to create a proposal. - -To view the percentage of staked tokens in the pool for an address, visit the -[DAO Tracker wallets page](https://tracker.api3.org/wallets). - -In order for your proposal to succeed, a few steps are highly recommended. - -1. Promote your idea and gather feedback on the API3 forum using a - [sentiment check post](https://forum.api3.org/t/sentiment-check-template/56). - Generally, ideas receiving community engagement on the forum are more likely - to pass once crafted as official proposals. -2. Create an - [official proposal](https://forum.api3.org/t/api3-dao-example-proposal-template/52) - post on the API3 forum. This should contain a link to the - [proposal description on IPFS](https://docs.api3.org/guides/dao-members/proposals.html#using-ipfs-for-proposals). -3. After receiving feedback from the above steps, create a formal proposal using - the DAO dashboard as described below. - -Proposals may be either primary or secondary. Primary proposals require an -absolute majority vote to pass, while secondary proposals require 15% and a -relative majority support. - -#### Creating a formal proposal - -(create a proposal video) - -1. Click **New Proposal** on the Governance page. -2. **Proposal Type** \ - Proposals can be either Primary or Secondary voting types. These two types - have access to separate treasuries, different voting settings, and different - permissions to change contract settings. For a technical breakdown of the - different permissions granted to the DAO's proposal types (and corresponding - Agents) see this - [README](https://github.com/api3dao/api3-dao/blob/develop/packages/dao/README.md#permissions). -3. **Title** \ - Enter a descriptive proposal title.The title will appear on the Governance - page and is used to identify the proposal. -4. **Description** - - While a description can be typed text, it’s highly recommended to instead - use a PDF hosted on IPFS and adding a link back to the forum where you - posted your proposal for discussion. - - Why use IPFS? - - Consider this use case: You posted on the - [API3 forum](https://forum.api3.org/) about a potential proposal. You - received positive feedback and decided to formally create a proposal using - the DAO dashboard. In the proposal's description field you provide a link - back to the forum so people can again see the proposal details. How does the - voter know that it's the exact same proposal they had read earlier in the - forum? IPFS addressing content by its hash is convenient here, because any - change you'll make to your proposal will change its hash. - - To create an IPFS link, upload a PDF version of your proposal to an IPFS - provider like Pinata or Fleek. After the file is uploaded, the respective - provider will create a URL with the IPFS hash for the PDF. Add the URL to - your forum posting and the description field of your DAO dashboard proposal. - - Remember that the URL the voter sees in the DAO dashboard proposal - description field is final and should match the URL on the forum. - -5. **Target Contract Address** \ - This is the address of the contract to call. For example, the commonly used - target contract for USDC is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. -6. **Target Contract Signature** \ - This defines the signature of the function to call within the target - contract. For the target contract USDC address mentioned above use the exact - signature below, without spaces (leading or otherwise): - - \ - - transfer(address,uint256) - - Do not alter the signature in any way or else your proposal will be invalid. - -7. **ETH Value** \ - You can use zero if the target function is not payable. -8. **Parameters** - - These are the arguments that will be used to satisfy the signature of the - target contract function in step 6. - - For example, if you use the USDC contract address - 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, you will be calling its transfer - function, as indicated in step 6, should the proposal pass. - - If you wanted to transfer 499,999 USDC to a specific wallet (in this example - 0xF…EE9), the respective Agent (primary or secondary) would be calling the - USDC contract to transfer the USDC to the desired wallet. The arguments - would look like this: - - ["0xF4EB52Cf9D31a...d1663d78ddDEE9","499999000000"] - -- The arguments must be provided in JSON array format where the values are - stringified. -- USDC uses 6 decimal places of precision as opposed to 18 that many other ERC20 - tokens use. Consequently, multiply the desired $USD by 10^6 to get the USDC - amount to enter. - - Note that since transfer(address,uint256) function transfers funds from the - sender to the specified address, the USDC is asked to be supplied from the - Agent's balance. - - ENS Names - - You are also encouraged to use the [ENS app](https://app.ens.domains/) to - register a name and associate it with an Ethereum account. Then, while - entering your proposal parameters, you can use this ENS name instead of the - account address. Before making the transaction that will create the proposal, - the DAO dashboard will look up the address that the ENS name is pointing to - and use the raw address in the proposal. Therefore, changing the address that - the ENS name is pointing to after this look up operation WILL NOT have an - effect on the proposal. - - For voters to see your ENS name instead of the raw address on the proposal - details page, you will have to use the [ENS app](https://app.ens.domains/) to - set a reverse record pointing to your ENS name (i.e., you need to have your - raw address point to the ENS name). If your proposal will make a - transfer(address,uint256) call to an ERC20 token contract where the address is - the address of a multisig wallet, you can - [set a reverse record with the multisig](https://medium.com/the-ethereum-name-service/you-can-now-manage-ens-names-with-gnosis-safe-9ddcb7e6c4ac) - to your ENS name. See Parameters in - [this proposal](https://api3.eth/#/history/secondary-31) for an example. - -9. Click **Create** \ - The proposal is then added to the proposal list and can be voted on. -10. **Return to the - [API3 forum](https://forum.api3.org/c/official-proposals/5)** \ - Add a comment to your post with a link to your newly created proposal. This - will help encourage community members to vote. - -### Proposal Execution - -A proposal is ready for execution if all of the following requirements have been -met: - -1. The proposal hasn't already been executed -2. The proposal's voting period has ended -3. The total "For" votes exceeds the "Against" votes -4. Depending on the proposal type you selected, the respective amount of voting - power voted “For” the proposal. - -Both primary and secondary type proposals execute immediately once 50% of all -voting power has voted "For" them. - -## Voting - -(vote and delegate video) - -Staking grants DAO members the ability to vote on proposals. Your voting power -is calculated by the number of tokens you have staked divided by the total -number of tokens staked at the time the proposal was made. To Vote, select a -proposal on the Governance page and click Vote to cast a vote “For” or -“Against”. - -If you do not want to vote on each proposal yourself, you can delegate your -votes to another wallet. To delegate your votes, navigate to the Governance page -and click “Delegate”. Enter the address of the wallet you wish to delegate your -votes to or the ENS name associated with it, and finalize the transaction. - -When you delegate your vote to another user, only that person can vote for you. -However, if the person you delegated to has also delegated to someone, your -voting power is discarded. You can update your delegator after seven days have -passed since your last delegation. - -# Contracts - -## Overview - -The core of the DAO is a set of smart contracts based on Aragon's -[aragonOS](https://github.com/aragon/aragonOS). The code for all DAO contracts -can be found in the [api3-dao](https://github.com/api3dao/api3-dao/) GitHub -repo, along with instructions for how to deploy a copy of the DAO. Below is a -list of contract addresses. - ->>>>> gd2md-html alert: inline image link here (to images/image1.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>
| Name - | -Mainnet Contract Addresses - | -
| DAO Kernel - | -0x593ea926ee9820a933488b6a288433c387d06dba ❏
- |
-
| ACL - | -0x1e7ecc6d3b5b4cfdfc71cb7c3ea9ac4a55f4195a ❏
- |
-
| Staking Pool - | -0x6dd655f10d4b9e242ae186d9050b68f725c76d76 ❏
- |
-
| API3 Token - | -0x0b38210ea11411557c13457D4dA7dC6ea731B88a ❏
- |
-
| Time-lock Manager - | -0xFaef86994a37F1c8b2A5c73648F07dd4eFF02baA ❏
- |
-
| Primary Voting - | -0xdb6c812e439ce5c740570578681ea7aadba5170b ❏
- |
-
| Secondary Voting - | -0x1c8058e72e4902b3431ef057e8d9a58a73f26372 ❏
- |
-
| Primary Agent - | -0xd9f80bdb37e6bad114d747e60ce6d2aaf26704ae ❏
- |
-
| Secondary Agent - | -0x556ecbb0311d350491ba0ec7e019c354d7723ce0 ❏
- |
-
| Convenience - | -0x95087266018b9637aff3d76d4e0cad7e52c19636 ❏
- |
-
| Signature - | -Description - | -
| depositRegular(uint256 amount) - | -Deposits your API3 tokens into the pool. Tokens must be deposited before they can be staked. - | -
| stake(uint256 amount) - | -Stakes deposited API3 tokens. Staked tokens will earn rewards, grant voting power - | -
| depositAndStake(address source, uint256 amount) - | -Deposits and stakes API3 tokens in one transaction. - | -
| scheduleUnstake(uint256 shares) - | -Schedules staked tokens to be unstaked. In order to unstake API3 tokens, members must first schedule an unstake and wait the scheduled period before unstaking (currently 1 week). Tokens scheduled to be unstaked no longer grant voting power or earn rewards. - | -
| unstake(address userAddress) returns(uint256) - | -Unstakes API3 tokens, allowing them to be withdrawn from the pool (unstaking and withdrawing are separate steps). Can only be called after scheduling an unstake and waiting until the scheduled time. - | -
| withdrawRegular(uint256 amount) - | -Withdraws your API3 tokens from the Pool contract. - | -
| unstakeAndWithdraw(address destination) - | -Unstakes and withdraws tokens in one transaction. - | -
| Signature - | -Description - | -
| function deposit(address source, uint256 amount, address userAddress) - | -Callable only by the Timelock Manager contract. Deposits tokens on behalf of a user. - | -
| function depositWithVesting(address source, uint256 amount, address userAddress, uint256 releaseStart, uint256 releaseEnd) - | -Callable only by the Timelock Manager contract. Deposits tokens on a vesting schedule on behalf of a user. These vesting tokens cannot be withdrawn by the user until they have vested, but they can be staked. - | -
| function updateTimelockStatus(address userAddress, address timelockManagerAddress) - | -Updates the vesting status of a user's deposited vesting tokens (i.e. unlocks tokens) according to the schedule in the Timelock Manager contract. - | -
| Signature - | -Description - | -
| userVotingPowerAt(address userAddress, uint256 _block) - | -Returns a user's current voting power (0 if they have delegated it). - | -
| delegateVotingPower(address delegate) - | -Delegates a member's voting power, as decided by their share of the staking pool, to another address. It is not necessary to undelegate before redelegating to a new address. - | -
| undelegateVotingPower() - | -Undelegates a member's voting power. - | -
| Signature - | -Description - | -
| mintReward() - | -Distributes new API3 tokens into the staking pool, where they can be unstaked and withdrawn by members using their share of the pool - | -
| Signature - | -Description - | -
| newVote(bytes _executionScript, string _metadata, bool _castVote, bool _executesIfDecided) returns (uint256 voteId) - | -Create a new proposal in the DAO. Requires a minimum percentage of voting power (currently 0.1%). - | -
| vote(uint256 _voteId, bool _supports, bool _executesIfDecided) - | -Vote yes or no on an existing proposal. - | -
| executeVote(uint256 _voteId) - | -Execute a proposal, if it is ready for execution. - | -
| Parameter Name - | -Initial Value - | -Function Signature - | -Description - | -
| stakeTarget - | -50 * 10^16 - | -setStakeTarget(uint256 _stakeTarget) - | -Percentage of all tokens targeted to be staked - | -
| aprUpdateStep - | -1 * 10^16 - | -setAprUpdateStep(uint256 _aprUpdateStep) - | -Percentage reward APR will be increased or decreased by - | -
| maxApr - | -75 * 10^16 - | -setMaxApr(uint256 _maxApr) - | -Maximum reward APR - | -
| minApr - | -2.5 * 10^16 - | -setMinApr(uint256 _minApr) - | -Minimum reward APR - | -
| proposalVotingPowerThreshold - | -0.1 * 10^16 - | -setProposalVotingPowerThreshold(uint256 _proposalVotingPowerThreshold) - | -Percentage of all shares that must be held to create a new proposal - | -
| unstakeWaitPeriod - | -604800 (seconds) - | -setUnstakeWaitPeriod(uint256 _unstakeWaitPeriod) - | -Length of time a member must wait after scheduling unstake before unstaking tokens from the pool - | -
-
-