Sidechain blocks can only be finalized by a whitelisted enclave fingerprint (Intel SGX calls it MRENCLAVE), which guarantees integrity of execution.
During beta phase, the Integritee team can deploy upgrades before whitelisting the enclave, but finality will only occur after whitelisting has been ratified by Integritee governance
This proposal aims to whitelist the sidechain-enclave build for <a href="https://github.com/integritee-network/worker/releases/tag/v0.15.3">Integritee SDK release 0.15.3</a>
MRENCLAVE:&nbsp;0x0b97ab9006b2af5601aaf549cc6425c1d9d5f3baa57df7c8e0c51e90eecf1b76
Shard:&nbsp;5wePd1LYa5M49ghuhnp41SP1RwtPVcsuvcf7JzjHcbXg (IncogniteeTEER000000000000000001)
&nbsp;

Schedule a majority-carries referendum to be tabled next once it is legal to schedule
an external referendum.

The dispatch of this call must be `ExternalMajorityOrigin`.

- `proposal_hash`: The preimage hash of the proposal.

Unlike `external_propose`, blacklisting has no effect on this and it may replace a
pre-scheduled `external_propose` call.

Weight: `O(1)`

Update shard config
To be respected by L2 instances after `enactment_delay` parentchain blocks
If no previous config exists, the `enactment_delay` parameter will be ignored
and the `shard_config` will be active immediately

- **Problem Statement:** Ensuring finality of sidechain blocks through whitelisting enclave fingerprints.
- **Significance:** Guarantees integrity of execution and governance approval for upgrades.
- **Proposed Solution:** Whitelisting the sidechain-enclave build for Integritee SDK release 0.15.3.
- **Expected Outcomes:** Secure finality of sidechain blocks and governance-approved upgrades.

#51 Update Incognitee Sidechain Enclave to 0.15.3

No Active Proposals