ZVD PONTES VENETO V5

Autore

ZVD – Pontes Veneto v5.0 | Whitepaper Istituzionale
Documento Tecnico-Istituzionale · Whitepaper Ufficiale

ZVD – Pontes Veneto v5.0 Architettura Sovrana Integrata per il Regolamento all’Ingrosso e l’Utilizzo Quotidiano

Versione 5.0 Settembre 2026 Autore: Franco Paluan Allineato a Pontes / Eurosistema Programma Appia Sovranità Digitale Veneta

Executive Summary

Il 21 settembre 2026 l’Eurosistema ha lanciato Pontes, la soluzione che consente alle transazioni all’ingrosso in attività tokenizzate di essere regolate in moneta di banca centrale (CeBM). Pontes è la prima iniziativa del programma strategico dell’Eurosistema per rendere la moneta di banca centrale adatta a un futuro tokenizzato e per supportare lo sviluppo di questo ecosistema finanziario in rapida evoluzione.

L’Eurosistema sta lavorando per consentire un mercato finanziario europeo più integrato, innovativo e resiliente nell’era digitale. Continueremo a fare progressi in stretta collaborazione con il mercato.

— Christine Lagarde, Presidente della BCE

Lo Zecchino Veneto Digitale (ZVD), nella sua versione 5.0, adotta integralmente l’architettura Pontes e la adatta al contesto territoriale storico veneto, integrandola con i principi di sovranità digitale veneta e con un’implementazione operativa per l’utente finale (persona fisica). Il ZVD ha un valore di 1:1 con l’Euro, stabilito per decisione del Governatore del Banco Nazionale Veneto.

Garanzie fondamentali

  • Moneta di banca centrale come ancora: ogni transazione all’ingrosso può essere regolata in moneta di banca centrale, eliminando il rischio di credito dell’emittente.
  • Doppio modello di regolamento: cash token sul DLT dell’Eurosistema oppure regolamento diretto in T2 RTGS.
  • Hash-Link Protocol: regolamento atomico DvP/PvP con finalità garantita e all-or-none.
  • Interoperabilità nativa: connessione tra piattaforme DLT di mercato e TARGET Services.
  • Utilizzo quotidiano per le persone: pagamenti, trasferimenti, risparmio e servizi pubblici con wallet sovrano e SSI.
  • Integrazione con Multisig EnvLab: gestione multi-firma per consorzi e operazioni critiche sulla blockchain Waves.

1. Visione e Posizionamento Istituzionale

1.1 Da ZVD a Pontes Veneto v5.0

Il whitepaper v4.0 descriveva lo ZVD come un’infrastruttura DLT permissioned autonoma allineata a Pontes. La versione 5.0 riposiziona lo ZVD come sistema di interoperabilità e regolamento modellato su Pontes, con le seguenti differenze fondamentali:

Confronto ZVD v4.1 vs Pontes Veneto v5.0
DimensioneZVD v4.1Pontes Veneto v5.0
Modello di riservaCeBM + riserva reale + capitale sovranoCeBM + riserva reale + capitale sovrano
RegolamentoDoppio binario (cash token + T2)Doppio binario + Hash-Link Protocol sovrano
InteroperabilitàHash-Link ProtocolHash-Link + Multisig EnvLab (Waves)
GovernanceAllineata a Pontes MCG / MIB+ Assemblea dei Nodi Sovrani
AccessoBanche, CSD, operatori DLT, CCP+ Utenti finali (persone fisiche)
IdentitàPseudonimi e hash+ Self-Sovereign Identity (SSI)
ValoreAncorato a CeBM1:1 con l’Euro (decisione del Governatore del Banco Nazionale Veneto)
ResilienzaDR tradizionale+ Sovereign Link Protocol (serverless)

1.2 Principi guida allineati a Pontes

  1. Mantenere la moneta di banca centrale come ancora di un sistema monetario a due livelli.
  2. Raggiungere l’autonomia strategica e una maggiore resilienza per i pagamenti europei.
  3. Promuovere un ecosistema di pagamenti integrato, competitivo e innovativo.
  4. Supportare il ruolo internazionale dell’euro.
  5. Sostenere l’innovazione senza compromettere sicurezza ed efficienza nelle infrastrutture di mercato finanziario.

1.3 Perimetro operativo esteso

Il Pontes Veneto v5.0 opera tra:

  • Soggetti ammessi Pontes: banche, CSD, operatori DLT, CCP con accesso a T2. Tra i partecipanti iniziali figurano ABANCA, BayernLB, Caisse des Dépôts et Consignations, Cecabank, Deutsche Bank, Deka Bank, DZ Bank, European Investment Bank, KfW, Memo Bank, NRW.BANK, Santander e Société Générale.
  • Nodi Sovrani: enti territoriali, consorzi di filiera, università, camere di commercio.
  • Cittadini-utenti: attraverso Self-Sovereign Identity e wallet sovrani.
  • Imprese venete: attraverso l’ecosistema delle filiere produttive.
  • Consorzi multisig: attraverso l’integrazione con Multisig EnvLab.
◆ ◆ ◆

2. Architettura di Sistema – Modello “Pontes Veneto v5.0”

2.1 Diagramma architetturale

LIVELLO 5 — APPLICAZIONI UTENTE FINALE Wallet sovrano · Pagamenti QR · Trasferimenti P2P · Servizi pubblici Marketplace di filiera · Gemello Digitale del Veneto · DAO di filieraLIVELLO 4 — INTERFACCIA SOVRANA Extended Interoperability Interface (EII) · Sovereign Link Protocol SSI (Self-Sovereign Identity) · API Gateway · Mesh Network Multisig EnvLab Bridge (Waves Blockchain)LIVELLO 3 — SOVEREIGN SUBSTRATE Tre primitive: Functional Units · State Units · Credential Units Otto meccanismi: compile-at-commit · roll-up · wilful inclusion · refusal · runtime evaluation · uniform invalidation · … Sovereign Constitution Fabric (Standard 817)LIVELLO 2 — DLT PONTES VENETO Rete permissioned IBFIT 2.0 · Chain ID 8140 · Hyperledger Besu Smart Contracts: ZVDToken · DvP Hash-Link · Registry · Oracle · Governance · SovereignIdentity · SovereignSubstrateLIVELLO 1 — INFRASTRUTTURA SOVRANA Data Center Regionale ACN · T2 RTGS · Token Issuance Wallet Custodia collaterale · Sovereign Mesh BackhaulLIVELLO 0 — BLOCKCHAIN WAVES (Multisig EnvLab) Wallet multisig · API pagamenti · Smart contract · Bridge di integrazione

2.2 Componenti principali (allineati a Pontes)

Il Pontes Veneto è costruito attorno a tre componenti principali, esattamente come il Pontes dell’Eurosistema:

01

Extended Interoperability Interface (EII)

