

ZVD – Pontes Veneto v5.0 Architettura Sovrana Integrata per il Regolamento all’Ingrosso e l’Utilizzo Quotidiano
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:
| Dimensione | ZVD v4.1 | Pontes Veneto v5.0 |
|---|---|---|
| Modello di riserva | CeBM + riserva reale + capitale sovrano | CeBM + riserva reale + capitale sovrano |
| Regolamento | Doppio binario (cash token + T2) | Doppio binario + Hash-Link Protocol sovrano |
| Interoperabilità | Hash-Link Protocol | Hash-Link + Multisig EnvLab (Waves) |
| Governance | Allineata a Pontes MCG / MIB | + Assemblea dei Nodi Sovrani |
| Accesso | Banche, CSD, operatori DLT, CCP | + Utenti finali (persone fisiche) |
| Identità | Pseudonimi e hash | + Self-Sovereign Identity (SSI) |
| Valore | Ancorato a CeBM | 1:1 con l’Euro (decisione del Governatore del Banco Nazionale Veneto) |
| Resilienza | DR tradizionale | + Sovereign Link Protocol (serverless) |
1.2 Principi guida allineati a Pontes
- Mantenere la moneta di banca centrale come ancora di un sistema monetario a due livelli.
- Raggiungere l’autonomia strategica e una maggiore resilienza per i pagamenti europei.
- Promuovere un ecosistema di pagamenti integrato, competitivo e innovativo.
- Supportare il ruolo internazionale dell’euro.
- 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
2.2 Componenti principali (allineati a Pontes)
Il Pontes Veneto è costruito attorno a tre componenti principali, esattamente come il Pontes dell’Eurosistema:
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.
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.
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:
- Setup: il venditore genera secret, calcola H(secret), lo registra on-chain.
- Verifica SSI: il compratore autentica la propria identità sovrana tramite DID/VC.
- Lock: il compratore blocca i fondi condizionati alla rivelazione del secret.
- Compliance check: il Sovereign Substrate verifica la conformità dell’operazione.
- Reveal: il venditore rivela il secret entro il timeLock.
- Settle: i fondi sono trasferiti atomicamente.
- 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
| Attivo | Haircut | Limite | Ruolo |
|---|---|---|---|
| Moneta di banca centrale | 0% | 100% | Riserva primaria — regolamento |
| Oro fisico LBMA | 5–10% | 40% | Riserva sussidiaria |
| Titoli di Stato area euro | 2–5% | 30% | Riserva sussidiaria |
| Depositi bancari garantiti | 0–2% | 20% | Liquidità operativa |
| Capitale sovrano regionale | 0% | 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
| Organo | Composizione | Funzione |
|---|---|---|
| Assemblea dei Nodi Sovrani | Validatori + enti territoriali + università | Approva la costituzione digitale, le modifiche allo Standard 817 |
| Comitato Tecnico-Istituzionale | 5–7 membri indipendenti | Strategia, parametri, upgrade |
| Comitato Rischi | Risk, compliance, audit | Monitoraggio riserva, limiti, incidenti |
| Segreteria Tecnica | Direttore operativo + staff | Esecuzione decisioni, reporting |
| Registro Centrale di Riserva | Custode + tesoreria | Mint, burn, custodia, attestazioni |
| Arbiter Node | Comitato di Garanzia | Contenziosi, emergency cancel |
| Auditor Indipendente | Società esterna | Audit riserve, codice, sicurezza |
| Agenzia Sovrana per l’Innovazione (NASI) | Consiglio scientifico | Supervisione algoritmi, etica digitale |
| Governatore del Banco Nazionale Veneto | Nominato dall’Assemblea | Stabilisce 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
| Fase | Azione | Strumento |
|---|---|---|
| 1. Registrazione | Creazione identità sovrana (DID) | Wallet ZVD / SSI |
| 2. Verifica | KYC semplificato per persone fisiche | Sportello bancario o app |
| 3. Attivazione | Apertura conto | Wallet ZVD sovrano |
| 4. Utilizzo | Pagamenti, trasferimenti, risparmio | App 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
| Funzione | Descrizione |
|---|---|
| Saldo | Visualizzazione in ZVD ed Euro (1:1) |
| Pagamento QR | Scansione e invio |
| Trasferimento | Invio a contatti o IBAN ZVD |
| Storico | Transazioni con marca temporale |
| Convertibilità | Cambio ZVD ↔ Euro presso sportelli |
| Sicurezza | Biometria, PIN, backup seed |
| SSI | Gestione 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
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-transactionsper la creazione e firma di transazioni multisig. - Smart contract Waves per la logica di autorizzazione.
7.2 Setup del progetto
# 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 chiavi7.3 Creazione di un wallet multisig per un consorzio di filiera
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
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
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
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
# 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 && fee0k7.8 Onboarding semplificato per l’utente finale
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
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
| Aspetto | Implementazione |
|---|---|
| Gestione seed | Cifratura AES-256, backup su hardware |
| Multisig | Quorum 2/3 per consorzi, 3/5 per operazioni critiche |
| TimeLock | 48 ore per transazioni superiori a 10.000 ZVD |
| Audit | Log immutabile di ogni operazione |
| Recovery | Procedura di recupero con verifica biometrica |
| Compliance | KYC/AML integrato con il Banco Nazionale Veneto |
8. Smart Contract Suite
8.1 Contratti previsti
| Contratto | Funzione | Integrazione sovrana |
|---|---|---|
| ZVDToken | ERC-20 con mint/burn controllati, freeze, pause | Compliance check via Sovereign Substrate |
| OperatorRegistry | Whitelist operatori, KYC hash, limiti | SSI integration per autenticazione |
| ZVDReserveOracle | Attestazioni di riserva | Merkle Review System per verifica |
| ZVDGovernance | Timelock + multisig | Standard 817 compliance |
| ZecchinoVenetoDvP | DvP Hash-Link | Trusted Oracle sovrano (NASI) |
| BridgeHTLC | Interoperabilità RTGS | Sovereign Link Protocol |
| SovereignIdentity | SSI registry per DID/VC | Integrazione con wallet sovrani |
8.2 ZVDToken.sol — Integrazione sovrana
// 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)
// 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)
// 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
// 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
| Normativa | Rilevanza |
|---|---|
| TARGET Guideline | Finalità e irrevocabilità del regolamento |
| DLT Pilot Regime | Autorizzazione operatori DLT; il tetto massimo è stato elevato a EUR 100 miliardi |
| MiCA | Stablecoin, CASP, obblighi informativi; l’EBA ha pubblicato priorità di revisione a settembre 2026 |
| AMLR | Applicabile dal 10 luglio 2027 |
| GDPR | Protezione dati personali |
| D.Lgs. 231/2007 | Adeguata verifica clientela |
| D.Lgs. 194/2025 | Obblighi fiscali cripto-attività (DAC8) |
| eIDAS 2.0 | Identità 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
| Rischio | Mitigazione sovrana |
|---|---|
| Compromissione validatore | HSM + MPC + rotazione chiavi + Sovereign Link isolation |
| Reentrancy | OpenZeppelin + ReentrancyGuard + audit |
| Insufficienza riserva | Audit + circuit breaker + Eclipse Protocol |
| Attacco informatico | Mesh network + serverless + DNSSEC |
| Violazione privacy | SSI + zero-knowledge proof + minimizzazione on-chain |
| Dipendenza infrastruttura esterna | Data Center ACN + mesh network + dark fiber |
| Attacco quantistico | Quantum Sovereign Signature (QSS™) |
| Censura | Sovereign 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
| Componente | RTO | RPO | Meccanismo sovrano |
|---|---|---|---|
| Rete DLT | 1 h | 0 | Sovereign Link + mesh failover |
| Registro Riserva | 2 h | 0 | Backup su Data Center ACN |
| API Gateway | 30 min | 5 min | Serverless routing |
| Custodia | 4 h | 0 | Custodi autorizzati + backup |
| SSI | 1 h | 0 | DID ledger + IPFS backup |
| Comunicazione | 15 min | 0 | Mesh network + LoRa |
12. Roadmap di Implementazione
| Fase | Periodo | Attività principali |
|---|---|---|
| 0 – Preparazione | Q4 2026 | Governance, legal opinion, validatori, SSI setup |
| 1 – PoC / Testnet | Q1 2027 | Testnet, DvP Hash-Link, Sovereign Substrate, mesh network |
| 2 – Pilot | Q2–Q3 2027 | Operatori pilota, audit, integrazione T2, SSI rollout |
| 3 – Produzione | Q4 2027 – Q1 2028 | Go-live, monitoraggio 24/7, scaling validatori |
| 4 – Evoluzione | 2028+ | Privacy layer, nuovi use case, piena capacità sovrana |
13. KPI e SLA
| KPI | Target |
|---|---|
| Uptime rete | ≥ 99,9% |
| Finality DvP | ≤ 2 s |
| Finality T2 | T+0 |
| Reserve ratio | ≥ 100% |
| Incident MTTR | ≤ 4 h |
| Audit findings chiusi | 30 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.
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:
| Dimensione | Tradizionale | Pontes Veneto |
|---|---|---|
| Pagamenti grandi | Bonifici bancari lenti e costosi | Regolamento in 2 secondi con moneta di banca centrale |
| Pagamenti piccoli | POS, contanti, carte con commissioni | Wallet personale senza commissioni fino a 1.000 ZVD |
| Identità | Documenti fisici, credenziali multiple | Identità digitale sovrana (SSI) con controllo dell’utente |
| Consorzi e filiere | Casse comuni con firme multiple cartacee | Multisig digitale su blockchain Waves |
| Riserva | Fiducia nella banca | Triplo ancoraggio: CeBM + Oro + Capitale Regionale |
In tre parole: veloce, sicuro, sovrano.
2. I cinque pilastri operativi
Valore stabile 1:1 con l’Euro
Per decisione del Governatore del Banco Nazionale Veneto.
Regolamento atomico
Titolo e pagamento si scambiano contemporaneamente, senza rischio.
Identità sovrana
L’utente controlla i propri dati, non il sistema.
Interoperabilità totale
Dialoga con banche (T2), consorzi (Waves), pubblica amministrazione (PagoPA).
Resilienza by design
Funziona anche in caso di interruzioni infrastrutturali.
3. Lo stack in sei livelli (spiegato semplice)
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
# 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 chiaviPasso 2 — Configurazione minima
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/v1Passo 3 — Deploy dei contratti core
# 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
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');
}
