Hey everyone — first time posting here, and I wanted to share something I’ve been building quietly for a while.

I’ve just opened up the public testnet for a Tendermint‑based blockchain I’ve been developing. It started as a solo project, but it’s now stable enough for anyone to query, inspect, or connect a node to.

Testnet Portal

https://testnet.uquad.org/

The site links back to the main project and will serve as the entry point for RPC, documentation, and network details as things evolve.

What’s running right now

The chain is a standard ABCI/Tendermint architecture with:

1‑second block times
clean proposer rotation
no round retries
no consensus stalls
deterministic state transitions
stable behavior over thousands of blocks

It’s been running long enough to prove liveness and consistency, and the consensus telemetry has been rock‑solid.

Public RPC

You can hit the RPC directly:

Code

http://testnet.uquad.org/status
http://testnet.uquad.org/block
http://testnet.uquad.org/validators
http://testnet.uquad.org/genesis

(If DNS is still propagating in your region, the IP fallback is 149.28.165.91.)

Genesis & Chain Info

Chain ID: quad-testnet-1
Genesis: available on the testnet site
Persistent Peer: will be posted shortly once I finalize the public node ID

What this testnet is for

Right now the goal is simple:

allow developers to query the chain
test RPC behavior
inspect consensus state
experiment with tooling
gather feedback before expanding the validator set

This is not a token launch, not a hype cycle, not a “buy this coin” situation — just a clean, functioning network that’s ready for outside eyes.

Feedback welcome

If you try the RPC, inspect the chain, or want to spin up a node, I’d love to hear what breaks, what works, and what you’d like to see next.

I’ll be expanding the documentation and adding more public endpoints as the testnet matures.

Thanks for taking a look.

I’m working on a constraint‑heavy economic system (currently implemented on Cosmos SDK, but the question is protocol‑agnostic). I’m trying to sanity‑check a design choice with people who’ve built or audited complex on‑chain systems.

The architecture enforces strict separation between roles:

Oracle layer — ingestion only, no economic logic
Market layer — pricing + safety bounds, no treasury access
Treasury layer — custody only, cannot initiate actions
Economics layer — computes validity conditions, cannot move funds
Action layer — executes only when upstream conditions are satisfied

The goal is to prevent cross‑layer collapse, implicit value flow, and “soft” failure modes.
Right now the system behaves correctly under stress tests, but I’m evaluating the design philosophy before taking it to public testnet

The question:
From your experience designing or auditing protocols, does enforcing this level of separation actually improve safety and auditability, or does it just introduce rigidity that becomes a long‑term maintenance cost?

I’m especially interested in perspectives from people who’ve worked on:

oracle → pricing → treasury pipelines
systems with strict failure‑domain boundaries
protocols where “treasury cannot act” is a deliberate constraint
architectures that avoid implicit module‑to‑module value flow

Not looking for launch feedback — this is still in a local test environment.
Just trying to understand whether this separation‑of‑powers model is a net positive or a trap.