Punto di accesso unico al DLT dell’Eurosistema tramite API e/o GUI, che indirizza le richieste al nodo corretto. Supporta operazioni standard e regolamenti all-or-none (DvP e PvP) tramite Hash-Link Protocol.

02

Eurosystem DLT Platform (ESY DLT)

Piattaforma DLT permissioned composta da nodi di banca centrale, nodo operatore e nodo BCE, con Dedicated Cash Wallets e Token Issuance Wallet.

03

T2 Interface

Interfaccia per il regolamento diretto in T2 RTGS, con trigger basati su API.

3. Modello di Regolamento – Doppio Binario

3.1 Modello duale (allineato a Pontes)

Il Pontes Veneto adotta il doppio modello di regolamento di Pontes:

Opzione A — Cash Token Settlement

  • I partecipanti regolano le transazioni sulla piattaforma DLT dell’Eurosistema con cash token (proxy della moneta di banca centrale).
  • Funding e defunding dei Dedicated Cash Wallets per il regolamento con cash token.
  • Verifica di conformità tramite Sovereign Substrate prima del commit.

Opzione B — Direct T2 RTGS Settlement

  • I partecipanti regolano direttamente in T2, il sistema RTGS dell’Eurosistema, tramite trigger basati su API.
  • La finalità del cash leg è raggiunta una volta completata la transazione corrispondente in T2, garantendo certezza legale e robustezza.

3.2 Hash-Link Protocol per DvP/PvP

Il regolamento all-or-none per DvP e PvP è abilitato tramite Hash-Link Protocol, basato su Hash-Time Locked Contracts (HTLC), DLT-agnostic e API-based, con un Trusted Oracle sovrano gestito dal NASI.

Flusso Hash-Link sovrano:

  1. Setup: il venditore genera secret, calcola H(secret), lo registra on-chain.
  2. Verifica SSI: il compratore autentica la propria identità sovrana tramite DID/VC.
  3. Lock: il compratore blocca i fondi condizionati alla rivelazione del secret.
  4. Compliance check: il Sovereign Substrate verifica la conformità dell’operazione.
  5. Reveal: il venditore rivela il secret entro il timeLock.
  6. Settle: i fondi sono trasferiti atomicamente.
  7. Expire: se il secret non è rivelato entro il timeLock, i fondi sono rimborsati.

3.3 Finalità e irrevocabilità

La finalità del regolamento è garantita secondo l’Articolo 18, Allegato 1, Parte I della TARGET Guideline. Il regolamento è irrevocabile una volta completato in T2.

◆ ◆ ◆

4. Modello di Riserva e Tesoreria – Triplo Ancoraggio

4.1 Struttura della riserva

Il Pontes Veneto prevede un triplo ancoraggio:

Livello 1 — Moneta di Banca Centrale (CeBM)

La riserva primaria è detenuta in moneta di banca centrale presso il Token Issuance Wallet del Registro Centrale di Riserva. Questa riserva è utilizzata per il regolamento delle transazioni all’ingrosso in cash token.

Livello 2 — Riserva Reale di Garanzia

Una riserva sussidiaria di attivi reali verificabili (oro, metalli preziosi, titoli di Stato area euro) è detenuta presso custodi autorizzati. Questa riserva fornisce copertura aggiuntiva e supporta la convertibilità in euro.

Livello 3 — Capitale Sovrano

Fondo di dotazione regionale per la stabilizzazione e lo sviluppo. Gestito dall’Agenzia Veneta Digitale in coordinamento con la Regione.

4.2 Valore 1:1 con l’Euro

Lo Zecchino Veneto Digitale (ZVD) ha un valore di 1:1 con l’Euro, stabilito per decisione del Governatore del Banco Nazionale Veneto. Questo ancoraggio garantisce:

  • Stabilità del potere d’acquisto per i cittadini veneti.
  • Fiducia nelle transazioni quotidiane senza volatilità.
  • Convertibilità garantita in Euro presso gli sportelli autorizzati.
  • Integrazione con il sistema bancario tradizionale senza rischio di cambio.

Il peg 1:1 è sostenuto dalla riserva a triplo ancoraggio e monitorato dal Comitato Rischi con circuit breaker automatici.

4.3 Attivi ammessi

Composizione degli attivi di riserva
AttivoHaircutLimiteRuolo
Moneta di banca centrale0%100%Riserva primaria — regolamento
Oro fisico LBMA5–10%40%Riserva sussidiaria
Titoli di Stato area euro2–5%30%Riserva sussidiaria
Depositi bancari garantiti0–2%20%Liquidità operativa
Capitale sovrano regionale0%10%Stabilizzazione

4.4 Circuit breaker

  • Reserve ratio < 100% → blocco mint.
  • Reserve ratio < 98% → blocco mint + redemption parziale.
  • Reserve ratio < 95% → sospensione operativa + attivazione Eclipse Protocol.
  • Attacco informatico → isolamento automatico dei nodi compromessi tramite Sovereign Link.

4.5 Proof-of-Reserve

  • Giornaliero: report interno automatico.
  • Mensile: attestazione firmata da auditor.
  • Trimestrale: audit completo.
  • On-chain: hash del report ancorato tramite Merkle Review System.

5. Governance Sovrana

5.1 Organi di governance

Struttura di governance del Pontes Veneto v5.0
OrganoComposizioneFunzione
Assemblea dei Nodi SovraniValidatori + enti territoriali + universitàApprova la costituzione digitale, le modifiche allo Standard 817
Comitato Tecnico-Istituzionale5–7 membri indipendentiStrategia, parametri, upgrade
Comitato RischiRisk, compliance, auditMonitoraggio riserva, limiti, incidenti
Segreteria TecnicaDirettore operativo + staffEsecuzione decisioni, reporting
Registro Centrale di RiservaCustode + tesoreriaMint, burn, custodia, attestazioni
Arbiter NodeComitato di GaranziaContenziosi, emergency cancel
Auditor IndipendenteSocietà esternaAudit riserve, codice, sicurezza
Agenzia Sovrana per l’Innovazione (NASI)Consiglio scientificoSupervisione algoritmi, etica digitale
Governatore del Banco Nazionale VenetoNominato dall’AssembleaStabilisce il peg 1:1, supervisiona la riserva

5.2 Composizione dell’Assemblea dei Nodi Sovrani

L’Assemblea replica ed estende il modello del Pontes MCG (64 stakeholder da 9 paesi) con:

  • Banca d’Italia – Filiale Veneto (coordinamento istituzionale)
  • Banche venete e casse rurali (partecipanti di mercato)
  • CSD e operatori DLT (infrastrutture)
  • Regione Veneto (osservatore istituzionale)
  • Università venete (consulenza scientifica)
  • Camere di Commercio (rappresentanza delle imprese)
  • Consorzi di filiera (agroalimentare, manifattura, turismo)

