The following enhancements could be considered for future iterations of the program:
-
Global Omni Vaults per Mint - Implement shared vault accounts per mint across all escrows rather than individual vaults per escrow per mint. This would reduce account overhead and simplify token management at scale.
-
Block All Token Extensions Option - Add a configuration flag within the blocked extension data to reject all token extensions by default, providing a simpler security posture for escrows that require only standard SPL tokens or vanilla SPL 2022 tokens.
-
Partial Withdrawals - Enable withdrawals of a specified amount rather than requiring full balance withdrawals, allowing for more flexible fund disbursement patterns.
-
TypeScript Client Testing - Develop a comprehensive test suite for the generated TypeScript clients to ensure client-side reliability and validate the end-to-end integration with the on-chain program.
-
Receipt Seed Space Optimization - The current
receipt_seeduses a 32-byteAddresstype. Two alternatives could save space:- Use
u8counter: Change to a simple counter (0-255), saving 31 bytes per receipt. Limits to 256 receipts per depositor/escrow/mint combination, which is acceptable for most use cases. - Single receipt with
deposit_additionalinstruction: Allow users to add to an existing receipt rather than creating new ones. This would require handling complexities arounddeposited_attimestamps (e.g., weighted average, use latest, or track per-deposit).
- Use
-
Two-Step Admin Transfer - The current
UpdateAdmininstruction requires both the current and new admin to sign the same transaction. This is problematic when transferring to/from multisig wallets (e.g., Squads), since both parties must be present in one transaction. A 2-step pattern (ProposeAdmin→AcceptAdmin, with optionalCancelAdminTransferand a timeout) would allow async coordination between parties and is the standard pattern for admin handoffs in production programs.