---
# System prepended metadata

title: Proposing blinded blocks with REST

---

# Proposing blinded blocks with REST

There is a request to be able to propose blinded blocks through the REST VC. It is currently impossible because`GetBeaconBlock`, which is called inside `ProposeBlock`, calls the full block API endpoint (`/eth/v2/beacon/blocks/{block_id}`), meaning that a full block will always be returned. In order to allow proposing blinded blocks, the first thing that should be done is to add a `--propose-blinded` VC flag. When it's turned on, the VC will call the blinded block endpoint (`/eth/v1/beacon/blinded_blocks/{block_id}`) in `GetBeaconBlock` and thus receive a blinded block. There is one prerequisite for this to work: the BN would have to always return a builder block. It can't return a blinded local block because there is no way to unblind it [confirmation needed]. Unfortunately we don't currently have an option to always return builder blocks from the BN proposer code. One possible mitigation is for the blinded block endpoint to include information whether the block is local or not, and for local blocks the VC would call the full block endpoint and propose it. However there is no such field/header in the blinded block endpoint's response.