{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"description": "Each checkpoint proposal includes EIP-4844 blob commitments that are checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated blob commitments before the epoch is finalized.",
"references": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Once the epoch root proof has been verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
}
]
}
],
"operator": {
"name": "There is no central operator",
"description": "There is no privileged sequencer. Anyone can stake 200 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
"risks": [],
"references": [
{
"title": "Rollup.sol - deposit() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
]
},
"otherConsiderations": [
{
"name": "Upgrades replace the canonical rollup",
"description": "The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay. Governance also owns critical config parameters that can freeze or compromise the Rollup system.",
"references": [
{
"title": "Registry.sol - addRollup() on Etherscan",
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"title": "Governance.sol - execute() on Etherscan",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
}
],
"risks": []
},
{
"name": "No canonical bridge escrow",
"description": "There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.",
"references": [
{
"title": "FeeJuicePortal.sol - on Etherscan",
"url": "https://etherscan.io/address/eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"description": "All censorship resistance tools that are part of the protocol rely on probabilistic inclusion. In contrast to \"forced transactions\", there is no simple deterministic inclusion after some maximum delay, but rather different inclusion probabilities after different time horizons. The \"time needed to exit\" of 20d for the exit window was simulated by using a simple model of the decentralized sequencer set at launch. The escape hatch and private transactions can give additional inclusion guarantees.",
"references": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked validator committee",
"description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 3394 and selects one proposer from the current committee per slot. More than 2/3 of the sequencers in the committee need to attest to each proposed block in an epoch for it to be valid.",
"sequencerSetSpec": {
"slotTime": {
"value": "1m 12s"
},
"epochTime": {
"value": "38m 24s"
"value": "38m 24s",
"description": "A random committee is sampled from the sequencer set for each epoch, a random block producer is sampled from the committee for each slot in the epoch"
},
"sequencerCount": {
"value": "3394 sequencers"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "200 K AZTEC, constant"
},
"rateLimit": {
"value": "Up to 4 sequencers per epoch (current)",
"description": "Can be changed (or set to 0) by onchain Governance"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Bonded escape hatch, private transactions",
"sentiment": "good"
}
},
"inclusionDelayChart": {
"type": "committeelike",
"validatorCount": 3394,
"committeeSize": 48,
"epochSlots": 32,
"slotSeconds": 72,
"blockingThreshold": 15,
"target": 0.99,
"maxCensorFraction": 0.5,
"stakeDistribution": {
"stakeToken": "AZTEC",
"totalStake": 629230000,
"entities": [
{
"name": "Nethermind",
"stake": 123200000
},
{
"name": "Nansen | Stake to Stack Points",
"stake": 79800000
},
{
"name": "Sigma Prime",
"stake": 54600000
},
{
"name": "snoopfear|PON",
"stake": 47200000
},
{
"name": "P2P.org",
"stake": 45196000
},
{
"name": "Wonderland",
"stake": 35400000
},
{
"name": "GabbexNodes",
"stake": 30800000
},
{
"name": "ZKV",
"stake": 30590000
},
{
"name": "Aztec-Scan",
"stake": 21000000
},
{
"name": "01node",
"stake": 18000000
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. It does not model the escape hatch, validator-set changes, validator-set lag, and blanket-censorship resistance gadgets.",
"censorshipResistance": "The committee and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations. The bond is 332 M AZTEC, a high amount that is supposed to protect the single-proof system in case of bugs while still providing a last resort opportunity to circumvent the sequencer set. Aztec has developed a full private execution environment on the L2. This can benefit users because they cannot be censored based on their transaction content.\n### Selective censorship\nOn a live Aztec L2 with a given fraction of censoring sequencers, users can either send private transactions or wait for a non-censoring committee and proposing sequencer to include their public transaction.\n### Blanket censorship\nIf users are censored by the entire sequencer set, even if it stops block production just to censor, anyone can join the sequencer set permissionlessly at the churn rate or circumvent it completely by bonding and using the escape hatch. In both cases, expensive hardware is required to provide the required validity proof. Motivated censorers can try to saturate the entry queue and the escape hatch with their own new sequencers and thus lower the inclusion chances of the censored.\n### Walkaway\nIn the scenario of all sequencers stopping their service, the escape hatch provides an inclusion guarantee of 2d 23h in the worst case and the sequencer set can heal long-term by permissionless entry and churn.",
"references": [
{
"title": "Aztec docs - Privacy considerations",
"url": "https://github.com/AztecProtocol/aztec-packages/blob/next/docs/docs-developers/docs/resources/considerations/privacy_considerations.md#function-fingerprints-and-tx-fingerprints"
},
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
}
],
"risks": []
},
"stateValidation": {
"description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). Unproven checkpoints are pruned after the proof submission window of 1h 16m expires.",
"categories": [
{
"title": "State root proposals",
"description": "The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.",
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
],
"risks": []
},
{
"title": "Validity proofs",
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
}
]
},
{
"title": "Slashing",
"description": "\nEach stake of 200 K AZTEC that is locked to join the sequencer set and vote in governance can be slashed under certain conditions. Slashing is voted on by sequencers each time they propose a checkpoint and is grouped in rounds that span 4 epochs (2h 33m) each.\n\nSlashing conditions are programmed into each sequencer node and can be changed by node operators by updating or editing their node software. Nodes usually submit votes to slash automatically on L1. The `TallySlashingProposer` contract only enforces the formalities of the slashing system:\n* A given slashing round's votes always target the checkpoint proposals from 2 rounds ago.\n* As soon as a round's votes have reached a quorum of 65/128, it enters an execution delay of 28 rounds (2d 23h)\n* An automatically generated slashing payload is executable by anyone on L1 after the execution delay, applying the slashing penalties defined by the sequencer votes.\n\nSlashing penalties are defined onchain in three levels: large (2.00 K AZTEC), medium (2.00 K AZTEC), and small (2.00 K AZTEC). Offenses that lead to slashing usually include:\n* Inactivity: A sequencer fails to attest or propose when selected.\n* Data Withholding: A sequencer proposes a checkpoint including state diff data availability on L1 but withholds the public transaction bodies and/or CHONK proofs required for permissionless proving.\n* Invalidity: A sequencer attests to invalid proposals, multiple conflicting proposals, with invalid signatures, or proposes a block that is not proven in time.\n\nThe above offense list is not exhaustive and not defined onchain but usually in the software the sequencers decide to run. This is also where the mapping of offenses to the slashing penalty levels can be defined.\n\nThe SlashVeto Council is a 5/9 Multisig that can veto specific proposals and/or all slashing for 3d at a time.",
"references": [
{
"title": "Slashing - Aztec Docs",
"url": "https://docs.aztec.network/operate/operators/sequencer-management/slashing_and_offenses"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": {
"content": "\n# Standard Path (Signaling)\nBecause sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new 'canonical' rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.\n\n## 1. The Signaling Phase (`GovernanceProposer`)\nAztec uses an onchain \"Empire\" signaling system. Active sequencers operating on the 'canonical rollup' (as defined by the Registry) call `signal(payloadAddress)` on the L1 `GovernanceProposer` contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 `Governance` contract.\n\n## 2. The Voting Phase (`Governance`)\nOnce submitted, the proposal enters a delay and voting flow:\n* **Pending (3d):** At the end of this delay, voting power is snapshotted.\n* **Active (7d):** AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the `yea` votes must exceed a required margin of 33%.\n* **Queued (1mo):** If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.\n* Executable (7d): The proposal enters a grace period where anyone can call `execute()`. If not executed, it expires.\n\nTotal standard delay from proposal to execution: **1mo 10d**.\n\n### Emergency Path (Circumvent Signaling)\nIf the L2 sequencer set is offline, censoring, or acting maliciously, the `GovernanceProposer` cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the `proposeWithLock()` function directly on the `Governance` contract.\n* An actor must lock **258 M AZTEC**, roughly 2.5% of total supply\n* These funds are locked for an extended 3mo.\n* Once proposed, the payload enters the exact same 1mo 10d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.\n\n### Rollup Immutability\nThe smart contract code of `Rollup`, its verifier and its canonical messaging contracts cannot be changed. However, `Governance` owns critical permissions for configuration parameters that can freeze the L2 indefinitely. 'Upgrading' a Rollup contract involves a `Governance` action that designates a new `Rollup` contract address as canonical. The `GSE` (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address `0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8` instead of a specific immutable rollup. Importantly, `Governance` retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.\n\n### Slashing and the SlashVeto Council\nAztec features onchain slashing for equivocation or missing attestations, managed by `Slasher` and `TallySlashingProposer`. \n\nThere is a protective **Vetoer** role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:\n* call `vetoPayload()` to stop a specific slashing event.\n* call `setSlashingEnabled(false)`, which pauses all slashing in the protocol for a period of 3d.\n\n### Economics & Treasury\n* **Coin Issuer:** The `CoinIssuer` contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20%.\n* **Protocol Treasury:** Funds owned by the DAO sit in the `ProtocolTreasury`. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal."
},
"warning": "Aztec v4 has [know security vulnerabilities](https://aztec.network/blog/critical-vulnerability-in-alpha-v4) that can only be fixed in a new deployment."
}
gnosis+1-1
scalingTechnology+1-1
{
"dataAvailability": [
{
"name": "Transaction data is stored on Gnosis Chain",
"description": "Gnosis Chain transaction data is published to Gnosis Chain and propagated by its validator and node network. The Ethereum bridge contracts do not verify data availability and only process bridge messages after bridge-validator signatures are submitted.",
"references": [
{
"title": "Gnosis specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "transaction data is unavailable and bridge validators cannot reconstruct or sign the messages needed to exit."
}
]
}
],
"detailedDescription": "Gnosis chain in its current form does not derive or benefit from Ethereum's decentralisation apart from being developed as a close fork to re-use Ethereum tooling and infrastructure. Its censorship resistance relies on an open validator set with over 100 thousand diverse validators, although the clustering and stake distribution among entities is intransparent. Users who are censored selectively on an otherwise live network benefit from the fast 5s block time and non-committee-gated, stake-weighted proposer rotation, resulting in an inclusion probability of 99% in less than a minute even if up to 50% of the Gnosis stake is censoring them. There are also a few thousand validators who run custom 'shutter network' nodes that support threshold-encrypted transactions. For a case of active blanket censorship (>50% stake) by all current validators, users have no way apart from a hardfork to get their transactions included or save the chain. In the operator walkaway scenario, new sequencers could stake and join the set permissionlessly.",
"otherConsiderations": [
{
"name": "Encrypted mempool (Shutter Network Beta)",
"description": "A subset of Gnosis Chain validators is currently running a modified node version that supports threshold-encrypted transaction payloads. This allows to 'encrypt the mempool' and protect against malicious MEV and censorship with significant caveats. To encrypt the transaction, users have to either use custom wallets or a trusted encrypting rpc proxy. Decryption is handled by participating validators sharing their decryption key shares at the target block, allowing the proposer to decrypt the transaction and include and execute (or censor) it.",
"references": [
{
"title": "Shutterized Gnosis Chain Beta Release",
"url": "https://blog.shutter.network/shutterized-gnosis-chain-is-now-live/"
},
{
"title": "Gnosis Docs: Shutterized Gnosis Chain",
"url": "https://docs.gnosischain.com/shutterized-gc/"
}
],
"risks": []
},
{
"name": "Destination tokens can be upgradeable",
"description": "Omnibridge uses token factories to deploy wrapped ERC20 representations for assets native to the other chain. The token factory owner can change the implementation used for newly deployed wrapped tokens.",
"references": [
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a malicious or vulnerable wrapped token implementation is configured for newly bridged assets."
}
]
}
],
"sequencing": {
"name": "Transactions are ordered by Gnosis Chain validators",
"description": "Gnosis Chain uses a permissionless proof-of-stake validator set with stake-weighted proposer rotation and a 5 second slot time. The Ethereum-like committee-free block production architecture combined with the short block time lead to fast theoretical inclusion times, even with high rates of censorship. In contrast to Ethereum, blocks on Gnosis chain are usually built *locally*, meaning that validators do not delegate block production to specialised builders. There is no public information on the decentralisation of the Gnosis validator set.",
"sequencerSetSpec": {
"slotTime": {
"value": "5s"
},
"epochTime": {
"value": "1m 20s",
"description": "Block production is not committee-based"
"description": "Block production is not committee-based (epochs do not affect sequencer rotation)"
},
"sequencerCount": {
"value": "100,000 validators"
},
"blockProductionAccess": {
"value": "Open",
"sentiment": "good"
},
"stakePerValidator": {
"value": "1 GNO minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "~1-2 GNO per epoch",
"description": "defined by the consensus clients"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "Shutter encrypted mempool beta",
"sentiment": "warning"
}
},
"inclusionDelayChart": {
"type": "ethereumlike",
"validatorCount": 100000,
"slotSeconds": 5,
"target": 0.99,
"maxCensorFraction": 0.5
},
"inclusionDelayChartDescription": "The chart uses the Ethereum-style single-proposer formula with Gnosis-specific constants. It excludes finality, inactivity leaks, validator-set changes, hard forks, and blanket-censorship resistance gadgets.",
"censorshipResistance": "Gnosis Chain does not have dedicated censorship resistance gadgets, but the sequencer set is open and there are no committees that can block inclusion.\n### Selective censorship\nEven with high percentages of stake censoring, users have very fast inclusion times. There are also initial tests of an out-of-protocol solution for encrypting transactions in the mempool (Shutterized Gnosis Chain).\n### Blanket censorship\nThere is no way to circumvent the validator set from Ethereum in a case of active censorship by all (or a majority of) validators.\n### Walkaway\nSince the validator set is open, new validators can join it in case validators passively stop block production. If all validators stop at the same time, a social recovery and hard fork would be necessary.",
"references": [
{
"title": "Gnosis Chain specifications",
"url": "https://docs.gnosischain.com/about/specs/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "at least half of the active stake censors them, or if current validators coordinate blanket censorship and the chain requires social recovery."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "Gnosis Chain is an independent proof-of-stake chain. Ethereum contracts do not check whether Gnosis state transitions are valid. Cross-chain messages are executed when the relevant bridge contract receives enough validator signatures: 4/7 for the xDAI bridge and 4/7 for AMB and Omnibridge.",
"references": [
{
"title": "xDAI Bridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/xdai-bridge"
},
{
"title": "Omnibridge documentation",
"url": "https://docs.gnosischain.com/bridges/About%20Token%20Bridges/omnibridge"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "bridge validators sign fraudulent messages that release more assets on Ethereum than were burned or locked on Gnosis."
},
{
"category": "Funds can be stolen if",
"text": "the Gnosis validator set finalizes an invalid chain state and the bridge validators sign messages derived from it."
},
{
"category": "Funds can be frozen if",
"text": "bridge validators stop signing messages or Gnosis Chain stops finalizing blocks."
}
]
}
]
}
}
polygon-pos+2-1
scalingTechnology+2-1
{
"otherConsiderations": [
{
"name": "Destination tokens are upgradeable",
"description": "Tokens transferred end up as wrapped ERC20 proxies, some of them are upgradable. The contract is named UChildERC20Proxy.",
"references": [],
"risks": [
{
"category": "Funds can be stolen if",
"text": "destination token contract is maliciously upgraded."
}
],
"isIncomplete": true
}
],
"sequencing": {
"name": "Transactions are ordered by Polygon PoS validators",
"description": "Polygon PoS is operated by a closed proof-of-stake validator set with 105 active validators. Block production rights are given to validators randomly (stake-weighted) for the duration of a *span*. In practice, validators delegate the block production further to centralised validator-elected block producers (VeBloPs). Ethereum smart contracts accept checkpoints signed by more than two thirds of Polygon PoS validator stake.",
"sequencerSetSpec": {
"slotTime": {
"value": "2s"
},
"epochTime": {
"value": "*Span*: 6400 blocks (3h 33m)"
"value": "3h 33m",
"description": "Randomly sampled validators delegate block production for the duration of a span: 6400 blocks"
},
"sequencerCount": {
"value": "105 validators"
},
"blockProductionAccess": {
"value": "Closed and capped",
"sentiment": "bad",
"description": "The current validator cap is 105. Joining the set is permissioned (Multisig)."
},
"stakePerValidator": {
"value": "100,000 POL minimum, variable",
"description": "stake-weighted block production rights, no maximum"
},
"rateLimit": {
"value": "No (permissioned)"
},
"deterministicCrGadget": {
"value": "No",
"sentiment": "warning"
},
"additionalCrGadgets": {
"value": "No",
"sentiment": "bad"
}
},
"inclusionDelayChart": {
"type": "spanlike",
"validatorCount": 105,
"spanBlocks": 6400,
"blockSeconds": 2,
"target": 0.99,
"maxCensorFraction": 0.33,
"stakeDistribution": {
"stakeToken": "POL",
"totalStake": 3606070002,
"entities": [
{
"name": "Upbit Staking",
"stake": 408044403
},
{
"name": "Coinbase",
"stake": 351875004
},
{
"name": "Luganodes",
"stake": 305004763
},
{
"name": "Binance Node",
"stake": 251922326
},
{
"name": "Figment",
"stake": 225231066
},
{
"name": "Matic Power",
"stake": 207784342
},
{
"name": "Anonymous 194",
"stake": 183259002
},
{
"name": "Blockdaemon",
"stake": 176532472
},
{
"name": "Kraken",
"stake": 152345919
},
{
"name": "Kiln x Ownest 🔸 Pro Staking 🔸",
"stake": 130976081
}
]
}
},
"inclusionDelayChartDescription": "The chart models live-chain selective censorship only. Since proposing is stake-weighted, the x-axis represents the censoring POL stake, and does not cover validator-set changes, or blanket-censorship resistance gadgets.",
"censorshipResistance": "The validator set (on Polygon PoS, validators are both proposers and sequencers) is closed and capped, but includes a diverse set of known entities who share block production rights. There are no specific censorship resistance gadgets built into the protocol.\n### Selective censorship\nAs long as the Polygon PoS blockchain is producing blocks, users can expect to include their transactions due to the rotating, diverse block producers, even if they are censored by some of them. Unfortunately, the rotation is very slow (see *span* time) and even just a few entities censoring can cause long inclusion delays.\n### Blanket censorship\nValidators holding more than 1/3 of Polygon PoS stake among them can censor users if they actively refuse to attest to blocks with their transactions. Polygon Multisig controls the core smart contracts on Ethereum and can administer the validator set (including malicious changes) as a consequence.\n### Walkaway\nIf validators holding more than 1/3 of the stake on Polygon PoS stop block production, the chain stops and there is no way for users to include any transactions. As the validator set is currently closed by a permissioned smart contract setting on ethereum, walkaway of the permissioned actor would require social coordination and a hard fork to progress the chain.",
"references": [
{
"title": "Polygon PoS architecture documentation",
"url": "https://docs.polygon.technology/pos/architecture/"
}
],
"risks": [
{
"category": "Users can be censored if",
"text": "the active span proposer censors them, or if at least one third of Polygon PoS stake refuses to attest blocks that include their transactions."
}
]
},
"stateValidation": {
"categories": [
{
"title": "No state validation",
"description": "State updates are settled on Ethereum if signed by at least 2/3+1 of the Polygon PoS validators stake. Contracts on Ethereum do not check whether the state transitions are valid.",
"references": [],
"risks": [
{
"category": "Users can be censored if",
"text": "validators on Polygon decide to not mint tokens after observing an event on Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum."
},
{
"category": "Funds can be stolen if",
"text": "validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds."
}
]
}
]
}
}