D Deedmint
dev · chain 31337

A registry of record for tokenised Indian real estate.

Ownership is recorded on-chain and verifiable by anyone. Money never touches the chain — subscriptions, rent and exits all move in INR through bank rails, and the registry records the consequence.

The chain is a registry of record, not a settlement layer.

It answers “who owns this, and what happened to it?” It never moves money. One tokenised property lives on exactly one chain, and there is one registry write per settled trade — money moves first, the record follows.

Live status

API
checking…
 
Environment
 
Control level
reads are never blocked
Database
 

Served live from /health. The control plane’s write routes (pause, resume, renew) are not reachable from the public internet — they are unauthenticated by design until the capability layer lands, so nginx refuses them outright.

What is actually built

LayerStateEvidence

Schema & controls

11 migrations · 27 tables · append-only history

Verified db:verify — 12 probes
all controls fire

Solidity contracts

7 contracts, immutable — no proxies

Tested forge test — 24 passed
replay guard reverts

Registry & indexer

checkpointed, single-instance, DB-leased

Running deployed to the dev chain
checkpoint advancing

Settlement & custody

orchestrator, escrow ledger, HSM signing

Not started Phase 1 remainder

Real money · real users

INR rails, KYC, consent architecture

Blocked launch gate 0 of 12

The boundary that must hold

No real users. No real personal data. No real money.

Consent cannot be collected retroactively. If one real PAN number entered this system before the consent architecture existed, that processing was unlawful at the moment it happened, and no later change fixes it. Everything here runs on synthetic identities and a local development chain.

This deployment exists so the engineering can be exercised end to end. It is not open for investment, it holds no client funds, and it is not an offer of any security.

Before mainnet — 12 gates, 0 passed

01Legal classification settled — SEBI Path A or Path BOpen
02Security audit complete, findings closedOpen
03Escrow / nodal bank account liveOpen
04Contracts deployed to mainnet, bytecode verifiedOpen
053-of-5 multisig composed and rehearsedOpen
06Custody path operational — keys in HSM, never in envOpen
0730 consecutive clean reconciliation daysOpen
08Backup and restore drilled on a clean hostOpen
09Kill switch drilled, both directionsOpen
10Monitoring and on-call liveOpen
11Legal documents and consent architecture liveOpen
12Operational runbooks rehearsedOpen

Every gate must pass. There is no partial credit and no override. Mainnet is a fresh genesis, not a data promotion — testnet records are discarded deliberately and properties are re-registered from verified legal records.

The controls that must not break

Four eyes, two layers

A database CHECK refuses a self-approved batch, and a 3-of-5 multisig holds the operator role. Two controls, two threats — neither substitutes for the other.

Idempotent settlement

One batch id is simultaneously the queue job id, a Postgres unique constraint, and an on-chain replay guard. A retry is safe at every layer.

Append-only history

The audit log, consent records, ledger entries and chain events refuse UPDATE and DELETE at the database level, not in application code.

Single-instance indexer

Two indexers on one checkpoint would skip ownership events silently. A database lease enforces it, so a config drift cannot defeat it.

Reads are never blocked

At every control level, including a full freeze, an investor can still see their own holdings. A hard rule, not a policy choice.

Immutable contracts

No proxies and no admin who can rewrite ownership. Changing a contract means an explicit, auditable, four-eyed migration.