PD-177 - Wallet Ethereum operationnel et gestion contractuelle des cles privees¶

1. Objectif¶

Definir les exigences contractuelles, testables et non ambigues pour rendre operationnel le wallet Ethereum de ProbatioVault dans l'epic BLOCKCHAIN (PD-187), en coherence avec PD-52, PD-55 et PD-245.

Le resultat attendu de PD-177 est un dispositif de wallet permettant: - d'emettre des transactions d'ancrage probatoire; - de proteger l'identite blockchain et les cles privees associees; - d'assurer la tracabilite probatoire complete de chaque ancrage; - de maintenir la continuite d'exploitation sous contraintes de securite et de souverainete.

2. Perimetre / Hors perimetre¶

Perimetre PD-177: - Activation contractuelle d'un unique wallet Ethereum actif pour l'ancrage probatoire. - Utilisation du mode de custody actif defini par PD-52 (S2 uniquement) sans rupture d'interface. - Signature et emission de transactions natives compatibles Ethereum L1/L2 ciblees par la configuration existante (Polygon, Arbitrum), avec politique de confirmations contractualisee par reseau (chainId -> confirmations + timeout). - Journalisation, lien probatoire et auditabilite des transactions d'ancrage. - Exigences de gestion du cycle de vie de la cle (initialisation, usage, incident, rotation planifiee, reprise).

Hors perimetre PD-177: - Multi-wallet simultane. - Support Tezos (PD-58). - Interactions DEX/DeFi. - Gestion de tokens ERC-20. - Trading, transfert fonctionnel de fonds hors ancrage. - Conception cryptographique post-quantique et garantie de perennite a 50 ans (hors perimetre: non testable dans la story). - Activation des modes S1 et S3 (hors perimetre tant que non mandates).

3. Definitions¶

Wallet officiel: identite blockchain unique utilisee pour les transactions d'ancrage probatoire ProbatioVault.
Custody mode: mode de gestion de cle expose par CustodyStrategy (S1|S2|S3). Pour PD-177, seul S2 est autorise.
Transaction d'ancrage: transaction blockchain emise pour publier un Merkle root probatoire via le smart contract de reference PD-53 (MerkleAnchorContract.sol).
Merkle root ancre: valeur racine issue du lot probatoire interne et publiee on-chain.
Preuve composite: artefact probatoire incluant les metadonnees blockchain (incluant le champ blockchain).
Registre append-only: registre interne non destructif base sur la persistance existante (PD-55 anchor_events ou equivalent), avec protection applicative interdisant UPDATE/DELETE par le service PD-177. La protection WORM au niveau base est hors perimetre PD-177.
Confirmation reseau: etat confirmant l'inclusion de la transaction dans un bloc selon la politique de confirmations applicable. Politique contractualisee PD-177: chainId=137 (Polygon) -> 12 confirmations, timeout=900s; chainId=42161 (Arbitrum) -> 30 confirmations, timeout=900s. En cas de timeout, le statut est non-finalise avec code d'erreur explicite.
Horodatage: format obligatoire ISO 8601 UTC avec millisecondes (exemple: 2026-02-23T14:30:00.000Z).
Incident de custody: evenement affectant la disponibilite, l'integrite ou le controle de la cle utilisee par le wallet.

4. Invariants (non negociables)¶

Identite et perimetre fonctionnel¶

INV-177-01: Un seul wallet Ethereum est actif a un instant donne pour l'ancrage probatoire.
INV-177-02: Toute transaction emise par le service d'ancrage doit etre associee au wallet officiel actif au moment de l'emission.
INV-177-03: Le wallet est utilise exclusivement pour des transactions d'ancrage probatoire (aucun usage metier tiers).
INV-177-04: Le champ blockchain de la preuve composite doit etre renseigne et appartenir a l'enum ethereum_l2 | tezos; pour PD-177, seules les preuves ethereum_l2 sont produites. Si blockchain=tezos est recu en entree d'un service PD-177, la valeur est ignoree ou passee en passthrough sans emission de transaction d'ancrage PD-177.

Compatibilite architecture existante¶

INV-177-05: L'integration respecte strictement l'interface CustodyStrategy existante (initialize, getAddress, signMessage, signTransaction, validateCapability).
INV-177-06: Le worker d'ancrage ne signe jamais directement; la signature est deleguee a la couche wallet/custody via les services existants.
INV-177-07: Le mode de custody autorise en production pour PD-177 est S2 exclusivement; S1 et S3 restent inactifs.

