Bridge Overview

The Zink Bridge is a multi-step, operator-managed bridge between Solana and Zink. It records every transfer as a sequence of on-chain state transitions across two tracker accounts, advanced by weighted authority votes until a configurable threshold is met.

Bridge-specific

The protocol centers on five instructions executed in strict order: deposit, ack_deposit, withdraw, ack_withdraw, and cleanup_deposit. Each instruction mutates tracker state on one chain; the full lifecycle spans both.

What the bridge actually does

A user locks tokens on a source chain. Bridge authorities independently observe that deposit, then vote on the destination chain to create a corresponding withdrawal. Once cumulative authority weight meets the configured threshold, the withdrawal becomes executable. A symmetric acknowledgement then finalizes the deposit on the source chain, and a cleanup step refunds overpaid fees or handles rejections.

That means the bridge is:

on-chain tracked — every deposit and withdrawal lives as an entry inside a DepositTracker or WithdrawTracker account, queryable over standard RPC
authority-mediated — a set of weighted signers must independently observe and vote on cross-chain events before anything finalizes
threshold-finalized — the Bridge account stores a fixed-point U0F64 threshold (0.0–1.0 of total authority weight); finalization requires cumulative vote weight to meet or exceed that value, with fractional requirements rounded up
operationally real — an off-chain server/crank loop is required infrastructure, not a convenience layer; without it, authority votes never happen and transfers stall indefinitely

Upstream-compatible

Both chains expose familiar Solana-style accounts, transactions, RPC, and signing. Integrators interact with the bridge through ordinary Solana instructions — no custom transport or non-standard RPC methods.

Five-step lifecycle

Step	Instruction	Chain	Permission	Key state change
1	`deposit`	Source	User	Creates `DepositEntry` in `Initialized` status; escrows tokens into the token-pair vault
2	`ack_deposit`	Destination	Authority	Creates/updates `WithdrawEntry` in `Voting`; accumulates authority weight toward threshold
3	`withdraw`	Destination	Permissionless	Releases or mints tokens to the destination address once `WithdrawEntry` is `Finalized` with `DepositResult::Confirmed`
4	`ack_withdraw`	Source	Authority	Votes the destination-side result back onto the `DepositEntry`; moves it through `Voting` to `Finalized`
5	`cleanup_deposit`	Source	Permissionless	Refunds excess fees, handles rejected deposits, marks `cleanup_completed` on the entry

This sequence is strict. Step 3 cannot execute before step 2 reaches threshold. Step 5 cannot execute before step 4 reaches threshold. Operate and integrate the bridge as a phased protocol, not as an instant asset swap.

Zink recommendation

When documenting or integrating the bridge, preserve the real instruction names and execution phases. Do not collapse them into a fictional "send/receive" abstraction — operators and users both need the phased model to reason about failures and partial completion.

Core state model

The bridge relies on four on-chain account types:

Account	PDA seeds	Purpose
`Bridge`	`["bridge", chain_id]`	Per-chain-pair configuration: authority set, token pairs, fees, threshold, fee target
`DepositTracker`	`["deposit", bridge]`	Source-side entry list, entry count, `next_finalized_entry` cursor, authority vote map
`WithdrawTracker`	`["withdraw", bridge]`	Destination-side entry list, entry count, cleanup tracker, authority vote map
`AuthProposal`	Keypair-based	Governance proposals for configuration changes (add/remove authorities, add/modify/remove token pairs, change threshold)

See State and Trackers for field-level detail.

Program IDs

Environment	Program ID
Production	`BR1DGEaF3Z3ZN9UouYiRLKbK2WWgFmHwUwcZKJfmJSSP`
Dev / Testnet	`BSMryvZi4HYn6ASXrY3xcDwo1sG6pXigaakQMgPMv6gT`
Localnet	`5Bw3DZTvadDWGJMg7urmZJQwhYoU87fRKcLQ2umT983n`

The static authority address used for program-level operations is AUTHvT1tzXUniLNNPLsQb2wf1fasfXvxi3yDKVfLKbot.

Quick facts

Parameter	Value
Zink Testnet RPC	`https://testnet-rpc.z.ink`
Source chain ID (Atlasnet)	`1001`
Destination chain ID (Zink Testnet)	`1002`
Bridge program (Devnet)	`BSMryvZi4HYn6ASXrY3xcDwo1sG6pXigaakQMgPMv6gT`

Bridge Overview ​

What the bridge actually does ​

Five-step lifecycle ​

Core state model ​

Program IDs ​

Quick facts ​

What this section covers ​