01 · The challenge
What needed solving
The client needed a Solana on-chain program that performed standard SPL Token operations — transfer, mint, burn, authority changes — on behalf of users, but driven by program-derived signers rather than direct user signatures. Calling the SPL Token program correctly from inside another program (the Cross-Program Invocation pattern) is the part that bites every Solana project on day one.
02 · Our approach
How we framed the work
We started with a discovery sprint to map the user journey, business goals and real constraints. From there we wrote a fixed-scope plan: clear milestones, weekly review gates on a staging URL, and a written exit criterion for every phase. The blockchain space rewards teams that ship — not teams that plan — so we biased the engagement towards working software from week two onward.
03 · The solution
What we built
We built an Anchor (Rust) program with four instructions — proxy_transfer, proxy_mint_to, proxy_burn and proxy_set_authority — each backed by a typed Anchor account struct that bundles the signer, the relevant mint or token account, and the SPL Token program. Every instruction converts its accounts into a CpiContext and invokes the SPL Token program, with a clean AuthorityType enum covering MintTokens, FreezeAccount, AccountOwner and CloseAccount. Mocha + Anchor TS tests cover every instruction path against a local validator. The result is a drop-in pattern any downstream program (vault, escrow, managed treasury) can copy.
04 · The results
What changed for the client.
Reference pattern for SPL Token CPI — every authority path and account layout typed end-to-end
Mocha test suite runs against local validator — instructions exercised before mainnet
AuthorityType enum cleanly maps the four SPL authority modes to Anchor instruction handlers
Tech stack
Want a similar outcome for your business? We'd love to hear about it.