Securite des cles et des secrets¶

INV-177-08: La cle privee du wallet ne doit jamais etre exportable en clair vers les canaux de sortie applicatifs suivants: logs applicatifs, traces d'erreur (y compris stack traces), enregistrements de persistance, reponses API, variables d'environnement en runtime. Les core dumps et la memoire processus sont hors perimetre PD-177 (niveau infrastructure).
INV-177-09: Toute tentative de fuite de secret detectee doit produire un echec explicite fail-closed et tracer un evenement d'incident securite; le mecanisme doit intercepter et bloquer l'emission avant ecriture sur un canal de sortie (logs, traces, persistance, reponse API).
INV-177-10: Une compromission d'un serveur applicatif ne doit pas permettre, a elle seule, la signature arbitraire de transactions sans controle custody valide. Modele de menace PD-177: compromission = execution de code arbitraire dans le contexte Node.js applicatif, sans acces aux credentials custody (tokens IAM, cles API KMS).
INV-177-11: Les identifiants aleatoires techniques introduits par PD-177 doivent etre generes via crypto.randomUUID(); cet invariant s'applique au code introduit par PD-177 et non au code existant modifie marginalement.
INV-177-12: Toute cle ephemere de test introduite dans le cadre PD-177 doit respecter le prefixe pv-test-*.

Tracabilite, audit et preuve¶

INV-177-13: Chaque transaction d'ancrage doit etre journalisee avec au minimum: identifiant d'ancrage interne, Merkle root, adresse emettrice (signer_address), chainId, tx_hash, horodatage d'emission (format ISO 8601 UTC avec millisecondes), etat de confirmation. Si signer_address n'existe pas dans le modele de persistance, PD-177 DOIT enrichir ce modele.
INV-177-14: Chaque transaction d'ancrage doit etre reliee de maniere deterministe a une entree du registre append-only.
INV-177-15: Un tiers auditeur doit pouvoir reconstruire la chaine de preuve entre Merkle root interne et transaction confirmee a partir des artefacts conserves.

Disponibilite et resilience operationnelle¶

INV-177-16: Un ancrage ne peut pas etre marque "finalise" sans confirmation reseau positive ou statut d'abandon explicite conforme aux codes d'erreur. La confirmation reseau applique strictement la politique par reseau contractualisee (137 -> 12 confirmations/900s, 42161 -> 30 confirmations/900s); au-dela du timeout, le statut reste non-finalise.
INV-177-17: En cas de fonds insuffisants, de plafond gas depasse ou indisponibilite RPC, l'ancrage doit echouer de facon explicite et tracable (pas d'echec silencieux).
INV-177-18: Une procedure documentee de reprise de controle du wallet doit exister et etre testee en exercice. Le resultat est consigne, horodate et auditable.
INV-177-19: Toute rotation de cle planifiee doit preserver l'auditabilite historique des preuves signees avant rotation.

Contraintes de conformite process¶

INV-177-20: Toute evolution du schema de persistance introduite par PD-177 doit etre validee localement avant integration (lecon PD-55 sur indexes partiels PostgreSQL).
INV-177-21: Toute interaction BullMQ introduite/majoree par PD-177 doit eviter les APIs depreciees (getRepeatableJobs, removeRepeatableByKey) et respecter les APIs non depreciees.

5. Flux nominaux¶

FN-177-01 - Initialisation du wallet officiel¶

Le systeme charge la configuration custody et valide que le mode actif est autorise.
Le service wallet recupere l'adresse officielle du wallet actif.
L'adresse officielle est enregistree dans la documentation operative et les metadonnees de service.
Le statut "wallet operationnel" est publie si les capacites minimales (address + signature + verification) sont valides.

Resultat contractuel attendu: - Une adresse officielle unique est identifiable, stable sur la periode de validite de la cle active et utilisable pour l'ancrage.

FN-177-02 - Emission d'une transaction d'ancrage¶

Un Merkle root valide est fourni au flux d'ancrage.
Le service construit la transaction d'ancrage conforme au format de payload valide pour le contrat PD-53 (MerkleAnchorContract.sol).
La transaction est signee via la couche custody (sans acces a la cle privee en clair).
Si la signature reussit mais la diffusion echoue, la transaction signee peut etre rejouee (retry); l'entree append-only n'est creee qu'apres diffusion confirmee (tx_hash obtenu) et aucune entree orpheline ne doit subsister.
La transaction est diffusee sur le reseau cible.
Le systeme attend la confirmation selon la politique applicable par reseau.
Le resultat (tx_hash + confirmation + signer_address) est lie au Merkle root et inscrit en append-only.
La preuve composite est enrichie des donnees blockchain requises.