5.3 Key management sovrano

  • Chiavi validatori: HSM o MPC, rotazione semestrale.
  • Chiavi admin: multisig 3/5 + timelock 48h.
  • Chiavi emergenza: 2/3 break-glass, log immutabile.
  • Chiavi cash token: gestite dal Token Issuance Wallet.
  • Chiavi SSI: gestite dall’utente tramite wallet sovrano (hardware o software).
  • Firma post-quantistica: Quantum Sovereign Signature (QSS™) per le operazioni critiche.
◆ ◆ ◆

6. Utilizzo da parte dell’Utente Finale (Persona Fisica)

6.1 Premessa: il valore 1:1 con l’Euro

Lo Zecchino Veneto Digitale (ZVD) ha un valore di 1:1 con l’Euro, stabilito per decisione del Governatore del Banco Nazionale Veneto. Questo ancoraggio garantisce:

  • Stabilità del potere d’acquisto per i cittadini veneti.
  • Fiducia nelle transazioni quotidiane senza volatilità.
  • Convertibilità garantita in Euro presso gli sportelli autorizzati.
  • Integrazione con il sistema bancario tradizionale senza rischio di cambio.

6.2 Fasi di adesione per l’utente finale

Percorso di onboarding dell’utente finale
FaseAzioneStrumento
1. RegistrazioneCreazione identità sovrana (DID)Wallet ZVD / SSI
2. VerificaKYC semplificato per persone fisicheSportello bancario o app
3. AttivazioneApertura contoWallet ZVD sovrano
4. UtilizzoPagamenti, trasferimenti, risparmioApp mobile / QR code

6.3 Casi d’uso quotidiani

Pagamenti in negozio

  • L’utente mostra il QR code del wallet.
  • Il commerciante scansiona e richiede il pagamento.
  • Conferma con impronta digitale o PIN.
  • Transazione finalizzata in 2 secondi, con finalità T2.

Trasferimenti P2P

  • Invio di ZVD a familiari, amici, fornitori.
  • Nessuna commissione per importi inferiori a 1.000 ZVD.
  • Ricevuta digitale con marca temporale on-chain.

Risparmio e investimento

  • Deposito ZVD presso conti remunerati.
  • Partecipazione a progetti di filiera tramite DAO.
  • Accesso a microcredito senza interessi.

Servizi pubblici

  • Pagamento di tributi locali, trasporti, mense scolastiche.
  • Ricezione di sussidi e rimborsi in ZVD.
  • Integrazione con l’Agenda Digitale del Veneto.

6.4 Interfaccia utente semplificata

Wallet mobile — Funzionalità principali

Funzionalità del wallet ZVD
FunzioneDescrizione
SaldoVisualizzazione in ZVD ed Euro (1:1)
Pagamento QRScansione e invio
TrasferimentoInvio a contatti o IBAN ZVD
StoricoTransazioni con marca temporale
ConvertibilitàCambio ZVD ↔ Euro presso sportelli
SicurezzaBiometria, PIN, backup seed
SSIGestione identità sovrana (DID/VC)

Accessibilità

  • Multilingua: Italiano, Veneto, Inglese.
  • Modalità semplificata per anziani.
  • Assistenza telefonica regionale.
  • Sportelli fisici presso casse rurali e banche convenzionate.

6.5 Tutele per l’utente finale

  • Fondo di garanzia per depositanti fino a 100.000 ZVD.
  • Assicurazione contro frodi informatiche.
  • Reclami gestiti entro 30 giorni.
  • Educazione finanziaria obbligatoria all’apertura.

6.6 Flusso operativo di esempio

Utente (Mario) → Wallet ZVD → Negozio (Panificio Veneto)├── Mostra QR code ───────────────────────────── ├── Conferma pagamento ───────────────────────── └── Ricevuta on-chain ──────────────────────────

7. Integrazione con Multisig EnvLab (Waves Blockchain)

7.1 Architettura di integrazione

Il wallet multisig.envlab.eu è una soluzione basata sulla blockchain Waves che consente la gestione di transazioni multi-firma. L’integrazione con il Pontes Veneto avviene tramite:

  • API del wallet per l’automazione dei pagamenti.
  • Libreria @waves/waves-transactions per la creazione e firma di transazioni multisig.
  • Smart contract Waves per la logica di autorizzazione.
PONTES VENETO (DLT) Smart Contract ZVD · DvP Hash-Link · Sovereign Substrate │ [Bridge di integrazione] │ MULTISIG ENVLAB (Waves Blockchain) Wallet multisig · API pagamenti · QR code · NFT

7.2 Setup del progetto

Setup ambientebash
# Clona il repository ufficiale
git clone https://github.com/pontes-veneto/core.git
cd core

# Installa le dipendenze
npm install

# Configura l'ambiente
cp .env.example .env
# Modifica .env con le tue chiavi

7.3 Creazione di un wallet multisig per un consorzio di filiera

multisig-setup.tstypescript
import { createTransaction, signTransaction, broadcast } from '@waves/waves-transactions';
import { libs } from '@waves/waves-transactions';

const NODE_URL = 'https://nodes.wavesnodes.com';

// Chiavi dei membri del consorzio (2 su 3)
const member1Seed = 'seed-membro-1';
const member2Seed = 'seed-membro-2';
const member3Seed = 'seed-membro-3';

const members = [
  libs.crypto.publicKey(member1Seed),
  libs.crypto.publicKey(member2Seed),
  libs.crypto.publicKey(member3Seed)
];

// Script multisig 2-of-3
const multisigScript = `
let alice = base58'${members[0]}'
let bob = base58'${members[1]}'
let carol = base58'${members[2]}'

let aliceSigned = sigVerify(tx.bodyBytes, tx.proofs[0], alice)
let bobSigned = sigVerify(tx.bodyBytes, tx.proofs[1], bob)
let carolSigned = sigVerify(tx.bodyBytes, tx.proofs[2], carol)

(aliceSigned && bobSigned) || (aliceSigned && carolSigned) || (bobSigned && carolSigned)
`;

// Transazione per impostare lo script multisig
async function setMultisigScript(seed: string) {
  const setScriptTx = createTransaction({
    type: 13, // SetScript
    version: 2,
    script: multisigScript,
    fee: 1000000,
    chainId: 'W'
  }, seed);

  const signedTx = signTransaction(setScriptTx, seed);
  const result = await broadcast(signedTx, NODE_URL);
  console.log('Multisig script impostato:', result.id);
}

setMultisigScript(member1Seed);

7.4 API di pagamento tramite URL

payment-api.tstypescript
interface PaymentParams {
  recipient: string;
  amount: number;
  assetId?: string;
  attachment?: string;
}

