Appearance
Security and Limitations
The Zink Bridge is designed as a practical, operator-managed corridor between Solana and Zink. That makes it useful, but it also means the trust model is very different from a proof-verified bridge.
Trust model
Users trust three things simultaneously:
- configured bridge authorities to observe and relay events honestly
- operator infrastructure to stay online and process the protocol phases
- key custody around authority signers and governance authorities
There is no light client, validity proof, or external consensus proof imported from one chain to the other.
Bridge-specific
This bridge is authority-mediated. If you need a bridge whose safety comes from cryptographic verification of remote consensus rather than operator trust, this is not that design.
What the protocol does protect
Even within an operator-trust model, the protocol still has meaningful on-chain structure:
- deposits and withdrawals are tracked explicitly in on-chain accounts
- authority actions are recorded as votes, not invisible off-chain state
- threshold agreement is required for finalization
- cleanup/refund behavior is tied to finalized source-side state
- token-pair limits and freeze controls exist at the bridge configuration layer
So the bridge is not just a centralized database update. It is still an on-chain protocol — just one whose liveness and safety depend on trusted authorities.
Primary limitations
Operator-dependent liveness
If the server/crank infrastructure is down or authorities stop acting, transfers stall.
Route-limited scope
Only configured token pairs are supported. This is not a permissionless arbitrary-asset bridge.
Multi-phase completion
Users may see partial progress:
- deposit complete
- destination-side voting in progress
- withdrawal available
- source-side finalization pending
- cleanup pending
This is normal for the protocol, but it makes UX and incident handling more complex.
Governance sensitivity
Bridge configuration changes are powerful. Adjusting token pairs, thresholds, or authorities can materially affect safety and recovery behavior.
Key management risk
Authority signers are high-value assets.
If an authority key is compromised, an attacker may be able to submit fraudulent acknowledgements or interfere with finalization behavior depending on the threshold and authority set.
That means operators should:
- isolate authority keys per deployment
- avoid baking keys into images
- mount keys from a secure secret store
- minimize blast radius per signer/service
- audit who can rotate or replace authority-related configuration
Zink recommendation
The current one-service-per-authority Cloud Run shape is not just operationally simple — it also constrains blast radius and makes signer behavior easier to reason about during incidents.
Economic and token-pair limits
Each token pair can carry:
- import limits
- export limits
- freeze state
- limit authority
- freeze authority
These controls are useful, but they also mean user-facing availability can change for operational reasons even when both chains are healthy.
UX limitations integrators should surface
If you build a frontend or operational dashboard on top of the bridge, surface at least:
- current protocol phase
- whether authority acknowledgement is still pending
- whether withdrawal is executable yet
- whether cleanup/refund has completed
- whether the route is frozen or over limit
Integrators who hide these realities create support tickets for themselves.
Scope boundaries
This bridge is purpose-built for explicitly configured Solana ↔ Zink routes.
Do not present it as:
- a general-purpose cross-chain protocol
- a permissionless relay network
- a proof-verified bridge
- an arbitrary-token bridge