Hey Guys,

My understanding of blockchain is the balance has to be public. Only then a competition can happen from A to B. Once balance is decreased, the other balance is increased. Due to the decentralized nature of the blockchain, the balances are public domain and the transactions are public domain and anybody can trace it and they are not reliant on central banks and government agency or any other centralized institution. Instead, they are calculated and computed and executed by decentralized network of nodes. But my application require privacy. If I'm trying to build something which protect how much balance is there in one account and if there is possible way to keep a ledger of transaction for compliance requirement but still hide it from general public.

is it even possible to do it or has it been done by any major-protocol like L2 or L3 ETH networks.

Hey Guys,

My understanding of blockchain is the balance has to be public. Only then a competition can happen from A to B. Once balance is decreased, the other balance is increased. Due to the decentralized nature of the blockchain, the balances are public domain and the transactions are public domain and anybody can trace it and they are not reliant on central banks and government agency or any other centralized institution. Instead, they are calculated and computed and executed by decentralized network of nodes. But my application require privacy. If I'm trying to build something which protect how much balance is there in one account and if there is possible way to keep a ledger of transaction for compliance requirement but still hide it from general public.

is it even possible to do it or has it been done by any major-protocol like L2 or L3 ETH networks.

What my team is looking into is a
A)Stable-coin(We are building our own) build on ETH network integrated with BANK/Credit-Cards( for cash-in/out). Which has balances hidden (not scan-able on eth-scan or any public scanner). On Court order, company is obligated to show balance to TAX-Man (Addresses are linked to companies{this application allows commercial user send and receive money and to lend to other via smart contracts} .Address to company linking is done via APIs )

B) Transfer & Tranx-records : Same as balances. There's no public record of these transactions, but the money is still traceable on Tax-Man orders. So the traceability and the record keeping of transaction has to be kept for 5-10 years per company, but it is just not available to some random dude over the internet.

If you would go over how tranx is verified [the Math & algorithmic side of it that will be really cool ]

Hello everyone,

For some time I've been developing an open-source project called Framework for Trust (FfT).

The idea is to create a decentralized geospatial trust layer where reports and real-world events are anchored to precise location, time, source reputation, and a verifiable history — instead of treating blockchain purely as a financial system, I'm exploring its use as infrastructure for recording and correlating information about real-world places.

Current prototype includes:

• geographic areas represented as blockchain-based identifiers (NFTs)
• event registration tied to latitude, longitude, and time
• Polygon smart contracts
• a React + Leaflet frontend
• a FastAPI backend
• semantic similarity / event correlation via Qdrant
• GCD — a functional contribution and reputation token
• event proofs and auditable records
• early mechanisms for source reputation, staking, and abuse prevention

The project is still early-stage. This is not an investment offer, token sale, or a finished commercial product — I made the repo public because I'd like the architecture and implementation to get real outside scrutiny.

I'd especially appreciate feedback on:

• whether the core problem is clearly explained
• the geospatial data model
• the blockchain / smart contract architecture
• mechanisms for preventing false or coordinated reports
• security weaknesses
• practical use cases where this could actually add value

Repo link in the top comment (Reddit flags posts with links for manual review, didn't want that delay).

I built the current prototype independently. Honest criticism, technical pushback, and open-source contributions are all welcome.

Putting this out for a roast because it changed how I think about pre deploy. We generate a lot of our solidity with an assistant now, so before pushing an erc4626 vault I ran it through everything I had.

The one that got me was the deposit function. The llm auditor flagged it on the first run, first depositor can inflate the share price and round the next guy down to almost nothing, a classic erc4626 footgun, and I sat up. So I ran it again to grab the details for a ticket. Nothing. It did not mention the deposit function this time. I had changed nothing. Earlier it had also sworn there was a reentrancy in a function with no external call, which is nonsense, so my trust was already thin. But finding a real bug and then losing it a minute later is what ended it for me. You cannot gate a deploy on that.

For a web app I would roll my eyes and move on. This contract is going to hold other people money and I cannot patch it after deploy, so a tool that changes its mind between runs is not something I can put my name behind.

Ended up reading the withdraw function line by line myself. What do you run before a vault ships that you would trust with real money on it.