function buildPaymentUrl(params: PaymentParams): string {
  const baseUrl = 'https://multisig.envlab.eu/';
  const recno = 'd4e5f6a7b8c9';

  const queryParams = new URLSearchParams({
    recno,
    recipient: params.recipient,
    amount: params.amount.toString(),
    assetId: params.assetId || '',
    attachment: params.attachment || ''
  });

  return `${baseUrl}?${queryParams.toString()}`;
}

// Esempio: pagamento di 100 ZVD a un fornitore
const paymentUrl = buildPaymentUrl({
  recipient: '3PM1Zb4vsWTVYBhcXmZ443gpPZsA2U4zTVM',
  amount: 100,
  assetId: 'ZVD',
  attachment: 'Fattura-2026-001'
});

console.log('URL di pagamento:', paymentUrl);

7.5 Integrazione con il DvP Hash-Link

dvp-integration.tstypescript
async function automatePayment(
  tradeId: string,
  amount: number,
  recipient: string,
  memberSeeds: string[]
) {
  const transferTx = createTransaction({
    type: 4, // Transfer
    version: 2,
    recipient: recipient,
    amount: amount * 100000000, // Importo in satoshi ZVD
    assetId: 'ZVD',
    fee: 100000,
    attachment: `DvP-${tradeId}`
  }, memberSeeds[0]);

  let signedTx = transferTx;
  for (const seed of memberSeeds) {
    signedTx = signTransaction(signedTx, seed);
  }

  const result = await broadcast(signedTx, 'https://nodes.wavesnodes.com');
  console.log('Pagamento inviato:', result.id);

  await registerDvPHash(tradeId, result.id);
}

async function registerDvPHash(tradeId: string, txHash: string) {
  const response = await fetch('https://api.pontesveneto.eu/eii/v1/trades/register', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      tradeId,
      externalTxHash: txHash,
      chain: 'waves',
      timestamp: Date.now()
    })
  });
  return response.json();
}

7.6 Bridge tra Waves e Pontes Veneto

bridge.tstypescript
interface BridgeRequest {
  sourceChain: 'waves' | 'pontes';
  targetChain: 'waves' | 'pontes';
  amount: number;
  recipient: string;
  txHash: string;
}

async function bridgeTransfer(request: BridgeRequest) {
  const isValid = await verifyTransaction(request.txHash, request.sourceChain);
  if (!isValid) {
    throw new Error('Transazione non valida');
  }

  if (request.sourceChain === 'waves') {
    await lockWavesFunds(request.txHash);
  }

  const releaseTx = await releasePontesFunds(
    request.recipient,
    request.amount,
    request.txHash
  );

  await logBridgeOperation({
    ...request,
    releaseTxHash: releaseTx,
    timestamp: Date.now()
  });

  return releaseTx;
}

7.7 Smart contract Waves per il consorzio

consortium.ridejavascript
# Smart contract per la gestione di un consorzio di filiera
# con autorizzazione 2-su-3

let consorzio = base58'3PM1Zb4vslwTVYBcXmZ443gpPZsAZU4zTVM'
let membro1 = base58'3P2H9Y7gXbN4vK8jL6mQ1wS3cD5fG7hJ9k'
let membro2 = base58'3P4R6tY8uI0oP2a54dF6gH8jK0lM2nB4v'
let membro3 = base58'3P5T7yU9i01pQ3sD5fG7hJ9kL1mN3bV5c'

let firma1 = sigVerify(tx.bodyBytes, tx.proofs[0], membro1)
let firma2 = sigVerify(tx.bodyBytes, tx.proofs[1], membro2)
let firma3 = sigVerify(tx.bodyBytes, tx.proofs[2], membro3)

let autorizzato = (firma1 && firma2) || (firma1 && firma3) || (firma2 && firma3)
let destinazioneValida = tx.recipient == consorzio
let fee0k = tx.fee <= 1000000

autorizzato && destinazioneValida && fee0k

7.8 Onboarding semplificato per l’utente finale

onboarding.tstypescript
async function onboardUser(userData: {
  nome: string;
  cognome: string;
  codiceFiscale: string;
  email: string;
}) {
  const kycResult = await verifyKYC(userData.codiceFiscale);
  if (!kycResult.approved) {
    throw new Error('KYC non superato');
  }

  const seed = generateSeed();
  const publicKey = libs.crypto.publicKey(seed);
  const address = libs.crypto.address(seed, 'W');

  const walletConfig = {
    seed: encryptSeed(seed, userData.codiceFiscale),
    address,
    publicKey,
    kycHash: kycResult.hash,
    createdAt: Date.now()
  };

  await registerUserOnPontes(address, kycResult.hash);
  await sendWelcomeEmail(userData.email, walletConfig);

  return walletConfig;
}

7.9 Invio di ZVD all’utente

fund-user.tstypescript
async function fundUserWallet(
  userAddress: string,
  amount: number,
  purpose: string
) {
  const reserveBalance = await getReserveBalance();
  if (reserveBalance < amount) {
    throw new Error('Riserva insufficiente');
  }

  const mintTx = await mintZVD(userAddress, amount, purpose);
  await recordMint(mintTx.id, amount, purpose);
}

7.10 Sicurezza e best practice

Misure di sicurezza per l’integrazione Multisig
AspettoImplementazione
Gestione seedCifratura AES-256, backup su hardware
MultisigQuorum 2/3 per consorzi, 3/5 per operazioni critiche
TimeLock48 ore per transazioni superiori a 10.000 ZVD
AuditLog immutabile di ogni operazione
RecoveryProcedura di recupero con verifica biometrica
ComplianceKYC/AML integrato con il Banco Nazionale Veneto
◆ ◆ ◆

8. Smart Contract Suite

8.1 Contratti previsti

Suite di smart contract del Pontes Veneto
ContrattoFunzioneIntegrazione sovrana
ZVDTokenERC-20 con mint/burn controllati, freeze, pauseCompliance check via Sovereign Substrate
OperatorRegistryWhitelist operatori, KYC hash, limitiSSI integration per autenticazione
ZVDReserveOracleAttestazioni di riservaMerkle Review System per verifica
ZVDGovernanceTimelock + multisigStandard 817 compliance
ZecchinoVenetoDvPDvP Hash-LinkTrusted Oracle sovrano (NASI)
BridgeHTLCInteroperabilità RTGSSovereign Link Protocol
SovereignIdentitySSI registry per DID/VCIntegrazione con wallet sovrani

8.2 ZVDToken.sol — Integrazione sovrana

ZVDToken.solsolidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

/**
 * @title ZVDToken
 * @notice Token ERC-20 per lo Zecchino Veneto Digitale v5.0.
 * Integra Sovereign Substrate per compliance check e
 * Sovereign Identity per autenticazione.
 * Valore 1:1 con l'Euro per decisione del Governatore
 * del Banco Nazionale Veneto.
 */
