From regulatory data sharing to a classroom game
The exploration at the Central Bank of Brazil moved from payments to a quieter question: could a permissioned chain serve as the spine of a regulator-grade data exchange between agencies? That second question became the brief for PIER — Plataforma Integrada de Informações entre Entidades Reguladoras — a prototype built to find out whether an immutable register, paired with the right access rules, could let regulators share supervisory data without losing who saw what, when, and under whose authority.
I worked on PIER with BCB colleagues; the devlog preserves the shared authorship. The prototype ran on Quorum, initially with Raft consensus and later reconfigured for Byzantine fault tolerance. A Truffle pipeline deployed the contracts, a TypeScript layer served a REST API, and an Angular client closed the loop in the browser. NGINX terminated the secure websockets; Newman ran the load tests. The contracts split the work four ways: RegistryContract recorded who could do what, CatalogContract defined the data shapes, TemplateContract declared the request definitions, and a RequestResponse contract tracked each request through its lifecycle. A docker_artifacts/ directory carried the npm modules that could not run their install scripts over the bank's network. The public archive lives at gitlab.com/bacen/pier.
PUTTING A SYSTEM IN FRONT OF STUDENTS
Later in 2018 I was invited to teach an extension course at IESB, in Brasília, on blockchain use cases — twenty-four hours of class, with the freedom to choose the syllabus. The subject was young enough that surveying what people were actually doing with it took about two hours, and there were not many projects to survey. That left twenty-two hours to fill.
I filled them with a long-held belief: videogames are the most complex type of software one can write, and a game can absorb almost any subject without strain. So the syllabus became the post mortem of a multiplayer Monopoly clone, written as a full-stack dApp. Every move on the board was an invitation to ask the right Web3 question — where does the rule live, what changes when the action reaches the ledger, who is allowed to act, and what does the transaction prove after the fact? The artifact was Chainopoly; the source code of a videogame became the textbook.
The build ran from October 2018 to January 2019, ninety-two commits, my own solo work, overlapping the teaching run. An Angular 6 client talked to a Tornado (Python 3) game server whose engine read the board from JSON. The Solidity side held Game.sol, ChainopolyCoin.sol, ChainopolyProperties.sol, Property.sol, and an AtomicSwap contract for trades between players. Splitting the project into a rule-and-ledger boundary gave the class something to argue about every week: rent becomes a transfer, a deed becomes a token, a swap either succeeds as a whole or it does not. The course deck for the same class (Implementando casos de uso utilizando blockchain) is in the slides archive; the slides themselves stay outside this site, by design.
The pattern that produced both projects is the one I keep coming back to in these pages: I take on the artifact that forces me to understand a system end to end, because I cannot stand in front of a room — or sit an exam — and hand-wave through the part I skipped. Chainopoly was the way I learned Solidity and Truffle, just as PIER was the way the team learned what a permissioned chain would and would not buy a regulator. The classroom was the deadline; the prototype was the textbook.