PIER.PRG
WHAT IT IS.
A permissioned-blockchain platform for regulatory data exchange between Brazilian financial-system regulators. PIER was the second project of the bank's Innovation Lab — a small team of IT analysts chartered in 2016 to study new technologies pragmatically by building proofs of concept against real institutional use cases. DLT was the first subject elected, and SALT had already mapped out where a Raft/BFT-style permissioned chain helps (audit-trail use cases) and where it doesn't (privacy + audit + liquidity all at once — the "triangular issue"). PIER was the team's deliberate move into the audit-trail territory, on a use case that fit cleanly.
The use case surfaced sideways: a colleague from the regulator-authorization process asked the DLT team whether a permissioned chain could replace a manual, paperwork-driven information exchange between the Central Bank, SUSEP and CVM — specifically, the processo autorizativo, where a bank needs Central Bank approval to appoint a new director and the regulator must verify the candidate's disciplinary and fraud history with the other agencies. The shape of that use case matched DLT almost exactly: data is immutable (history isn't editable), data must be authenticated and non-repudiable (no agency can disclaim what it recorded), and the institutions have no clean hierarchy (each is an autarchy; choosing any of them as the central coordinator is itself a political problem). The canonical solution to inter-agency integration is a shared database with a host agency. PIER deliberately rejected that.
THE ARC.
PIER replaces the shared database with three things working together: a permissioned Quorum chain that holds catalogs, templates, requests and responses; a REST API server that proxies everything so users never deal with contracts directly; and metadata, not data, as the unit of sharing. The decision to share metadata was the architectural turn. Instead of designing a common schema and copying records into a central store, each agency publishes a catalog that describes which data services it makes available and how they can be called. Templates built from those catalogs become requests; the chain records each request and, once each responding node has returned its part, the request closes. Smart contracts are the small surface and the bulk of the codebase is the deploy tree and the API server, which runs the node's listener and its local agent in the same process.
The local agent is the seam that made the use case buildable. Smart contracts on a permissioned chain don't reach outside the ledger, and external oracles were a non-starter for this design. The team's answer was a per-node agent that watches new requests on the chain, decides whether this node is responsible for any part of the request, fetches the answer from a local data service (Olinda, an internal BCB product that exposes relational databases as ODATA endpoints, made the database layer infrastructure-agnostic), and writes the response back into the request contract. The agent never connects to corporate databases directly — only to web services. That is what made PIER minimally intrusive in the working definition the team settled on: each agency exposes the data it chooses, behind the firewall it chooses, and the chain only sees signed requests and signed responses.
Privacy came in stages. The first version stored responses on-chain in the clear, which made them public to every node in the network. Quorum Constellation was added later so that responses could be encrypted with the requestor's public key — once a node has contributed its part, only the originator of the request can read it. This was the second iteration's headline change.
WHAT I LEARNED.
Sharing metadata instead of data is the actual architectural lever. As long as each agency exposes a useful service over the firewall, no single schema has to be agreed on by all participants, and the chain can stay narrow.
Local agents beat oracles for regulator-grade deployments. The agent lives inside each institution's network, speaks to its services in their own protocol, and never touches corporate databases. The chain only sees the agent's signed writes.
The contracts are the small surface; the deploy tree, genesis, and WSS configuration eat the calendar. In a permissioned deployment the audit trail is the deliverable — RBAC, registry, admin-change-by-consensus, and existence-checks land before any business logic for that reason.
Privacy is a property of the message, not the channel: Constellation moved PIER from "every node can read every response" to "only the requestor can read its own requests' responses" without changing the contracts.