contract ZVDToken is ERC20, AccessControl, Pausable {

    bytes32 public constant MINTER_ROLE      = keccak256("MINTER_ROLE");
    bytes32 public constant BURNER_ROLE      = keccak256("BURNER_ROLE");
    bytes32 public constant COMPLIANCE_ROLE  = keccak256("COMPLIANCE_ROLE");
    bytes32 public constant PAUSER_ROLE      = keccak256("PAUSER_ROLE");
    bytes32 public constant CASH_TOKEN_ROLE  = keccak256("CASH_TOKEN_ROLE");
    bytes32 public constant SOVEREIGN_ROLE   = keccak256("SOVEREIGN_ROLE");

    mapping(address => bool)    public frozen;
    mapping(address => bytes32) public sovereignDID;

    event AccountFrozen(address indexed account, bool status);
    event Mint(address indexed to, uint256 amount);
    event Burn(address indexed from, uint256 amount);
    event CashTokenIssued(address indexed to, uint256 amount);
    event CashTokenRedeemed(address indexed from, uint256 amount);
    event SovereignDIDLinked(address indexed account, bytes32 did);

    constructor(address admin)
        ERC20("Zecchino Veneto Digitale", "ZVD")
    {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(MINTER_ROLE, admin);
        _grantRole(BURNER_ROLE, admin);
        _grantRole(COMPLIANCE_ROLE, admin);
        _grantRole(PAUSER_ROLE, admin);
        _grantRole(CASH_TOKEN_ROLE, admin);
        _grantRole(SOVEREIGN_ROLE, admin);
    }

    function mint(address to, uint256 amount)
        external onlyRole(MINTER_ROLE) whenNotPaused
    {
        _mint(to, amount);
        emit Mint(to, amount);
    }

    function burn(address from, uint256 amount)
        external onlyRole(BURNER_ROLE)
    {
        _burn(from, amount);
        emit Burn(from, amount);
    }

    function issueCashToken(address to, uint256 amount)
        external onlyRole(CASH_TOKEN_ROLE) whenNotPaused
    {
        _mint(to, amount);
        emit CashTokenIssued(to, amount);
    }

    function redeemCashToken(address from, uint256 amount)
        external onlyRole(CASH_TOKEN_ROLE)
    {
        _burn(from, amount);
        emit CashTokenRedeemed(from, amount);
    }

    function linkSovereignDID(address account, bytes32 did)
        external onlyRole(SOVEREIGN_ROLE)
    {
        sovereignDID[account] = did;
        emit SovereignDIDLinked(account, did);
    }

    function freeze(address account, bool status)
        external onlyRole(COMPLIANCE_ROLE)
    {
        frozen[account] = status;
        emit AccountFrozen(account, status);
    }

    function pause()   external onlyRole(PAUSER_ROLE) { _pause(); }
    function unpause() external onlyRole(PAUSER_ROLE) { _unpause(); }

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal override whenNotPaused {
        require(!frozen[from] && !frozen[to], "ZVD: account congelato");
        super._beforeTokenTransfer(from, to, amount);
    }
}

8.3 ZecchinoVenetoDvP.sol (Hash-Link Sovrano)

ZecchinoVenetoDvP.solsolidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

/**
 * @title ZecchinoVenetoDvP
 * @notice Regolamento atomico DvP/PvP con Hash-Link Protocol sovrano.
 * @dev Integra Trusted Oracle sovrano (NASI), SSI per autenticazione,
 * compliance check automatico e dispute resolution on-chain.
 */
contract ZecchinoVenetoDvP is ReentrancyGuard, AccessControl, Pausable {
    using SafeERC20 for IERC20;

    bytes32 public constant ARBITER_ROLE     = keccak256("ARBITER_ROLE");
    bytes32 public constant OPERATOR_ROLE    = keccak256("OPERATOR_ROLE");
    bytes32 public constant HASH_LINK_ROLE   = keccak256("HASH_LINK_ROLE");
    bytes32 public constant T2_TRIGGER_ROLE  = keccak256("T2_TRIGGER_ROLE");
    bytes32 public constant NASI_ROLE        = keccak256("NASI_ROLE");

    enum TradeStatus {
        None, Initiated, HashLocked, ApprovedBuyer,
        ApprovedSeller, Settled, Cancelled, Expired, Disputed
    }

    struct Trade {
        address buyer;
        address seller;
        uint256 amountZec;
        bytes32 assetHash;
        bytes32 hashLock;
        uint64  timeLock;
        string  assetDescription;
        TradeStatus status;
        uint64  initiatedAt;
        uint64  settledAt;
        bool    t2Settlement;
        bytes32 buyerDID;
        bytes32 sellerDID;
    }

    mapping(bytes32 => Trade) public trades;
    mapping(bytes32 => bool)  public revealedSecrets;
    mapping(bytes32 => bytes32) public disputeEvidence;

    IERC20 public immutable zecToken;
    uint256 public constant DEFAULT_TIMEOUT = 7 days;

    event TradeInitiated(bytes32 indexed tradeId, address indexed buyer, address indexed seller, uint256 amountZec, bytes32 assetHash);
    event HashLocked(bytes32 indexed tradeId, bytes32 hashLock, uint64 timeLock);
    event SecretRevealed(bytes32 indexed tradeId, bytes32 secret);
    event TradeSettled(bytes32 indexed tradeId, uint256 amountZec, bool t2);
    event TradeCancelled(bytes32 indexed tradeId, address indexed by);
    event DisputeOpened(bytes32 indexed tradeId, bytes32 evidenceHash);
    event DisputeResolved(bytes32 indexed tradeId, bool settled);

    constructor(
        address _zecToken,
        address _admin,
        address _arbiter
    ) {
        require(_zecToken != address(0), "Token invalid");
        zecToken = IERC20(_zecToken);
        _grantRole(DEFAULT_ADMIN_ROLE, _admin);
        _grantRole(ARBITER_ROLE, _arbiter);
    }

    function initiateTrade(
        bytes32 tradeId,
        address seller,
        uint256 amountZec,
        bytes32 assetHash,
        bytes32 hashLock,
        uint64  timeLock,
        string calldata assetDescription,
        bool t2Settlement
    ) external nonReentrant onlyRole(OPERATOR_ROLE) whenNotPaused {
        require(trades[tradeId].status == TradeStatus.None, "Trade ID esistente");
        require(seller != address(0) && seller != msg.sender, "Seller non valido");
        require(amountZec > 0, "Importo nullo");
        require(hashLock != bytes32(0), "HashLock mancante");
        require(timeLock > block.timestamp, "TimeLock scaduto");

        zecToken.safeTransferFrom(msg.sender, address(this), amountZec);

        trades[tradeId] = Trade({
            buyer: msg.sender,
            seller: seller,
            amountZec: amountZec,
            assetHash: assetHash,
            hashLock: hashLock,
            timeLock: timeLock,
            assetDescription: assetDescription,
            status: TradeStatus.Initiated,
            initiatedAt: uint64(block.timestamp),
            settledAt: 0,
            t2Settlement: t2Settlement,
            buyerDID: bytes32(0),
            sellerDID: bytes32(0)
        });

        emit TradeInitiated(tradeId, msg.sender, seller, amountZec, assetHash);
    }

    function revealSecret(bytes32 tradeId, bytes32 secret)
        external nonReentrant
    {
        Trade storage t = trades[tradeId];
        require(t.status == TradeStatus.HashLocked, "Stato non valido");
        require(
            keccak256(abi.encodePacked(secret)) == t.hashLock,
            "Secret non valido"
        );
        require(block.timestamp <= t.timeLock, "TimeLock scaduto");

        revealedSecrets[tradeId] = true;
        t.status = TradeStatus.ApprovedSeller;
        emit SecretRevealed(tradeId, secret);
    }

    function emergencyCancel(bytes32 tradeId)
        external nonReentrant onlyRole(ARBITER_ROLE)
    {
        Trade storage t = trades[tradeId];
        require(
            t.status != TradeStatus.Settled &&
            t.status != TradeStatus.Cancelled &&
            t.status != TradeStatus.None,
            "Non cancellable"
        );
        t.status = TradeStatus.Cancelled;
        zecToken.safeTransfer(t.buyer, t.amountZec);
        emit TradeCancelled(tradeId, msg.sender);
    }

    function pause()   external onlyRole(DEFAULT_ADMIN_ROLE) { _pause(); }
    function unpause() external onlyRole(DEFAULT_ADMIN_ROLE) { _unpause(); }
}

