RFP-022: bring ERC-20s and ETH into LEZ's private DeFi x.com/i/article/2118…

Two RFPs are open for proposals on the Logos Execution Zone (LEZ). The goal is to bring ERC-20 tokens and ETH into LEZ without a trusted intermediary.

RFP-021: Trustless Ethereum State Attestation for LEZ
Today a LEZ program can't confirm that an Ethereum deposit happened. This RFP asks for a light client that runs as a LEZ program, follows Ethereum's sync committee, and verifies accounts, storage slots, and event logs against finalised headers. Tier M, estimated 8 to 12 weeks.

RFP-022: Privacy-Preserving Wrapped ERC-20 and Ether Bridge for LEZ
A lock-and-mint bridge where a deposit doesn't reveal its LEZ destination and a burn doesn't reveal its Ethereum destination. Tier L, estimated 16 to 20 weeks.

RFP-022 consumes the attestation from RFP-021, and proposals covering both get preference.

You propose the team, technical approach, milestones, and budget. Grants are paid per milestone in USD, and you keep ownership of your code under MIT and Apache 2.0.

Scope is LEZ testnet 0.4 and a public Ethereum testnet. Mainnet deployment is not part of either RFP, and both need an independent audit before production.

Read the specs and submit a proposal: logos.co/rfp

Build the parallel.

There are four ways to run a Logos testnet node:

New to nodes: Basecamp desktop app.
CLI user: logosctl on Linux, Apple silicon or Pi 5.
Server operator: full node (blockchain, storage, delivery).
On Dappnode: unofficial community package.

Run what you depend on. ↓

Encrypting a message protects its contents.

But what about the metadata? Who sent it, who received it, and when?

Mixnets help protect this information at the network layer.

@giuliano_mega explains how.

Go deeper on Mix and the Logos networking stack: logos.co/technology-sta…

RFP-022 requires deposits and burns that don't reveal their other end, plus position recovery from existing credentials.

If your team does privacy protocol design or ZK (RISC0), read the spec.

Have you heard of Reflection (collaborative editing app) and p2panda (p2p protocol which it runs on?)

Well..I have done a thing during @OpenAlt

I have a Reflection fork which can run on both p2panda and Logos Delvery

But I also have a Reflection Basecamp app which runs on lt, but there is a p2panda module which you can switch to and also bridge from p2panda to Logos Delivery and back

Do you think Reflection would likea PR?:D

Logos Blockchain node configurations now hold only the operator's overrides. A fresh init-config writes an empty file with unset values populated from the binary's defaults.

When a release changes a default value, existing nodes inherit it without a config migration. That means less upkeep for anyone running their own node. ↓

init-config now writes only the values passed as flags, keys load from the keystore, and the old migration commands are gone. To start fresh, init-config --overwrite with your flags rebuilds a working config, and --show-config redacts secrets.

github.com/logos-blockcha…

Every field in config variants and optional sections now has a default, so one setting can be overridden without restating the rest of its section. Defaults live in the node's config layer, not in the service crates.

github.com/logos-blockcha…

Era support has merged into the Logos Blockchain node. An era schedule maps an epoch to a versioned ruleset, and every node service, from the time service to Blend, now follows it.

This lays the groundwork for hard forks. A rule change can take effect at a scheduled epoch, and services keep the old era running through a transition window before retiring it. ↓

The network stack now handles era transitions. Chain sync is bound to the fork, so its protocol name rotates with each era. The old name stays live until the transition ends, so peers still on it can keep syncing.

github.com/logos-blockcha…

Blend, the layer that hides who proposed a block, now handles era transitions too. Broadcast and edge modes switch over directly, while core nodes carry era events through every stage and let epoch transitions drive the migration.

github.com/logos-blockcha…

A combined Mix and Delivery module architecture has been proposed, with the Logos Mix module acting as entry and exit node for Logos Delivery.

Delivery is the p2p transport inside Logos Messaging, and the Mixnet gives its senders anonymity. The proposal simplifies how the two connect. A shared peer and connection management interface comes next. ↓

The proposed Mix and Delivery architecture is in this GitHub issue, open for review:

github.com/logos-co/logos…

RFP-022 consumes the Ethereum state attestation primitive from RFP-021. Proposals that cover both get preference, and both close 18-November 2026.

Teams with Ethereum light-client experience should bid on both.

Logos Execution Zone v0.3.2 is out. It adds the Zone SDK's inscription re-funding fix, which addresses previous disruptions seen on testnet.

LEZ posts its state to Logos Blockchain as inscriptions on a channel. When a pending inscription goes stale, the sequencer can now re-fund it, so Zone state keeps landing on chain. ↓

Sequencers now have an optional stale_refund_slots setting (0 or at least 50), and the Bedrock node config schema changed with this bump. No change is needed for wallets and modules, and program IDs are unchanged. github.com/logos-blockcha…