TrueCurrent settles RFQ trades through Injective’s exchange module. To make settlement atomic, taker and maker wallets grant the RFQ contract narrow authz permissions before trading.
The grants are one-time setup per wallet. They are scoped to the current RFQ contract address, limited to specific message types, and revocable at any time.
Required grants
MsgWithdraw appears in some contract notes as a canonical grant, but the current working setup intentionally omits it. The active settlement path does not exercise it, and granting unused permissions increases attack surface. If a future contract path requires a new message type, add it only after verifying the deployed contract and runbook.
Grant all testnet permissions
The script below grants the working testnet set for one maker wallet and one taker wallet. The shell wrapper loads .env before running the Python script so the private keys are present.
Submit grant transactions sequentially. Parallel grant broadcasts commonly fail with account sequence mismatch errors.
Verify grants
Use the Injective LCD to confirm grants before running settlement tests.
Expected result:
- Maker grants include
MsgPrivilegedExecuteContract and MsgSend.
- Taker grants include
MsgPrivilegedExecuteContract, MsgBatchUpdateOrders, and MsgSend.
- The
grantee is the current RFQ contract address.
Direct GenericAuthorization
If your Injective SDK helper forces an expiration or uses a specialized authorization, build the grant manually as GenericAuthorization.
Use gas heuristics for grant broadcasts. Simulation can under-estimate grant transaction gas and produce avoidable failures.
Revoking grants
Revoking MsgPrivilegedExecuteContract is the fastest kill switch. It prevents future contract-initiated settlements for that wallet.
Revocation does not close open positions. It only prevents future TrueCurrent contract settlement actions for that wallet.
Security checklist
- Use dedicated maker and taker wallets.
- Grant only the message types listed above.
- Grant only to the current RFQ contract address.
- Re-verify grants after contract upgrades.
- Keep a revocation path ready before going live.
- Monitor grant presence at bot startup.
- Re-run grant setup if settlement fails with
unauthorized or authorization not found.
For the broader trust model, see Authorization model.