8.4 BridgeHTLC.sol (Interoperabilità RTGS)

BridgeHTLC.solsolidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

/**
 * @title BridgeHTLC
 * @notice Bridge HTLC per interoperabilità tra Pontes Veneto e T2 RTGS.
 * Integra Sovereign Link Protocol e Multisig EnvLab (Waves).
 */
contract BridgeHTLC is AccessControl, ReentrancyGuard {
    bytes32 public constant OPERATOR_ROLE        = keccak256("OPERATOR_ROLE");
    bytes32 public constant T2_RELAYER_ROLE      = keccak256("T2_RELAYER_ROLE");
    bytes32 public constant SOVEREIGN_LINK_ROLE  = keccak256("SOVEREIGN_LINK_ROLE");
    bytes32 public constant MULTISIG_BRIDGE_ROLE = keccak256("MULTISIG_BRIDGE_ROLE");

    struct HTLC {
        address sender;
        address receiver;
        uint256 amount;
        bytes32 hashLock;
        uint64  timeLock;
        bool    claimed;
        bool    refunded;
        bool    sovereignLink;
        bytes32 wavesTxHash;
    }

    mapping(bytes32 => HTLC) public htlcs;

    event HTLCCreated(bytes32 indexed htlcId, address indexed sender, address indexed receiver, uint256 amount, bytes32 hashLock, uint64 timeLock);
    event HTLCClaimed(bytes32 indexed htlcId, bytes32 secret);
    event HTLCRefunded(bytes32 indexed htlcId);
    event T2TriggerRelayed(bytes32 indexed htlcId, bytes32 t2TxHash);
    event SovereignLinkEstablished(bytes32 indexed htlcId);
    event WavesMultisigLinked(bytes32 indexed htlcId, bytes32 wavesTxHash);

    constructor(address admin) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(OPERATOR_ROLE, admin);
        _grantRole(T2_RELAYER_ROLE, admin);
        _grantRole(SOVEREIGN_LINK_ROLE, admin);
        _grantRole(MULTISIG_BRIDGE_ROLE, admin);
    }

    function createHTLC(
        bytes32 htlcId,
        address receiver,
        uint256 amount,
        bytes32 hashLock,
        uint64  timeLock,
        bool    useSovereignLink
    ) external onlyRole(OPERATOR_ROLE) {
        require(htlcs[htlcId].sender == address(0), "HTLC esistente");
        require(receiver != address(0), "Receiver invalido");
        require(amount > 0, "Importo nullo");
        require(timeLock > block.timestamp, "TimeLock scaduto");

        htlcs[htlcId] = HTLC({
            sender: msg.sender,
            receiver: receiver,
            amount: amount,
            hashLock: hashLock,
            timeLock: timeLock,
            claimed: false,
            refunded: false,
            sovereignLink: useSovereignLink,
            wavesTxHash: bytes32(0)
        });

        emit HTLCCreated(htlcId, msg.sender, receiver, amount, hashLock, timeLock);
        if (useSovereignLink) {
            emit SovereignLinkEstablished(htlcId);
        }
    }

    function claimHTLC(bytes32 htlcId, bytes32 secret)
        external nonReentrant
    {
        HTLC storage h = htlcs[htlcId];
        require(!h.claimed && !h.refunded, "HTLC non attivo");
        require(keccak256(abi.encodePacked(secret)) == h.hashLock, "Secret non valido");
        require(block.timestamp <= h.timeLock, "TimeLock scaduto");
        require(msg.sender == h.receiver, "Non autorizzato");

        h.claimed = true;
        emit HTLCClaimed(htlcId, secret);
    }

    function relayT2Trigger(bytes32 htlcId, bytes32 t2TxHash)
        external onlyRole(T2_RELAYER_ROLE)
    {
        emit T2TriggerRelayed(htlcId, t2TxHash);
    }

    function linkWavesMultisig(bytes32 htlcId, bytes32 wavesTxHash)
        external onlyRole(MULTISIG_BRIDGE_ROLE)
    {
        htlcs[htlcId].wavesTxHash = wavesTxHash;
        emit WavesMultisigLinked(htlcId, wavesTxHash);
    }
}

8.5 SovereignIdentity.sol

SovereignIdentity.solsolidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/AccessControl.sol";

/**
 * @title SovereignIdentity
 * @notice Registro SSI per DID/VC secondo standard W3C.
 * Ogni utente mantiene il controllo della propria identità.
 */
