Ethereum

Has anyone written eth contracts where one token is continuously minted to the holders of another token? I know the GNO/OWL pattern (which only works when staked). Seems like doing it safely requires meticulous, maybe UTXO-like tracking of proportions & flow rates change. Any efficient solutions?

co founder of @metamask . Making computers behave for us.

This is the alt account of Sister Hazel. Writings at https://powerlaw.systems. Building https://testnet.uvio.network. 

I don't think `balanceOf` even needs to be accurate for profits owed. I think there are quite a few places where the guarantees could be weakened, but the basic promises should be something like:

- If anyone gets paid out, then everyone who has equity at that point is assured to be able to get paid out at that rate (if not paid out instantly).

One way I was imagining weakening liveness for performance is making the withdraw function public, and only dividing up owed funds according to holdings at those points. If people care a lot about shifting equity, they could always call it more often. Otherwise, if equity is stable, everyone can just chill and watch it accrue.

Do you need to send tokens every block or is it good enough when balanceOf returns the accurate result when being called?

IDK if its possible but I think the best option would be something like delta + socialized rebalancing. I.e. every interaction with the contract updates the state to reflect the changes since the last update. All of that should allow atomic delta capture if you apply it to all state change events. Not sure on the gas impacts tho

Developer of Echo Protocol / DevRel @ Flow Foundation - (flow.com)

I could see splitting those up as being necessary to make sure the operation can be split up across blocks if needed.

Yeah doing the live estimation on FE & enforcement onchain is how I'm imagining too. I probably have a general approach that's decently effective now.

Sorry, did some digging and no luck.  From what I remember, they were doing it with two transactions - one to initiate the collection and one to claim rewards.  I think they were simulating the over time part on the FE then doing the calculation onchain when the claim happened.

I'm jet lagged and am falling asleep but I talked to someone a few months ago who was doing this for a game.  I'll try to find if I have any messages about it tomorrow.

https://github.com/0xBeans/DRIP20 by x.com/0x_beans does kind of that!