Resultat contractuel attendu: - Un tx_hash confirme est associe de maniere univoque au Merkle root ancre.

FN-177-03 - Audit probatoire d'un ancrage¶

Un tiers demande la verification d'un Merkle root ancre.
Le systeme fournit l'entree append-only correspondante et ses metadonnees.
Le tiers verifie la correspondance Merkle root <-> transaction <-> confirmation reseau <-> preuve composite.

Resultat contractuel attendu: - Le tiers peut verifier sans dependre d'un secret interne.

FN-177-04 - Continuite d'exploitation¶

Le systeme surveille les preconditions d'emission (fonds, gas, RPC, capacite custody).
En cas de degradation, une alerte operationnelle est emise avant interruption silencieuse.
En cas d'incident custody, la procedure de reprise documentee est declenchee.
En cas de rotation planifiee, la transition preserve la tracabilite historique.

Resultat contractuel attendu: - Le service reste operable ou echoue explicitement avec dossier d'incident exploitable.

5bis. Diagrammes Mermaid¶

Diagramme d'etats — Cycle de vie d'un ancrage blockchain¶

Represente les etats d'une transaction d'ancrage depuis la reception du Merkle root jusqu'a la finalisation ou l'abandon. References : INV-177-14, INV-177-16, INV-177-17.

stateDiagram-v2
    [*] --> PENDING : Merkle root recu
    PENDING --> SIGNING : Delegation custody S2 (INV-177-06)
    SIGNING --> SIGNED : Signature OK
    SIGNING --> FAILED_SIGNATURE : ERR-177-02
    SIGNED --> BROADCAST : Diffusion reseau
    BROADCAST --> CONFIRMING : tx_hash obtenu, entree append-only creee (INV-177-14)
    BROADCAST --> RETRY_BROADCAST : Echec diffusion (tx signee rejouable)
    RETRY_BROADCAST --> BROADCAST : Retry
    RETRY_BROADCAST --> FAILED_BROADCAST : Retries epuises
    CONFIRMING --> FINALIZED : Confirmations atteintes (137→12, 42161→30) (INV-177-16)
    CONFIRMING --> NON_FINALIZED_TIMEOUT : Timeout 900s depasse (INV-177-16)
    CONFIRMING --> REORGED : Reorg detectee (ERR-177-06)
    PENDING --> BLOCKED_FUNDS : Fonds insuffisants (ERR-177-03)
    PENDING --> BLOCKED_GAS : Gas > plafond (ERR-177-04)
    PENDING --> BLOCKED_RPC : RPC indisponible (ERR-177-05)
    FAILED_SIGNATURE --> [*]
    FAILED_BROADCAST --> [*]
    FINALIZED --> [*]
    NON_FINALIZED_TIMEOUT --> [*]
    REORGED --> [*]
    BLOCKED_FUNDS --> [*]
    BLOCKED_GAS --> [*]
    BLOCKED_RPC --> [*]

Diagramme d'etats — Cycle de vie du wallet¶

Represente les etats du wallet Ethereum officiel depuis l'initialisation jusqu'a la rotation ou l'incident. References : INV-177-01, INV-177-07, INV-177-19.

stateDiagram-v2
    [*] --> INITIALIZING : Chargement config custody
    INITIALIZING --> VALIDATING_MODE : Mode custody lu
    VALIDATING_MODE --> REJECTED : Mode != S2 (ERR-177-01, INV-177-07)
    VALIDATING_MODE --> RESOLVING_ADDRESS : Mode S2 confirme
    RESOLVING_ADDRESS --> OPERATIONAL : Adresse resolue + capacites validees (INV-177-01)
    OPERATIONAL --> SIGNING_TX : Demande ancrage
    SIGNING_TX --> OPERATIONAL : Ancrage termine (succes ou echec trace)
    OPERATIONAL --> DEGRADED : Precondition non satisfaite (fonds, gas, RPC) (INV-177-17)
    DEGRADED --> OPERATIONAL : Precondition retablie
    DEGRADED --> INCIDENT : Incident custody detecte (INV-177-18)
    OPERATIONAL --> ROTATING : Rotation planifiee
    ROTATING --> OPERATIONAL : Nouvelle cle active, historique preserve (INV-177-19)
    INCIDENT --> RECOVERY : Procedure de reprise declenchee (INV-177-18)
    RECOVERY --> OPERATIONAL : Reprise reussie
    REJECTED --> [*]