contract SovereignIdentity is AccessControl {
    bytes32 public constant ISSUER_ROLE  = keccak256("ISSUER_ROLE");
    bytes32 public constant REVOKER_ROLE = keccak256("REVOKER_ROLE");

    struct DIDDocument {
        address owner;
        string  did;
        bytes32 publicKeyHash;
        uint64  created;
        uint64  updated;
        bool    active;
    }

    struct VerifiableCredential {
        bytes32 id;
        bytes32 didHash;
        bytes32 credentialHash;
        string  credentialType;
        uint64  issuedAt;
        uint64  expiresAt;
        bool    revoked;
    }

    mapping(bytes32 => DIDDocument) public dids;
    mapping(bytes32 => VerifiableCredential) public credentials;
    mapping(address => bytes32) public addressToDID;

    event DIDCreated(bytes32 indexed didHash, address indexed owner, string did);
    event DIDUpdated(bytes32 indexed didHash, bytes32 newPublicKeyHash);
    event DIDDeactivated(bytes32 indexed didHash);
    event CredentialIssued(bytes32 indexed vcId, bytes32 didHash, string credentialType);
    event CredentialRevoked(bytes32 indexed vcId);

    constructor(address admin) {
        _grantRole(DEFAULT_ADMIN_ROLE, admin);
        _grantRole(ISSUER_ROLE, admin);
        _grantRole(REVOKER_ROLE, admin);
    }

    function createDID(
        bytes32 didHash,
        address owner,
        string calldata did,
        bytes32 publicKeyHash
    ) external onlyRole(ISSUER_ROLE) {
        require(dids[didHash].created == 0, "DID già esistente");
        require(owner != address(0), "Owner invalido");

        dids[didHash] = DIDDocument({
            owner: owner,
            did: did,
            publicKeyHash: publicKeyHash,
            created: uint64(block.timestamp),
            updated: uint64(block.timestamp),
            active: true
        });
        addressToDID[owner] = didHash;

        emit DIDCreated(didHash, owner, did);
    }

    function issueCredential(
        bytes32 vcId,
        bytes32 didHash,
        bytes32 credentialHash,
        string calldata credentialType,
        uint64 expiresAt
    ) external onlyRole(ISSUER_ROLE) {
        require(dids[didHash].active, "DID non attivo");
        require(expiresAt > block.timestamp, "Scadenza non valida");

        credentials[vcId] = VerifiableCredential({
            id: vcId,
            didHash: didHash,
            credentialHash: credentialHash,
            credentialType: credentialType,
            issuedAt: uint64(block.timestamp),
            expiresAt: expiresAt,
            revoked: false
        });

        emit CredentialIssued(vcId, didHash, credentialType);
    }

    function revokeCredential(bytes32 vcId) external onlyRole(REVOKER_ROLE) {
        credentials[vcId].revoked = true;
        emit CredentialRevoked(vcId);
    }
}
◆ ◆ ◆

9. Compliance e AML/CFT

9.1 Quadro normativo

Normative di riferimento
NormativaRilevanza
TARGET GuidelineFinalità e irrevocabilità del regolamento
DLT Pilot RegimeAutorizzazione operatori DLT; il tetto massimo è stato elevato a EUR 100 miliardi
MiCAStablecoin, CASP, obblighi informativi; l’EBA ha pubblicato priorità di revisione a settembre 2026
AMLRApplicabile dal 10 luglio 2027
GDPRProtezione dati personali
D.Lgs. 231/2007Adeguata verifica clientela
D.Lgs. 194/2025Obblighi fiscali cripto-attività (DAC8)
eIDAS 2.0Identità digitale europea (EUDI Wallet)

9.2 AML/KYC – Procedura operativa

Soglie di adeguata verifica:

  • Operazioni occasionali ≥ 15.000 euro.
  • Trasferimenti di cripto-attività > 1.000 euro.
  • Sospetto di riciclaggio (qualsiasi importo).

Documentazione richiesta:

  • Persone giuridiche: atto costitutivo, visura camerale, documento identità legale rappresentante, UBO, PEP e sanctions screening.
  • Persone fisiche: documento identità, codice fiscale, fonte dei fondi, PEP e sanctions screening.
  • Integrazione SSI: DID sovrano + credenziali verificabili.

Conservazione: almeno 5 anni dalla fine del rapporto.

9.3 GDPR – Privacy by Design

  • On-chain: solo pseudonimi, hash, DID (quando necessario).
  • Off-chain: dati personali crittografati, KYC, documenti.
  • SSI: l’utente controlla i propri dati e decide cosa condividere.
  • Zero-knowledge proof: possibilità di dimostrare la conformità senza rivelare i dati.
  • InfinityWipe™: cancellazione verificabile dei dati quando richiesto.

10. Sicurezza e Gestione dei Rischi

10.1 Modello di sicurezza sovrano

Matrice rischio–mitigazione
RischioMitigazione sovrana
Compromissione validatoreHSM + MPC + rotazione chiavi + Sovereign Link isolation
ReentrancyOpenZeppelin + ReentrancyGuard + audit
Insufficienza riservaAudit + circuit breaker + Eclipse Protocol
Attacco informaticoMesh network + serverless + DNSSEC
Violazione privacySSI + zero-knowledge proof + minimizzazione on-chain
Dipendenza infrastruttura esternaData Center ACN + mesh network + dark fiber
Attacco quantisticoQuantum Sovereign Signature (QSS™)
CensuraSovereign Link Protocol + mesh network

10.2 Privacy by Design sovrana

  • On-chain: solo pseudonimi, hash, DID (quando necessario).
  • Off-chain: dati personali crittografati, KYC, documenti.
  • SSI: l’utente controlla i propri dati e decide cosa condividere.
  • Zero-knowledge proof: possibilità di dimostrare la conformità senza rivelare i dati.
  • InfinityWipe™: cancellazione verificabile dei dati quando richiesto.

11. Continuità Operativa e Disaster Recovery

Obiettivi di continuità operativa
ComponenteRTORPOMeccanismo sovrano
Rete DLT1 h0Sovereign Link + mesh failover
Registro Riserva2 h0Backup su Data Center ACN
API Gateway30 min5 minServerless routing
Custodia4 h0Custodi autorizzati + backup
SSI1 h0DID ledger + IPFS backup
Comunicazione15 min0Mesh network + LoRa

12. Roadmap di Implementazione

Fasi di implementazione del Pontes Veneto
FasePeriodoAttività principali
0 – PreparazioneQ4 2026Governance, legal opinion, validatori, SSI setup
1 – PoC / TestnetQ1 2027Testnet, DvP Hash-Link, Sovereign Substrate, mesh network
2 – PilotQ2–Q3 2027Operatori pilota, audit, integrazione T2, SSI rollout
3 – ProduzioneQ4 2027 – Q1 2028Go-live, monitoraggio 24/7, scaling validatori
4 – Evoluzione2028+Privacy layer, nuovi use case, piena capacità sovrana

13. KPI e SLA

Indicatori chiave di prestazione
KPITarget
Uptime rete≥ 99,9%
Finality DvP≤ 2 s
Finality T2T+0
Reserve ratio≥ 100%
Incident MTTR≤ 4 h
Audit findings chiusi30 gg
Soddisfazione operatori≥ 90%
Copertura SSI≥ 80% operatori
Resilienza mesh≥ 99,5%
Utilizzo utente finale≥ 100.000 wallet attivi

14. Modello Economico

Entrate

  • Contributi nodi validatori.
  • Fee di conversione cash token.
  • Fee servizi a valore aggiunto.
  • Finanziamenti istituzionali / regionali.
  • Servizi SSI e identità digitale.
  • Fee per transazioni utente finale (sopra 1.000 ZVD).

