Bridge

Purpose and Scope

The VoidAI native bridge supports the Bittensor ↔ Ethereum corridor for:

TAO ↔ WTAO
ALPHA (subnet-specific) ↔ WALPHA (same subnet)

BittensorEVM Support

What Changed

We upgraded the bridge backend to improve security, operational reliability, and consistency across environments.

In earlier versions, some bridge actions depended on older wallet-driven internal flows. Those flows are now replaced with a more controlled BittensorEVM handling path for transfers, swaps, and confirmations. This reduces operational risk and makes runtime behavior more predictable.

User Impact

The user-facing workflow is intentionally familiar: you can still bridge, transfer, and swap assets as before.

The main difference is behind the scenes. These operations now run on stronger backend orchestration that is easier to monitor and maintain, and safer to operate over time.

Reliability Improvements

Swaps and confirmations now follow a clearer internal sequence, which improves validation and completion reliability.
Environment handling is more consistent across development, staging, and production.
Legacy internal code paths that are no longer required were removed, reducing maintenance overhead and complexity.

One-Line Summary

This update makes the bridge safer and more dependable by replacing older background wallet handling with a cleaner BittensorEVM system for transfers, swaps, and confirmations.

Supported Assets and Routes

Source Chain	Destination Chain	Asset Path
Bittensor	Ethereum	`TAO -> WTAO`
Ethereum	Bittensor	`WTAO -> TAO`
Bittensor	Ethereum	`ALPHA(subnet X) -> WALPHA(subnet X)`
Ethereum	Bittensor	`WALPHA(subnet X) -> ALPHA(subnet X)`

Subnet-specific ALPHA assets are not interchangeable across subnet IDs.

End-to-End Flow

Bittensor -> Ethereum

User submits bridge request with destination Ethereum address.
User signs on Bittensor and source assets are locked in bridge custody.
Proof is generated and relayed to destination execution.
Wrapped asset (WTAO or WALPHA) is minted on Ethereum.
Transaction status is marked complete after destination confirmation.

Ethereum -> Bittensor (Redemption)

User submits redemption request with destination Bittensor address.
User approves and signs burn transaction on Ethereum.
Wrapped asset is burned on Ethereum.
Burn proof is verified and relayed to Bittensor.
Native asset is released to the destination Bittensor address.
Transaction status is marked complete after destination confirmation.

Fee Model

Bridge transactions can include:

Platform Fee: VoidAI service fee.
Source Gas: Execution fee paid on the source chain.
Destination Execution Cost: Chain execution cost on destination settlement.

For current rates and token-specific rules, see Fee Structure.

Timing and Finality

Typical completion window: 5-15 minutes.
Actual time depends on source/destination congestion and confirmation thresholds.
A transfer is final only after destination settlement is confirmed.

Transaction Status Lifecycle

Status	Meaning	User Action
`INITIATED`	Request created	Wait for source-chain signature/submit
`PENDING_SOURCE`	Waiting source-chain confirmation	Monitor wallet and explorer
`PROCESSING`	Proof verification and relay in progress	No action needed
`PENDING_DESTINATION`	Destination settlement in progress	Wait for destination confirmation
`COMPLETED`	Destination settlement succeeded	Verify received balance
`FAILED`	Terminal error occurred	Retry with new request or contact support

Security and Trust Model

Source and destination actions are tied to verifiable on-chain events.
Settlement requires proof validation before mint/release.
User wallets keep signing authority; private keys are never held by docs infrastructure.

Troubleshooting

Confirm source/destination networks before signing.
Verify recipient address format for the destination chain.
Keep transaction hash/identifier for support escalation.
If status remains non-terminal beyond expected window, contact support with transaction ID.