Conversation
| // cursor positions | ||
| msg!("role: {:?}", role.unwrap().get_all_actions()); | ||
| let (swig_header, swig_roles) = unsafe { swig_account_data.split_at_mut_unchecked(Swig::LEN) }; | ||
| let swig = unsafe { Swig::load_mut_unchecked(swig_header)? }; |
There was a problem hiding this comment.
you are doing double work, loading with roles and also doing the load_mut, you can consolidate to one.
There was a problem hiding this comment.
you're so right here thank you for this callout
| } | ||
|
|
||
| // Authentication and permission checking | ||
| let swig_with_roles = SwigWithRoles::from_bytes(&swig_account_data).unwrap(); |
There was a problem hiding this comment.
SwigWithRoles is meant to be a helper for off chain usage, its slow on chain remove please see next comments
|
|
||
| // Get existing authorization locks for this role using a smaller array to avoid | ||
| // stack overflow | ||
| const MAX_LOCKS: usize = 10; // Smaller bound to prevent stack overflow |
There was a problem hiding this comment.
man I would love to be able to increase this. do we have any data to suggest a user may only need 10 concurrent locks. looking at my credit card statement it would be very rare, but imagining businesses would need more.
There was a problem hiding this comment.
Honestly I just set it arbitrarily here. We can crank this up, maybe even not have a limit? I think it's more sensible to have a limit but can also experiment to see what seems better
| )?; | ||
|
|
||
| // Re-borrow data after authentication | ||
| let swig_account_data = unsafe { ctx.accounts.swig.borrow_mut_data_unchecked() }; |
There was a problem hiding this comment.
This looks like its following the SwigBuilder pattern like in add authority
| let lock_slice = &mut swig_account_data[new_lock_offset..new_lock_offset + new_lock_size]; | ||
| let new_lock = unsafe { &mut *(lock_slice.as_mut_ptr() as *mut AuthorizationLock) }; | ||
|
|
||
| // Initialize the lock fields directly in memory |
There was a problem hiding this comment.
maybe we can encapsulate this in swig builder
2 participants
More optimal implementation of AuthorizationLock concept.
TokenLimit,RecurringTokenLimit,SolLimit,RecurringSolLimiton the role that is adding the AuthorizationLock. Meaning, a role can't lock up more tokens than what they're allowed access to.