Add OGNRewardsSource contract

[shahthepro]

If you made a contract change, make sure to complete the checklist below before merging it in master.

Contract change checklist:

• [ ] Code reviewed by 2 reviewers.
• [ ] Copy & paste code review security checklist below this checklist.
• [ ] Unit tests pass
• [ ] Slither tests pass with no warning
• [ ] Echidna tests pass if PR includes changes to OUSD contract (not automated, run manually on local)

[pandadefi]

@shahthepro I have added my comments regarding the changes.

[DanielVF]

FixedRateRewardsSource

Requirements

The FixedRateRewardsSource works to provide a steady per block stream of incentives funds to the xOGN staking contract.

Rewards can be sent to the contract from any source (including incentives, as well as protocol buybacks), but will drip out at a rate that can be changed by the strategist.

In the event that not enough funds are in the dripper, what funds are there are given out, and the dripper is reset to start accruing max dripped funds again. In this way even if there are fewer funds than expected coming in, the contract will still hand out whatever funds it does get.

Deployment Considerations

There's a potential circular address dependency between this contract and the staking contract. Both need to know the address of the other. We've taken the simple route and made this contract us a mutable address for the staking contract, while the staking contract uses an immutable address for this.

If the contract is not initialized, collect rewards will revert because the message sender is not 0, preventing anything weird from happening.

This should be deployed into a proxy.

Internal State

config.lastCollected should never move downwards. This holds. It is always set to the current timestamp, which does not move down.

config.lastCollected should be set any time rewards are sent from the contract. It is.

We should not have resolution issues on config.ratePerSecond, since we can pay at a rate down to trillions of a penny's worth of yield per day.

Attack

Depending on how this contract is used, it could hold up to a month or two of incentives. This could be a substantial amount reward tokens. This contract does not hold any user funds.

Attackers could attempt to steal funds. However, Funds only transfer to the admin controlled rewards target.

Attackers could attempt to increase the number of rewards paid. However rewards paid can only be increased by donating to the contract (and only then if it does not have enough rewards)

A collectRewards should be called before changing the setRewardsPerSecond, if we care about accuracy, or if it has not been called in a long time. This ensures that the past is paid at the past rate.

Logic

Contract logic looks correct .

Tests

• [x] Each publicly callable method has a test
• [x] Each logical branch has a test
• [x] Each require() has a test
• [ ] Edge conditions are tested
• [ ] If tests interact with AMM make sure enough edge cases (pool tilts) are tested. Ideally with fuzzing.

Flavor

There are a few tiny flavor changes I see, but we can leave the contract as is.

• In setRewardsPerSecond, we are not getting any gas savings out of using a local storage variable for _config, code would be shorter, and more safely changed without the local variable.
• In collect rewards, the RewardCollected event is not necessarily called every time lastCollect is changed. This makes for a possible state changing function call that does not event, and prevents perfect tracking of what the future rewards will be based purely on events. That said this is only an issue when reward rate is set for some time to zero and then again raised.

Overflow

No for loops

Proxy

• [x] Make sure proxy implementation contracts don't initialize variable state on variable declaration and do it rather in initialize function.

Black magic

• [x] Does not contain selfdestruct
• [x] Does not use delegatecall outside of proxying
• [x] Address.isContract should be treated as if could return anything at any time, because that's reality.

Dependencies

• [x] Review any new contract dependencies thoroughly (e.g. OpenZeppelin imports) when new dependencies are added or version of dependencies changes.
• [x] If OpenZeppelin ACL roles are use review & enumerate all of them.
• [x] Check OpenZeppelin security vulnerabilities and see if any apply to current PR considering the version of OpenZeppelin contract used.

Deploy

• [ ] Check that any deployer permissions are removed after deploy (Deploy will be a separate PR.)

Authentication

• [x] Never use tx.origin
• [x] Check that every external/public function should actually be external
• [x] Check that every external/public function has the correct authentication

Cryptographic code

_No Crypto

Gas problems

• [x] Contracts with for loops must have either:
  • [ ] A way to remove items
  • [ ] Can be upgraded to get unstuck
  • [ ] Size can only controlled by admins
  • [x] No for loops
• [x] Contracts with for loops must not allow end users to add unlimited items to a loop that is used by others or admins.

External calls

• [x] Contract addresses passed in from users are validated
• [x] No unsafe external calls
• [ ] Reentrancy guards on all state changing functions
  • [x] Contract only works with trusted tokens.
• [x] No malicious behaviors in dependencies
• [x] Could fail from stack depth problems (low level calls must require success)
• [x] No slippage attacks (we need to validate expected tokens received)
• [x] Oracles, one of:
  • [x] No oracles
  • [ ] Oracles can't be bent
  • [ ] If oracle can be bent, it won't hurt us.
• [x] Don't call balanceOf for external contracts to determine what they will do, when they instead use internal accounting?

Ethereum

• [x] Contract does not send or receive Ethereum.
• [x] Contract has no payable methods.