Diagramme de sequence — Emission d'une transaction d'ancrage (FN-177-02)¶

Represente l'interaction multi-service lors d'un ancrage nominal. References : INV-177-05, INV-177-06, INV-177-08, INV-177-13, INV-177-14.

sequenceDiagram
    participant W as AnchorWorker (PD-55)
    participant WS as WalletService
    participant CS as CustodyStrategy S2 (PD-52)
    participant KMS as AWS KMS secp256k1
    participant RPC as Blockchain RPC (Polygon/Arbitrum)
    participant AO as Registre Append-Only
    participant PC as Preuve Composite (PD-245)

    W->>WS: anchorMerkleRoot(merkleRoot, chainId)
    WS->>CS: signTransaction(txData)
    Note right of CS: INV-177-06 : signature deleguee,<br/>cle privee jamais exposee (INV-177-08)
    CS->>KMS: sign(digest, keyId)
    KMS-->>CS: signature
    CS-->>WS: signedTx
    WS->>RPC: eth_sendRawTransaction(signedTx)
    RPC-->>WS: tx_hash
    WS->>AO: insert(anchorId, merkleRoot, signer_address,<br/>chainId, tx_hash, timestamp_iso8601)
    Note right of AO: INV-177-13 : champs obligatoires<br/>INV-177-14 : lien deterministe append-only
    WS->>RPC: poll confirmations (12 ou 30 selon chainId)
    loop Attente confirmations (timeout 900s)
        RPC-->>WS: confirmationCount
    end
    alt Confirmations atteintes (INV-177-16)
        WS->>AO: updateStatus(FINALIZED)
        WS->>PC: enrichProof(blockchain=ethereum_l2, tx_hash)
        WS-->>W: AnchorResult{FINALIZED, tx_hash}
    else Timeout ou reorg
        WS->>AO: updateStatus(NON_FINALIZED / REORGED)
        WS-->>W: AnchorResult{NON_FINALIZED, errorCode}
    end

Diagramme de sequence — Detection et blocage d'exposition de secret (INV-177-09)¶

Represente le mecanisme fail-closed lors d'une tentative de fuite de secret. References : INV-177-08, INV-177-09, ERR-177-08.

sequenceDiagram
    participant SVC as Service applicatif
    participant GRD as SecretGuard (intercepteur)
    participant LOG as Logger / Trace
    participant AUD as Audit securite

    SVC->>GRD: emit(output contenant materiau sensible)
    GRD->>GRD: Scan patterns cle privee / secret
    alt Secret detecte (INV-177-09)
        GRD->>AUD: createIncident(SECRET_EXPOSURE_DETECTED)
        GRD-->>SVC: throw FailClosedError (ERR-177-08)
        Note right of GRD: Emission bloquee AVANT ecriture<br/>sur canal de sortie (INV-177-08)
    else Aucun secret
        GRD->>LOG: forward(output)
        LOG-->>SVC: OK
    end

6. Cas d'erreur¶

Les ERR-177-XX sont des cas d'usage contractuels qui utilisent les BlockchainErrorCode existants selon le mapping explicite ci-dessous.
ERR-177-01 - Mode custody invalide (BlockchainErrorCode: INVALID_CUSTODY_MODE): si BLOCKCHAIN_CUSTODY_MODE est different de S2 dans le contexte PD-177, l'initialisation doit etre refusee avec code d'erreur explicite.
ERR-177-02 - Echec de signature (BlockchainErrorCode: SIGNATURE_FAILED): toute impossibilite de signer via custody doit produire un echec explicite, journalise, sans fuite de secret.
ERR-177-03 - Fonds insuffisants (BlockchainErrorCode: INSUFFICIENT_FUNDS): l'emission d'ancrage est bloquee avec erreur explicite et alerte operationnelle.
ERR-177-04 - Gas au-dessus plafond (BlockchainErrorCode: GAS_PRICE_CEILING_EXCEEDED): la transaction n'est pas emise et un evenement d'alerte est journalise.
ERR-177-05 - Echec RPC primaire/secondaire (BlockchainErrorCode: RPC_UNAVAILABLE): l'echec est trace selon les codes existants; aucun succes fictif.
ERR-177-06 - Transaction reorg/abandonnee (BlockchainErrorCode: TRANSACTION_REORGED_OR_ABANDONED): le statut final doit refleter l'abandon ou la reorg detectee, sans marquage "finalise" errone.
ERR-177-07 - Donnees de preuve incompletes (BlockchainErrorCode: PROOF_LINK_INCOMPLETE): si le lien Merkle root <-> tx_hash <-> confirmation est incomplet, la preuve est invalide.
ERR-177-08 - Exposition de secret detectee (BlockchainErrorCode: SECRET_EXPOSURE_DETECTED): creation d'un incident securite obligatoire et blocage de l'operation courante.

