Payer reward config #2 #26
Conversation
…o many changed files cuz I do not yet grok pull n merge crap
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
so notably I can't actually see the distribution tx (fail or pass) in Amman, it may be that simulation is failing but it seems to be getting a hash? I am noob, plz advise
|
|
if its timing out that just means the local setup is not correct. Maybe you already had something running on this port -- I ran into this as well and had a ton of problems generally using amman, I added CI to the repo in this PR #35 maybe we should just merge it first so we can have these tests running in this PR for actual functional changes like this one you have here but ya I think I saw the tx timeouts locally when i had something else already running on that port |
|
is this meant to replace #14 |
programs/hydra/src/state.rs
Outdated
| @@ -29,6 +29,7 @@ pub struct Fanout { | |||
| pub bump_seed: u8, //1 | |||
| pub account_owner_bump_seed: u8, //1 | |||
| pub total_available_shares: u64, //8 | |||
| pub payer_reward_basis_points: u64, //8 | |||
There was a problem hiding this comment.
I know you have space because these are all initialized at 300bytes but can we just defined FANOUT_SIZE: usize = 300 here and use it in init_parent so that someone will know if this is a state breaking change easily :)
There was a problem hiding this comment.
hi again - what timezone are you @jpbogle ?
will have a look when I get settled after the hop.
I ran into this before when messing with a fork of redacted_j's fairlaunch but hadn't actually considered it as a part of a mainnet-beta thing (with 2k+ instances)
if I add this here does it break those 2k+ instances "_"
There was a problem hiding this comment.
because the size is 300 there is space left in all those 2k+ instances
but if you place this here, I believe it will cause the following fields that are currently there be offset incorrectly and thus deserialized either incorrectly or fail to deserialize
If you put it at the end of the struct it should work
and im in PST
yes Luk is on twittter but I'm unsure if they've revisited this |
Cheers - I mean, amman allows the first 40ish tx thru and then dies on this one :/ I have a new local env so I'll muck around with this PR over the weekend |
…h has been replaced with the holding account for the tippy top rain hydra. This hydra pays two other rain hydras - well, more info tba. <3 B+J. https://docs.google.com/drawings/d/1mK0O-vNXZDyzeCu5s0lu6l4Ssu8RlSZkRUCBLfRSIiQ/edit?usp=sharing
|
yo @jpbogle thanks again for proactively looking into my PR here - btw I had a look at your pending CI PR, and noticed you fixed an awful lot of grievances that cost me many minutes of glasseating lol - for instance the hydra vs hydra_wallet fugazi :/ Anyways I've looked this over, changed the struct in the appropriate spot, and then I thought to myself: well unfortunately if this hydrapixiepinatta thing gains any traction at all than the vision that @LUK3ARK had and I felt like continuing isn't exactly the most ideal. The thought was that a permissionless payer reward config model would encourage distribution bots to competitively figure out which opportunities existed vs their appetite for immediate risk-free gains. I realized a few minutes ago this is the type of stuff that MEV folks -prey on- and start entering into race wars with each other - even modifying validator software to accomplish, can vouch - and so, all in all, in the interest of this thing not eating MPL && Solana at large, I'm just gonna be the sole payer reward config payer. :) anyways if you decide to unhardcode my wallet here there really isn't much hard feelings in that, do not forget to tip @staccart. I redact literally all of my original greed :) stacc@staccs-MacBook-Air hydra % git add . ; git commit -m "stacc_maybe;
|
Following up:
#10
#14