How the Bridge Works

What is wtJKC?

Wrapped tJunkcoin (wtJKC) is a 1:1 backed ERC-20 token on supported EVM chains. It lets tJunkcoin (tJKC) participate in EVM DeFi, DEXs, and wallets without changing the native tJunkcoin chain.

Deployed contract

Live values are read from the event indexer, not from the RPC — only deployment metadata and the contract's immutable constants come from configuration.

Current Trust Model

tJKC → wtJKC (Deposit)

Deposit tJKC on the tJunkcoin network and receive wtJKC on the EVM chain. After 6 tJKC confirmations, the committee verifies and mints wtJKC to your wallet.

1. 1
   Create a deposit intent.Connect your EVM wallet and enter the amount. The frontend generates OP_RETURN metadata containing your EVM address — this routes wtJKC to your wallet automatically.
2. 2
   Send tJKC to the custody address.Transfer native tJKC to the bridge custody address shown in the UI, and attach the OP_RETURN metadata. You can send from any self-custody wallet.
3. 3
   Auto-detect on-chain.After sending, click "I've Sent" in the bridge UI. The frontend scans the tJunkcoin chain directly for your transaction by matching the OP_RETURN metadata to your EVM address — no manual TXID entry needed.
4. 4
   Wait for 6 tJKC confirmations.The node waits for 6 block confirmations to prevent double-spend and reorg attacks.
5. 5
   Validators verify and sign.Each validator watches the custody address on the tJunkcoin chain directly — detection does not depend on this frontend. Each independently checks: OP_RETURN contains a valid EVM address, amount ≥ 2 tJKC, TXID not previously processed on the bridge contract. They each sign the EIP-712 deposit digest (chainId + bridge address + recipient + amount + TXID) with their FROST shares, producing one threshold signature.
6. 6
   wtJKC minted on EVM.Once the MPC validator committee reaches threshold consensus, a validator calls registerDepositClaim()with the committee's joint MPC signature to register the deposit on-chain. You then call claimDeposit() to mintwtJKC to your wallet minus the fee (user pays EVM gas). The daily mint limit is checked at registration time.

wtJKC → tJKC (Withdrawal)

Burn your wtJKC on the EVM chain and receive native tJKC to your tJunkcoin wallet. An elected leader builds the tJKC UTXO transaction and commits to its exact fingerprint; the other validators rebuild it deterministically, verify it, and only then co-sign.

1. 1
   Approve and initiate.Approve the bridge contract to spend your wtJKC, then call initiateWithdrawal(amount, jkcAddress, maxFeeBps). The maxFeeBps parameter is a slippage guard — the call reverts if the current fee is higher than your specified maximum. Your wtJKC is burned (net amount) and the fee is retained by the bridge.
2. 2
   On-chain event emitted.The contract emits WithdrawalInitiated with your tJKC destination address and net amount after fee. The fee is fixed at the moment of initiation — it cannot change later even if the owner updates feeBps.
3. 3
   A leader validator is deterministically elected.One validator is deterministically elected leader for your withdrawal (rotating every timeout, anchored to the EVM block timestamp so all validators agree on the schedule). The leader builds the deterministic tJKC payout transaction from the custody UTXO set, and records its fingerprint in a persistent sign-once registry to prevent double-signing.
4. 4
   Validators verify and threshold-sign via FROST MPC.Each validator in the round's committee re-verifies the proposal against on-chain data: the WithdrawalInitiated event (destination + amounts), every input UTXO (owned by custody and still unspent), and every output (your address, exact net amount, change back to custody). Once verified and sign-once is asserted, the committee participates in the off-chain FROST MPC signing round.
5. 5
   tJKC arrives in your wallet.Once FROST MPC threshold signing completes, the transaction is broadcast to the tJunkcoinnetwork. You receive native tJKC minus a small tJKCnetwork fee. The payout embeds your withdrawal's EVM transaction hash as an OP_RETURN output — a public, verifiable link between the burn on the EVM chain and the payout on the tJunkcoin chain.
6. 6
   The withdrawal is closed on-chain.The committee signs the EIP-712 WithdrawalConfirmed digest carrying the tJKCtransaction ID and submits confirmWithdrawal(). The contract marks your withdrawal completed and permanently records the tJKC TXID — the same TXID can never close two withdrawals.

Smart Contract Safeguards

The following protections are enforced by the smart contract — they cannot be overridden by the validators or the owner.