7. Criteres d'acceptation (testables)¶

CA-177-01: Le systeme expose exactement une adresse wallet officielle active pour le contexte de production PD-177.
CA-177-02: Avec BLOCKCHAIN_CUSTODY_MODE=S2, l'initialisation wallet/custody aboutit; avec S1 ou S3, elle echoue explicitement dans le perimetre PD-177.
CA-177-03: L'interface CustodyStrategy est respectee sans rupture de contrat sur les 5 methodes definies.
CA-177-04: Une transaction d'ancrage de test est emise avec succes et retourne un tx_hash non vide.
CA-177-05: La transaction de test atteint un etat de confirmation reseau positif dans la fenetre de suivi configuree, selon la politique par reseau (137 -> 12 confirmations/900s, 42161 -> 30 confirmations/900s).
CA-177-06: L'entree append-only de l'ancrage contient au minimum les champs imposes par INV-177-13 (incluant signer_address et horodatage ISO 8601 UTC millisecondes) et est immutable apres ecriture.
CA-177-07: Pour une transaction confirmee, la preuve composite contient le champ blockchain=ethereum_l2 et le lien vers tx_hash.
CA-177-08: Aucun secret de type cle privee/materiau sensible n'apparait en clair dans les logs applicatifs lors d'un test nominal de signature.
CA-177-09: En cas de simulation INSUFFICIENT_FUNDS, l'operation echoue explicitement et genere une alerte operationnelle.
CA-177-10: En cas de simulation GAS_PRICE_CEILING_EXCEEDED, l'operation echoue explicitement et genere une alerte operationnelle.
CA-177-11: En cas de simulation d'indisponibilite RPC, le code d'erreur correspondant est emis et aucun statut "finalise" n'est produit.
CA-177-12: En cas de simulation de reorg, le statut final n'est pas "finalise" et l'evenement est trace conformement au code d'erreur.
CA-177-13: La procedure de reprise wallet est documentee, versionnee, et un exercice de test aboutit a un resultat consigne, horodate et auditable.
CA-177-14: Si PD-177 introduit des identifiants aleatoires, ils sont tous conformes a crypto.randomUUID() (verification statique + tests).
CA-177-15: Si PD-177 introduit des cles de test ephemeres, leurs identifiants respectent le prefixe pv-test-*.
CA-177-16: Toute migration de schema introduite par PD-177 passe une validation locale sans erreur PostgreSQL liee aux indexes partiels non supportes.
CA-177-17: Toute evolution BullMQ introduite par PD-177 n'utilise aucune API marquee depreciee dans le perimetre identifie.

8. Scenarios de test (Given / When / Then)¶

ST-177-01 - Initialisation custody valide¶

Given BLOCKCHAIN_CUSTODY_MODE=S2 et une configuration custody valide When le service wallet est initialise Then l'adresse officielle est resolue et le statut "operationnel" est atteint

ST-177-02 - Rejet mode custody hors perimetre¶

Given BLOCKCHAIN_CUSTODY_MODE=S1 (ou S3) When le service wallet est initialise dans PD-177 Then l'initialisation est refusee avec un code d'erreur explicite

ST-177-03 - Ancrage nominal confirme¶

Given un Merkle root valide et un reseau blockchain disponible (Polygon ou Arbitrum) When une transaction d'ancrage est emise Then un tx_hash est produit, confirme, et lie au Merkle root dans le registre append-only

ST-177-04 - Verification tierce de preuve¶

Given une entree append-only d'ancrage confirmee When un tiers verifie les artefacts (preuve composite + transaction) Then la correspondance Merkle root <-> tx_hash <-> confirmation est verifiable

ST-177-05 - Fonds insuffisants¶

