Why Verify Events?
On StarkNet, a transaction can have status “SUCCEEDED” while the token transfer inside it fails silently. This happens because:- The Chipi paymaster wraps your calls in
execute_from_outside_v2 - The forwarder contract executes the wrapped call
- If the inner call fails (e.g., insufficient balance), the forwarder may still succeed
- The transaction is marked “SUCCEEDED” on explorers
Checking Transfer Events via RPC
After a transfer, query the transaction receipt for Transfer events from the token contract:Checking Balance Before and After
For additional certainty, query the token balance before and after the transfer:Using getTransactionStatus for Polling
The SDK’sgetTransactionStatus method polls the chain for finality, but it only checks transaction inclusion — not whether the inner transfer succeeded:
getTransactionStatus for finality, then verify Transfer events for correctness.
Common Pitfalls
| Pitfall | What Happens | How to Detect |
|---|---|---|
| Insufficient token balance | Tx succeeds, no Transfer event | Check events in receipt |
| Wrong recipient address | Tokens sent to wrong address | Verify keys[2] matches expected recipient |
| Amount overflow/underflow | Transfer of 0 tokens | Check data[0] and data[1] are non-zero |
| Tx status “SUCCEEDED” but transfer failed | Forwarder catches inner error | Always check Transfer events |
Related
- getTransactionStatus - Poll transaction finality
- transfer - Send tokens
