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
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
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?
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.
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.
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.
Last question for this, there's a function called swapExactTokensForETHSupportingFeeOnTransferTokens
and it seems to distribute the rewards, how to use/call that?
It's a function on a completely different contract (Uniswap V2 Router).