> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pfbridge.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# BLS Auth

> BLS-only authentication replaces the pre-auth relayer. Both parties sign the order once; one aggregated signature gates both unlocks.

<Note>
  🔨 **Planned for T1.** Replaces the pre-authorization relayer with
  on-chain BLS aggregate verification and lands several defensive
  contract changes in the same cutover.
</Note>

Phase 2 retires the manager-signing relayer — the largest live
trust assumption in Phase 1. The two counterparties on a trade
become the only signers gating their own settlement.

## Architecture diagram

<img src="https://mintcdn.com/proofbridge/Q904cguIxUfnPlot/architecture/_diagrams/phase-2-bls-auth.png?fit=max&auto=format&n=Q904cguIxUfnPlot&q=85&s=20b476208b4b121cc89d032fa92007f2" alt="Phase 2 architecture — BLS auth, pre-auth retired" width="1800" height="668" data-path="architecture/_diagrams/phase-2-bls-auth.png" />

## Delta from Phase 1

What changes vs [Phase 1](/architecture/current-state):

<CardGroup cols={2}>
  <Card title="Pre-auth gone" icon="circle-xmark">
    `_consumeAuth`, `managers[]`, `requestTokens[]`, and the
    `signature / authToken / timeToExpire` parameters are removed
    from every state-changing entry point on both `AdManager` and
    `OrderPortal`.
  </Card>

  <Card title="BLS verification on `unlock`" icon="key">
    Each `unlock` does one native pairing check
    (`env.crypto().bls12_381().pairing_check` on Soroban,
    `BLS12_PAIRING_CHECK` precompile on EVM) against the aggregated
    maker + bridger signature.
  </Card>

  <Card title="`BLSKeyRegistry`" icon="address-book">
    New contract. Maps each wallet to a registered BLS public key,
    with Proof-of-Possession enforced at registration to prevent
    rogue-key attacks. Single key per address in T1; a multi-key
    upgrade lands in Phase 3.
  </Card>

  <Card title="Route commitment per ad" icon="lock">
    Every ad pins its `committed_order_token` at creation time.
    Future admin route changes don't reach into existing ads —
    closes the admin-compromise → fake-token-route drain vector.
  </Card>

  <Card title="Side-bound MMR leaves" icon="layer-group">
    `MerkleManager` leaves are now `poseidon2(orderHash, sideFlag)`,
    closing the X-1 attack surface where a local-chain leaf could
    satisfy a counterpart-chain proof.
  </Card>

  <Card title="Pause + 2-step admin" icon="pause">
    `whenNotPaused` guard on every state-changing entry point.
    Two-step admin transfer (`AccessControlDefaultAdminRules` on
    EVM, `pending_admin / accept_admin` on Soroban) eliminates the
    wrong-address transfer footgun.
  </Card>
</CardGroup>

## What gets signed

Both parties sign the same 15-field EIP-712 `OrderData` struct
introduced in Phase 1. The orderHash is byte-identical on both
chains by construction, so one aggregated signature verifies on
either side:

```text theme={null}
authMessage  = orderHash                     // EIP-712 digest of the OrderData struct
sigAggregate = sigMaker + sigBridger         // G1 point addition
pkAggregate  = pkMaker  + pkBridger          // G2 point addition

// Pairing check on each chain's `unlock`:
e(sigAggregate, G2_generator) == e(H_to_G1(orderHash), pkAggregate)
```

Total signatures per trade: **2** (one per user). Users sign once;
the aggregate is reused at both `AdManager.unlock` and
`OrderPortal.unlock`.

## Curve choices

ProofBridge uses two curves, each chosen for its job:

| Concern                                           | Curve     | Why                                                                                                                        |
| ------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------- |
| BLS signature aggregation + on-chain verification | BLS12-381 | Native Stellar host functions (CAP-0059), native EVM precompile (EIP-2537), 128-bit security, matches the Noir BLS library |
| Deposit ZK proof (MMR inclusion + nullifier)      | BN254     | UltraHonk native; auto-generated verifier (Soroban + Solidity) already deployed in Phase 1                                 |

In T1 the two curves don't compose at the contract layer. The
deposit proof and the BLS verification are independent gates on
`unlock`. A combined proof is a long-term optimization tracked in
[Phase 5](/architecture/phase-5-followups).

T1 also ships a standalone Noir BLS auth circuit as a building
block. It isn't on the unlock path itself, but later phases use
it for agent attestations and dispute evidence.

## What ships next

<Card title="Phase 3: AI Agents & Dispute Resolution" icon="arrow-right" href="/architecture/phase-3-agents-disputes">
  Soroban custom-account contracts let makers deploy AI agents
  under scoped policies. Order `deadline` field is added; cancel
  and arbiter-driven dispute paths handle stuck or contested
  orders. The `BLSKeyRegistry` upgrades to multi-slot for
  single-tx agent rotation.
</Card>