• Replay protection. processedTxids permanently records every completed tJKC deposit, and processedJkcTxids records every tJKC payout TXID — the same transaction can never mint twice or close two withdrawals. Resubmitting reverts with AlreadyProcessed.
• Payout fingerprint gate. Before any signature exists, the leader commits to the exact tJKC transaction fingerprint and every co-signer rebuilds it deterministically from on-chain state. A co-signer refuses to sign anything that does not match — a node that lost all local state still cannot be tricked into signing a competing payout. The gate holds no funds and reads its committee from the bridge, so rotating validators on the bridge applies everywhere at once.
• EIP-712 structured signatures. Each validator signature commits to the exact chain ID, bridge address, recipient, amount, and tJKC TXID using typed data signing. A signature from one chain or contract is useless on another.
• Duplicate signer prevention. A single validator cannot submit two copies of their own signature to meet the threshold — the contract checks for duplicate signers in each call.
• Daily mint rate limit. A configurable maxDailyMint cap (5M wtJKC/day by default) limits how much can be minted per 24-hour window. Even if all 3 validator keys were compromised, an attacker could only mint up to this limit per day, giving the team time to pause the bridge and respond.
• Reentrancy guard. registerDepositClaim(), claimDeposit(), and refundFailedWithdrawal() use ReentrancyGuard. State is always updated before external token transfers (CEI pattern).
• Pause / emergency stop. The owner can pause all deposits and withdrawals instantly. If paused for more than 7 days with no owner action, anyone can trigger an emergency unpause to prevent the contract being frozen forever.
• Fee cap. The bridge fee cannot exceed 1% (100 bps) — hardcoded in the contract. The owner cannot change this cap.
• Minimum deposit. Transactions below 2 tJKC / 2 wtJKC are rejected to prevent dust spam.
• Ownership protection. Ownership transfer requires two steps (propose + accept). renounceOwnership() is permanently disabled — the contract cannot be made ownerless accidentally.
• Fee stored at initiation. The withdrawal fee is set at the moment you call initiateWithdrawal(). A later fee change by the owner does not affect pending withdrawals.

Risks & Honest Limitations

• Validator collusion (Phase 1 risk). All 3 validator nodes are controlled by the same team. If the team colluded or was coerced, 2 of the 3 keys could mint wtJKCbeyond users' deposits. The daily rate limit reduces this to a maximum of maxDailyMint wtJKC per day. This risk is addressed in Phase 2 with independent validator operators.
• tJKC custody key compromise. The tJunkcoin UTXO custody address is a Taproot P2TR address protected by FROST threshold MPC. Multiple independent key shares are required to produce any valid signature. Mitigation: key shares are encrypted at rest with Argon2id + AES-256-GCM and stored on isolated validator hosts.
• Validator liveness. If all 3 nodes go offline, new deposits and withdrawals stall. Your funds are never at risk — wtJKC in the contract is safe, and you can cancel a pending withdrawal after 7 days. Service resumes when nodes come back online.
• tJunkcoin reorg. The 70-confirmation requirement makes a successful reorg attack on a processed deposit extremely unlikely (~70× harder than a 1-confirmation attack).
• Frontend trust. The frontend is a convenience layer, not a security layer. A compromised or replaced frontend could show a wrong custody address. Always verify the custody address against the official source before sending large amounts.
• Wrong tJKC address. tJunkcoin UTXO transactions are irreversible. If you enter an incorrect destination address during withdrawal, the funds cannot be recovered. Triple-check before confirming.
• Supply cap. The bridge cannot mint more than 54,000,000 wtJKC total. Daily mint rate limits provide additional protection. Withdrawals (wtJKC → tJKC) burn tokens, reducing circulating supply.

Fees

A 0.50% bridge fee is charged on both deposits and withdrawals. The fee is deducted from the transferred amount — you always receive slightly less than you send. Fees accumulate as wtJKC inside the bridge contract and are periodically withdrawn by the owner to fund operations.

The fee is capped at 1% maximum by the contract — the owner cannot set it higher. The current fee is always visible in the bridge UI before you confirm a transaction.

Minimum transaction size: 2 tJKC / wtJKC. Amounts below this threshold are rejected to prevent spam.

Gas Costs (EVM)

Validators call registerDepositClaim() to register deposits on-chain (they pay a small amount of EVM gas). Users then call claimDeposit() to mint theirwtJKC to their own wallet — users pay their own EVM gas for claiming. A registered claim must be claimed within 30 days, after which it can be re-registered. The 0.50% bridge fee funds bridge operations; no separate gas tank is used.