Costi

  • Infrastruttura (Data Center ACN, mesh network).
  • Custodia.
  • Audit.
  • Compliance.
  • Personale.
  • Sviluppo Sovereign Substrate.

Obiettivo: costo di settlement significativamente inferiore ai sistemi tradizionali, con piena sovranità tecnologica.

15. Conclusioni e Visione 2028

Il Pontes Veneto v5.0 – Architettura Sovrana Integrata per il Regolamento all’Ingrosso e l’Utilizzo Quotidiano rappresenta l’evoluzione finale dello Zecchino Veneto Digitale: un sistema che coniuga la stabilità e la fiducia della moneta di banca centrale con l’autonomia, la resilienza e l’autodeterminazione di un ecosistema digitale territorialmente radicato, ora accessibile anche all’utente finale persona fisica.

L’integrazione di Sovereign Substrate, Sovereign Constitution Fabric, Sovereign Link Protocol, Self-Sovereign Identity e Multisig EnvLab trasforma il Pontes Veneto da infrastruttura di regolamento a piattaforma di sovranità digitale al servizio del Veneto e dei suoi cittadini.

Il valore 1:1 con l’Euro, stabilito per decisione del Governatore del Banco Nazionale Veneto, garantisce stabilità e fiducia per tutti gli attori dell’ecosistema, dalle istituzioni finanziarie ai cittadini.

Visione 2028

Un Veneto dotato di infrastruttura digitale sovrana, capace di regolare transazioni all’ingrosso in moneta di banca centrale, di tutelare la privacy dei propri cittadini, di resistere a interruzioni infrastrutturali e di preservare la propria autonomia in un contesto europeo integrato.

Franco Paluan
Autore · Pontes Veneto v5.0
◆ ◆ ◆

Pontes Veneto v5.0 — Implementazione Integrata, Innovativa e Semplificata

Dalla Visione alla Realtà Operativa
Autore: Franco Paluan · Data: Settembre 2026 · Versione: 5.0 — Edizione Operativa Integrata · Classificazione: Documento Tecnico-Istituzionale

1. Cos’è Pontes Veneto in una pagina

Pontes Veneto è l’infrastruttura digitale sovrana del Veneto che unisce due mondi:

Confronto tradizionale vs Pontes Veneto
DimensioneTradizionalePontes Veneto
Pagamenti grandiBonifici bancari lenti e costosiRegolamento in 2 secondi con moneta di banca centrale
Pagamenti piccoliPOS, contanti, carte con commissioniWallet personale senza commissioni fino a 1.000 ZVD
IdentitàDocumenti fisici, credenziali multipleIdentità digitale sovrana (SSI) con controllo dell’utente
Consorzi e filiereCasse comuni con firme multiple cartaceeMultisig digitale su blockchain Waves
RiservaFiducia nella bancaTriplo ancoraggio: CeBM + Oro + Capitale Regionale

In tre parole: veloce, sicuro, sovrano.

2. I cinque pilastri operativi

01

Valore stabile 1:1 con l’Euro

Per decisione del Governatore del Banco Nazionale Veneto.

02

Regolamento atomico

Titolo e pagamento si scambiano contemporaneamente, senza rischio.

03

Identità sovrana

L’utente controlla i propri dati, non il sistema.

04

Interoperabilità totale

Dialoga con banche (T2), consorzi (Waves), pubblica amministrazione (PagoPA).

05

Resilienza by design

Funziona anche in caso di interruzioni infrastrutturali.

3. Lo stack in sei livelli (spiegato semplice)

LIVELLO 5 — QUELLO CHE VEDI Wallet · Pagamenti QR · Servizi pubbliciLIVELLO 4 — QUELLO CHE TI IDENTIFICA Identità sovrana (SSI) · Bridge WavesLIVELLO 3 — QUELLO CHE DECIDE Regole automatiche (Sovereign Substrate)LIVELLO 2 — QUELLO CHE REGISTRA Blockchain Pontes (Hyperledger Besu)LIVELLO 1 — QUELLO CHE SOSTIENE Data Center ACN · T2 RTGSLIVELLO 0 — QUELLO CHE INTEGRA Multisig EnvLab (blockchain Waves)

4. Analogia quotidiana

Immagina Pontes Veneto come un sistema autostradale digitale:

  • Autostrade = T2 RTGS (pagamenti grandi tra banche)
  • Strade provinciali = DLT Pontes (pagamenti quotidiani)
  • Caselli intelligenti = Smart contract (verificano e autorizzano)
  • Patente digitale = SSI (identità sovrana)
  • Polizia stradale = Compliance automatizzata
  • Riserva di emergenza = Triplo ancoraggio (CeBM + Oro + Regione)

5. Avvio rapido: 5 passi per iniziare

Passo 1 — Ambiente di sviluppo

Setup ambientebash
# Clona il repository ufficiale
git clone https://github.com/pontes-veneto/core.git
cd core

# Installa le dipendenze
npm install

# Configura l'ambiente
cp .env.example .env
# Modifica .env con le tue chiavi

Passo 2 — Configurazione minima

.envenv
PONTES_NETWORK=testnet
PONTES_CHAIN_ID=8140
PONTES_RPC_URL=https://rpc-testnet.pontesveneto.eu
WAVES_NODE_URL=https://nodes-testnet.wavesnodes.com
BANCO_VENETO_API=https://api.banconevento.eu/v1

Passo 3 — Deploy dei contratti core

Deploybash
# Compila e distribuisci i contratti Solidity
npx hardhat compile
npx hardhat run scripts/deploy.js --network pontes-testnet

# Output atteso:
# ZVDToken deployed at: 0x...
# ZecchinoVenetoDvP deployed at: 0x...
# SovereignIdentity deployed at: 0x...

Passo 4 — Prima transazione

quickstart.tstypescript
import { PontesClient } from '@pontes-veneto/sdk';

const client = new PontesClient({
  rpcUrl: 'https://rpc-testnet.pontesveneto.eu',
  chainId: 8140
});

async function primaTransazione() {
  // 1. Crea o importa un wallet
  const wallet = await client.createWallet();
  console.log('Wallet:', wallet.address);

  // 2. Collega l'identità sovrana
  await wallet.linkSovereignDID({
    jurisdiction: 'IT-VE',
    credentialType: 'Citizen'
  });

  // 3. Ricevi 100 ZVD di benvenuto (solo testnet)
  await client.faucet.request(wallet.address, 100);

  // 4. Effettua un pagamento
  const tx = await wallet.pay({
    to: '0x742d35Cc6634C0532925a3b8444Bc9e7595f0bEb',
    amount: 25.50,
    memo: 'Caffè e brioche'
  });

  console.log('Transazione completata in', tx.finalityMs, 'ms');
}

Passo 5 — Integrazione con il wallet multisig

Autore

Torna in alto