TRUST ARCHITECTURE
Trust here isn't a promise. It's a set of architectural decisions.
"Trustworthy" is easy to say. Instead, this page shows exactly why a report can't be edited after the fact, why one account can never see another's data, and why an amount can't quietly vanish to a rounding error -- at the database level.
At Lancerix, trust doesn't rest on the application code behaving well -- it rests on Postgres itself refusing certain operations outright: an unauthorized row cannot be read, a signed record cannot be deleted, a monetary amount can never be stored as a decimal. This page walks through where and how each of those constraints is actually enforced.
Money never exists as a decimal, anywhere
Every amount is an integer of the smallest currency unit (kuruş), never a float. Rates are stored as basis points (1000 = 10.00%). This removes the classic floating-point failure mode -- 0.1 + 0.2 not quite equaling 0.3 -- from money math entirely.
The platform fee is computed from the amount added on top of what the client pays, not subtracted from the freelancer's earnings; the client's charge and the freelancer's net payout are both derived from one gross amount by subtraction, never by a second percentage calculation -- so the two sides can never end up disagreeing about the total.
This logic isn't written twice in two languages that can drift apart: the TypeScript calculation function and Postgres's own generated columns apply the identical rounding rule (half away from zero) and are checked against each other by automated tests.
A status can only change through one door
A delivery's or a payment milestone's status can change from exactly one database function, never from anywhere in the application code directly. Which status can move to which is defined in its own table; an undefined transition is rejected by the database itself.
That function writes the status change and the ledger row explaining it inside the same database transaction -- a request that fails partway through can never leave a status change with no record of why it happened.
A trigger rejects any status update attempted outside that function -- even a bug in the application code cannot bypass the rule, because the database enforces it independently.
The ledger is append-only, full stop
Every status change and every verification report is written to a permanent ledger. Those tables have no UPDATE or DELETE policy at all -- backed by a separate trigger that blocks it outright. That includes the platform's own admin account.
A verification report's cryptographic digest (SHA-256) is tamper-evident proof of exactly what text that report contained -- if the report were ever "corrected" after the fact, the digest would no longer match, and that mismatch is immediately visible. This is not a blockchain: instead of a distributed network, it's an immutability guarantee enforced at the database level by one trusted party (Lancerix) -- but the guarantee itself is real, not a marketing flourish.
Access is enforced in the database, not the application
Row Level Security is on for every table, no exceptions. A freelancer can only see their own records, a client only theirs -- not because the application code happens to write a correct query, but because Postgres itself filters every query against that rule.
The practical effect: even if the application layer had an authorization bug (a wrong query, a missing check), the database still would not return an unauthorized row. Authorization is enforced in exactly one place, exactly one way.
Identity fields are validated the moment they're written
Turkish national ID (11 digits) and tax ID (10 digits) fields are checksum-validated against their official algorithms, both in the browser and again when written to the database. A random 11-digit number cannot be saved into the system.
Frequently asked
Is this a blockchain?
No. A blockchain is a distributed system that lets many mutually-untrusting parties agree on one shared record. Lancerix has one trusted party (its own database); the immutability guarantee comes from that database's own access rules and cryptographic digests, not from distributed consensus. It's a simpler system, but a real and independently verifiable guarantee.
Have you had an independent security audit?
Not yet. The architecture described on this page has so far been maintained through our own internal discipline and code review. An independent third-party audit is a concrete step we plan to take before Faz 2 (real fund custody) is in scope.
How does this architecture extend into Faz 2 (escrow)?
The same three principles -- integer-only currency, single-door state machines, an append-only ledger -- carry directly over to escrow account balances. Faz 2 doesn't invent a new trust model; it extends the one already proven in Faz 1 to real fund movement.
Can I review the source code?
Not at this time -- the source is closed. This page exists to describe, as concretely as possible without the code itself, exactly which decisions and guarantees the architecture contains.
Want to see the mechanism live?
Look at an example verification report, or set up a contract yourself and try the whole flow.