DeFCoN Migration Portal PAC Protocol to DeFCoN · fixed-ratio · no-login flow

PAC Protocol migration

Secure fixed-ratio migration to DeFCoN

Fixed 1:10 migration ratio from PAC Protocol to DeFCoN (1 PAC = 0.1 DFCN).

This portal enables a secure, fixed-ratio migration of PAC to DeFCoN following the network transition. Generate a unique PAC deposit address, send PAC, and receive DeFCoN automatically after the required confirmations.

Start Migration Read Documentation

No account or login required. Test with a small amount first if this is your first migration.

Fixed ratio High-confirmation security On-chain verifiable Reorg protection

Start Migration

No login or account is required. Enter your DeFCoN payout address to generate a unique PAC deposit address.

You send PAC Protocol (PAC)
1,000,000 PAC
You receive DeFCoN (DFCN)
100,000 DFCN

The system returns a unique PAC deposit address, fixed ratio, minimum deposit, and expiration timestamp.

Fixed Ratio

1,000,000 PAC → 100,000 DFCN

Transparent fixed-ratio migration. No market pricing or slippage.

High Confirmation Security

100 confirmations

PAC deposits require deep confirmations before payout is released.

Transparent Process

On-chain verifiable

Deposits and payouts can be verified using transaction IDs and explorers.

How It Works

Simple four-step migration flow with explicit state tracking and confirmation gating.

  1. 1

    Generate a unique PAC address

    Enter your DeFCoN payout address and create a migration request.

  2. 2

    Send PAC

    Send PAC to the generated deposit address for this request only.

  3. 3

    Wait for confirmations

    The service waits for the required confirmation threshold before payout.

  4. 4

    Receive DFCN automatically

    The payout worker sends DeFCoN to your provided address once eligible.

Migration Details

Operational parameters are fixed and monitored. Some values are shown live below.

Migration Parameters

  • Migration ratio1 PAC = 0.1 DFCN (1:10)
  • Minimum depositShown after request creation
  • Confirmation requirement100 blocks
  • Payout modeAutomatic fixed-ratio payout

Operational Controls

  • Hot wallet liquidityMonitored continuously
  • Daily payout limitEnforced by backend policy
  • Reorg handlingFail-closed freeze protection
  • Wallet unlockOnly around sendtoaddress

Live System Status

Public operational status panel. Exact hot-wallet balance is not exposed; only safe status bands are shown.

Checking... Updated every 15 seconds
Last updated -
-
-
UNKNOWN
-

Swap State Machine

The backend uses explicit state transitions, blocking invalid moves and preventing duplicate payouts after restarts.

  1. CREATEDRequest created
  2. DEPOSIT_SEENDeposit observed
  3. CONFIRMINGWaiting for confirmations
  4. CONFIRMEDEligible for payout
  5. PAIDDFCN payout broadcast
REORG_DETECTED

If blockhash changes or confirmations regress, payout flow is frozen automatically until the chain is stable.

Dedicated full nodes

PAC and DeFCoN are monitored via local full-node RPC, not a third-party explorer API.

Reorg detection

Blockhash changes and confirmation drops trigger reorg detection and payout freeze protection.

Hot/cold separation

Operational payouts come from a monitored hot wallet, while treasury storage should remain in cold wallets.

Daily payout limits

The backend enforces daily payout caps and liquidity gates before sending any DeFCoN payout.

RPC localhost only

Node RPC endpoints are restricted to 127.0.0.1 and are not intended to be publicly reachable.

Wallet unlock window

The DeFCoN wallet is unlocked only during payout transmission and locked again immediately after.

FAQ

What happens after the migration period ends?

Requests created after the service is paused or closed may be rejected. Follow official project communication for the final migration deadline and post-period process.

Can I send multiple PAC transactions to the same migration request?

The backend can detect multiple deposits, but you should follow the documented policy for your migration campaign. Using a fresh request per transfer is the safest approach.

What if my transaction is delayed?

The payout waits for the configured confirmation requirement. If the network is slow or paused due to a safety event, payout may be delayed until conditions recover.

Is this custodial?

This is a migration service, not a trading exchange. Funds sent to the migration deposit address are processed for fixed-ratio migration according to the published rules.

What if I send below the minimum deposit or after expiration?

Always verify the minimum deposit and expiration before sending. Handling of under-minimum or late deposits depends on the migration policy and may require manual support.