DarkLedger: Precision Payroll Infrastructure
💀 The Inspiration: The Floating Point Ghost
In the world of Web3 and modern SaaS, we have forgotten the old gods. We build financial systems on JavaScript and Python, languages that rely on IEEE 754 floating-point arithmetic.
In a standard modern environment, simple addition can yield terrifying results due to binary approximation errors:
In a payroll run of $10,000,000, these "micro-pennies" accumulate. In the traditional banking world, this leads to audit failures. In the crypto world, where transactions are immutable, this leads to irreversible financial loss.
We asked ourselves: "What if we brought the dead back to life to save the future?"
⚡ What It Is
DarkLedger (formerly Ledger-De-Main) is a "Frankenstein" architecture. We stitched together the oldest, most reliable financial engine (COBOL) with the newest, fastest settlement layer (Base L2).
We refuse to modernize the math. We run the core payroll logic in a compiled COBOL binary—the same technology that powers 95% of the world's ATM swipes—ensuring 100% decimal precision. We then "stitch" this brain to a Python nervous system that executes payouts on the blockchain.
🏗 How We Built It (The Architecture)
We utilized Kiro's Agentic IDE to bridge two incompatible eras of computing.
- The Brain: COBOL (Legacy Core)
We generated a GnuCOBOL program using Vibe Coding. This component handles the Gross-to-Net logic using Fixed-Point Arithmetic.
Unlike floating point, our COBOL engine treats money as integers scaled by a power of 10. For a value ( V ), stored as an integer ( I ):
This ensures that our tax calculations (15% Federal, 5% State) are exact:
- The Stitch: Python & Agent Hooks
The biggest challenge was connecting a modern JSON-based frontend to a legacy binary that expects fixed-width text files.
We used Kiro Agent Hooks to automate the "Stitching" process.
The Hook: On every save of payroll.cbl, Kiro parses the DATA DIVISION, extracts the byte positions (e.g., PIC X(10)), and auto-generates a Python struct parser.
The Interface:
Input: 23 Bytes (Employee ID, Hours, Rate, Tax Code)
Output: 60 Bytes (ID, Gross, Taxes, Net, Status)
- The Hands: Settlement on Base
Once the math is verified by the "Brain," the "Body" (Python) uses the Coinbase CDP SDK to convert the Net Pay into a USDC transaction on the Base L2 network.
🧟♂️ Challenges & Lessons Learned
Challenge 1: The Language Barrier COBOL does not speak JSON. It speaks Bytes. Lesson: We learned that modern ease-of-use has made us lazy with data types. We had to build a rigid byte-level contract (defined in our design.md spec) to ensure Python didn't send garbage to the mainframe. Challenge 2: Containerizing a Monster Running COBOL in the cloud isn't standard. Lesson: We built a custom Docker container that acts as a time machine. It installs a lightweight Linux OS, pulls the gnucobol compiler dependencies, compiles the legacy code on build, and then spins up a modern FastAPI server to listen for requests. Challenge 3: "Audit-Proofing" We learned that "close enough" isn't good enough for payroll. By enforcing Banker's Rounding in COBOL (COMPUTE ROUNDED), we achieved a level of precision that standard JavaScript libraries struggle to replicate without heavy dependencies.Click to expand our learnings
🚀 Usage
- Run the Container
docker build -t ledger-de-main .
docker run -p 8000:8000 --env-file .env ledger-de-main
- Execute Payroll
Navigate to our Retro-Terminal UI and execute a batch command:
RUN PAYROLL --BATCH 2025-10-31
The system will:
Generate a fixed-width input.dat.
Spawn a subprocess to run cobol/bin/payroll.
Read the output.rpt.
Execute a gasless USDC transfer on Base.
📜 Kiro Implementation Details
Specs: Used requirements.md to define the 23-byte input constraint.
Steering: Enforced a "Sacred Timeline" rule in .kiro/steering/tech.md that forbade refactoring COBOL logic into Python.
Hooks: Automated the binary compilation and Python model updates.
Built with 💚 (and 🧟♂️) for Kiroween 2025
Top comments (0)