TL;DR
OP-PIP-87 already empowers the Pythian Council to repatriate DAO-owned fees from non-Solana chains. This discussion is about operationalizing that mandate: defining the infrastructure, withdrawal criteria, and reporting standards. There is approximately $350k sitting in Core and Entropy contracts across 19 chains with balances >$2k. Time to put a system in place.
Background
Quick refresher: OP-PIP-87 Section 3 already established:
“It will be the responsibility of the Pythian Council to regularly retrieve funds from Pyth contracts deployed across other chains and repatriate their value to the Pyth DAO Treasury on Solana.”
The rules are already set:
- Max 5% slippage on any transaction
- DAO receives PYTH or USDC only
- PC finds venues for native-to-USDC conversions
What’s missing is the operational playbook. How does the council actually execute this? When does the council trigger withdrawals?
This proposal answers these questions with a detailed set of instructions that reduces the council’s discretion to a minimum. The council acts solely as the executing arm of the DAO, and only because a step-by-step public vote is technically impossible on chain. Executed point by point, its role becomes purely mechanical, comparable to an algorithm, acting exclusively upon and within the instructions of this proposal.
Current Situation
Fees accumulate in Pyth contracts across many chains but sit idle because there’s no established process to retrieve them. Auto-bridging directly to Solana via contract logic isn’t practical: it’s technically complex and would result in wrapped tokens with poor liquidity on Solana.
In my opinion, the solution is PC-controlled multisigs on each chain. Contract upgrades send fees to these multisigs, and the Council handles swaps and bridging manually with proper oversight.
I have only referenced chains that have over $2,000 in accrued onchain fees
- Core Price Feeds
| Chain | Accumulated Fees |
| ------------- | ---------------- |
| Injective EVM | $46,113 |
| Cronos | $21,273 |
| HyperEVM | $13,735 |
| Monad | $10,178 |
| opBNB | $9,578 |
| Base | $6,078 |
| Etherlink | $3,552 |
| Mezo | $2,398 |
| Avalanche | $2,309 |
| Optimism | $2,166 |
| CoreDAO | $2,018 |
| Subtotal | ~$119k |
- Entropy
| Chain | Accumulated Fees |
| -------- | ---------------- |
| Abstract | $97,912 |
| Blast | $79,496 |
| ApeChain | $25,405 |
| Base | $8,441 |
| Monad | $4,348 |
| Soneium | $3,901 |
| HyperEVM | $2,705 |
| Subtotal | ~$222k |
Combined: ~$341k sitting idle (just counting >$2k balances)
Proposed Framework
1. PC Multisigs on EVM Chains
Deploy Safe (Gnosis) multisigs on chains where the council will need to retrieve fees. Safe is the industry standard for on-chain custody and the only multisig solution used for this.
Threshold: 5/8, which mirrors the Pythian Council on Solana (6/9) minus the Ops wallet, which isn’t needed for operations outside of Solana.
If a chain doesn’t have Safe support (or equivalent battle-tested multisig infrastructure), the council can simply delay withdrawing from that chain. No point rushing to retrieve fees if they can’t be custodied safely. Once the chain gets proper multisig support, the council can revisit.
Contract upgrades via OP-PIP would redirect accumulated fees to these PC-controlled multisigs. Once in the multisig, the Council handles bridging without needing per-withdrawal governance votes.
2. When to Withdraw
Two triggers:
| Trigger | Condition | Why |
| --------------- | ----------------------------------------------------------------- | -------------------------------------------------- |
| Chain Risk | Chain announces sunset, shows instability, or is being deprecated | Get the funds out before infrastructure disappears |
| Minimum Balance | ≥$2,000 accumulated | Below this, bridging costs don't make sense |
Recent example: Swellchain sunset, with the chain going offline June 15. We’d want to retrieve any fees before that date.
3. Bridging & Swaps
Following OP-PIP-87 rules:
- ≤5% slippage on all transactions
- Aggregators (Jumper, LI.FI, etc.) for optimal routing
- USDC preferred since it’s cleanest to bridge and has best Solana liquidity (USDC-> PYTH)
- Native tokens only if the wrapped version has decent liquidity on Solana (thinking $200k+ on-chain)
Bridge choice stays flexible, provided that the chosen bridge is not subject to any applicable international sanctions regime.
4. Scope: Repatriation Only
Important clarification: The PC’s role here is strictly repatriation, getting funds from other chains back to the DAO Treasury on Solana as USDC.
Once the USDC lands in the DAO Treasury, the existing treasury management rules kick in (OP-PIP-87: monthly 33% allocation toward PYTH purchases, etc.). The PC doesn’t convert repatriated funds to PYTH directly. That follows the pre-established treasury flow.
Fees on Chain X → PC Multisig → Swap to USDC → Bridge → DAO Treasury (Solana)
↓
Existing OP-PIP-87 rules apply
(33% monthly PYTH purchases, etc.)
5. Batched Contract Upgrades
Rather than one OP-PIP per chain, we’d batch:
- Single proposal covering multiple chains
- Lists all contract addresses and new multisig destinations
- PC posts a reply under the proposal once complete with:
- Transaction hashes
- Amounts retrieved
- Bridge/swap breakdown
- Final USDC deposit to treasury
Keeps governance lightweight while maintaining full transparency.
Multisig Availability
| Chain | Fees | Multisig |
| ------------- | ------ | ---------------------------- |
| Abstract | $98k | Safe ✓ |
| Blast | $79k | Safe (Brahma or self-host) ✓ |
| Injective EVM | $46k | Injective Multisig ✓ |
| ApeChain | $25k | Safe ✓ |
| Cronos | $21k | Safe ✓ |
| HyperEVM | $16.4k | Safe ✓ |
| Base | $14.5k | Safe ✓ |
| Monad | $14.5k | Safe ✓ |
| opBNB | $9.6k | Safe ✓ |
| Avalanche | $2.3k | Safe ✓ |
| Optimism | $2.2k | Safe ✓ |
| CoreDAO | $2k | Safe ✓ |
| Soneium | $4k | Safe ✓ |
| Etherlink | $3.5k | Verifying |
| Mezo | $2.4k | Safe ✓ |
Chains without confirmed multisig support will be deferred until infrastructure is available.
Open Questions
Looking for community input on:
- Native token liquidity threshold: Is $100-200k on-chain liquidity the right bar for accepting wrapped tokens on Solana? Or should the council just default to USDC always?
- $2k minimum: Feels right given bridging costs, but open to arguments for different thresholds.
- Batching cadence: Quarterly batched OP-PIPs? Or as-needed when balances hit thresholds?
- Chain risk indicators: Should the council formalize what “at risk” means? (team announcement, TVL crash, network issues, etc.)
What This Isn’t
This isn’t asking for new authority. OP-PIP-87 already granted the mandate. This is about setting up the operational infrastructure so the PC can actually execute it efficiently, with clear expectations and guidelines from the community. The PC isn’t making treasury allocation decisions here.