How can this contract distribute BUSD dividends?

Smart Contracts
1

So this contract from https://bscscan.com/address/0x9d30E245Dd356e4075456cfB2Aa86ad454B9549A#code

it says it distribute BUSD dividends, but upon multiple tests i can't seem to identify the proper sequence

Tests includes :

Adding liquidity BNB/TOKEN
Adding liquidity BUSD/TOKEN

Used a different address to swap & trade to both, still no dividends received.
Used claim function

Also the function "Distributedividends" from the contract "DividendPayingToken" are not showing on write functions upon deploying. Is there something wrong in this contract?

How to deploy?
deploy the IterableMapping first then deploy the main contract
include the IterableMapping address on the .json file on artifacts(if you're using remix)
include the IterableMapping adress and name as a library upon verifying

2

There is something wrong with what you think "this contract" is:

  • Function distributeDividends is implemented in contract DividendPayingToken
  • Contract DividendPayingToken is inherited by contract DividendTracker
  • An instance of contract DividendTracker is deployed during the construction of contract SW
  • Contract SW is "this contract", i.e., the one deployed at the address that you've linked above

So "this contract" does not expose function distributeDividends directly.
Instead, it exposes dividendTracker - a pointer to the contract which implements that function.

1 Like
4

Hi Barakman, thanks for pointing that out.

would it be ideal to fix this by doing Contract SW is DividendPayingToken in order to hookup the needed functions?

5

Well, splitting it into several contracts embeds several downsides, which raises the question - why did you choose this architecture to begin with?

Typical incentives for this choice are:

  • Contract byte-code size exceeding the maximum (24KB)
  • Storing the state of the system (including funds) in a separate contract

Typical downsides for this choice are:

  • More expensive transactions, due to external calls between contracts
  • Potential reentrancy exploit, requiring careful review followed by appropriate protection

So the decision of whether or not to use a single contract (as you've suggested above) largely depends on a number of design considerations which you need to make, based on your product requirements.

7

thanks for that, so base on this contract, or what we have in discussion rather, what would you suggest on doing for a reflection reward? or what model would you suggest?

I do not own this contract and just found it to play around with since there are few projects that offers "BUSD/USDT" as a reflection rewards.

8

I don't understand how this is related to the question.

Any change that you do, in particularly "merging" two contracts into one, would require you to redeploy a new contract or contracts, which you WILL be the owner of.

9

Last question for this, there's a function called swapExactTokensForETHSupportingFeeOnTransferTokens and it seems to distribute the rewards, how to use/call that?

10

It's a function on a completely different contract (Uniswap V2 Router).