Given un solde wallet sous le minimum operationnel When une emission d'ancrage est tentee Then l'operation echoue explicitement, une alerte est emise, et aucun statut "finalise" n'est ecrit

ST-177-06 - Plafond gas depasse¶

Given un prix du gas superieur au plafond configure When une emission d'ancrage est tentee Then l'operation est refusee avec erreur explicite et alerte operationnelle

ST-177-07 - Indisponibilite RPC¶

Given une indisponibilite RPC primaire puis secondaire When une emission d'ancrage est tentee Then l'operation echoue avec code d'erreur reseau et sans finalisation trompeuse

ST-177-08 - Reorg blockchain¶

Given une transaction initialement incluse puis invalidee par reorg When le tracker de confirmations termine son cycle Then le statut final est non-finalise et l'evenement reorg est journalise

ST-177-09 - Controle de fuite de secrets¶

Given une execution de signature en mode debug normalise When les logs et traces sont analyses Then aucun materiau de cle privee n'apparait en clair

ST-177-10 - Exercice de reprise wallet¶

Given une procedure de reprise documentee et un scenario d'indisponibilite custody simule When l'exercice de reprise est execute Then le resultat est consigne, horodate et auditable

9. Hypotheses explicites¶

Les hypotheses suivantes sont necessaires pour appliquer la presente specification. Elles doivent etre confirmees ou invalidees explicitement.

HYP-177-01: Le mode S2 (AWS KMS secp256k1) reste le seul mode custody autorise sur la duree PD-177.
HYP-177-02: Les reseaux cibles d'ancrage operationnels sont ceux deja configures (Polygon/Arbitrum) et le champ preuve reste ethereum_l2 pour PD-177.
HYP-177-03: Un registre append-only existe deja (table anchor_events ou equivalent) et est habilite a recevoir les metadonnees blockchain requises.
HYP-177-04: Les codes d'erreur blockchain existants couvrent les cas d'erreur PD-177 sans extension obligatoire immediate.
HYP-177-05: Les exigences juridiques de publication de l'adresse officielle sont traitees par la gouvernance produit/compliance en dehors du present artefact technique.
HYP-177-06: Transformee en exigence contractuelle (section Definitions et INV-177-16); ce point n'est plus une hypothese.

Si une hypothese est invalidee, la specification doit etre re-emise avec impact explicite sur invariants, criteres d'acceptation et scenarios.

10. Points a clarifier¶

Points bloquants ou incomplets identifies (aucune hypothese implicite):

CL-177-01 - Politique de rotation de cle: periodicite, declencheurs, et mecanisme de continuite d'identite lors du changement d'adresse (declencheurs non formalises a ce stade; PD-177 valide uniquement la preservation d'auditabilite lors d'une rotation simulee).
CL-177-02 - Seuil de solde minimal et mecanisme de refill: valeur contractuelle, responsabilite operationnelle, delai maximal de reapprovisionnement.
CL-177-03 - Separation testnet/mainnet: exigences de cloisonnement des permissions et des identites wallet par environnement.
CL-177-04 - Plan de reprise apres perte d'acces au service custody: RTO, RPO, roles, preuves d'exercice, frequence des tests.
CL-177-05 - Trajectoire S1/S3: decision formelle d'activation (ou non) et impact futur sur la stabilite du contrat PD-177.
CL-177-06 - Obligation de declaration publique/juridique de l'adresse officielle: autorite proprietaire, canal de publication, preuve de mise a jour.
CL-177-07 - Criteres de souverainete mesurables: quelles contraintes geographiques et contractuelles sont juridiquement opposables pour le plan de custody.
CL-177-08 - Exigence de perennite 10-50 ans: definition contractuelle testable des obligations de maintenance de l'identite blockchain (la promesse absolue de 50 ans est hors perimetre car non testable).

References¶

Epic PD-187 - BLOCKCHAIN.
Story PD-52 - Ethereum L2 Setup (interfaces custody/wallet/transaction, mode S2 actif).
Story PD-55 - Worker ancrage blockchain (pipeline collect->anchor->confirm->finalize).
Story PD-53 - Smart contract d'ancrage (MerkleAnchorContract.sol) pour la publication on-chain du Merkle root.
Story PD-245 - Format preuve multi-chain (blockchain: 'ethereum_l2' | 'tezos').
Learnings obligatoires integres: PD-55, PD-52, PD-245, PD-63 (UUID securise et prefixe pv-test-*).