You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docs-developers/docs/foundational-topics/pxe/index.md
+19Lines changed: 19 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,6 +87,25 @@ The keystore securely stores cryptographic keys for registered accounts, includi
87
87
88
88
Oracles are pieces of data that are injected into a smart contract function from the client side. Learn more about [how oracles work](../../aztec-nr/framework-description/advanced/protocol_oracles.md).
89
89
90
+
## Oracle versioning
91
+
92
+
The set of oracles that the PXE exposes to private and utility functions is versioned, so that contracts can declare which oracles they expect to be available. Every contract compiled with `Aztec.nr` records the oracle version it was built against, and the PXE checks this version before executing any oracle call.
93
+
94
+
The version uses two components, `major.minor`, with the following compatibility rules:
95
+
96
+
-**`major`** must match exactly. A major bump is a breaking change — oracles were removed or their signatures changed — and a PXE on a different major cannot safely run the contract.
97
+
-**`minor`** indicates additive changes (new oracles). The PXE uses a best-effort approach here: a contract compiled against a higher `minor` than the PXE supports is still allowed to run, and an error is only thrown if the contract actually invokes an oracle the PXE does not know about. In practice, a contract built with a newer Aztec.nr may not use any of the newly added oracles at all, in which case it runs fine on an older PXE.
98
+
99
+
The canonical version constants live in the PXE (`ORACLE_VERSION_MAJOR` / `ORACLE_VERSION_MINOR` in `yarn-project/pxe/src/oracle_version.ts`) and in Aztec.nr (`noir-projects/aztec-nr/aztec/src/oracle/version.nr`). The two are kept in lockstep as part of each release.
100
+
101
+
### Resolving a version mismatch
102
+
103
+
If you see an error like _"Oracle '…' not found. … The contract was compiled with Aztec.nr oracle version X.Y, but this private execution environment only supports up to A.B"_, the contract uses one or more oracles from a newer Aztec.nr than your PXE supports.
104
+
105
+
To fix it, upgrade the software that ships the PXE (sandbox, wallet, or whatever embeds `@aztec/pxe`) to a release whose Aztec.nr version is at least as new as the one the contract was compiled with.
106
+
107
+
If the PXE reports a version that _should_ include every oracle the contract needs but an oracle is still missing, that is a contract bug rather than a version problem and you should likely report it to the app developer.
108
+
90
109
## For developers
91
110
92
111
To learn how to develop on top of the PXE, refer to these guides:
Copy file name to clipboardExpand all lines: docs/docs-participate/token/staking.md
+10-7Lines changed: 10 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -56,15 +56,18 @@ Slashing is managed through governance voting based on evidence collected both o
56
56
57
57
## Unstaking
58
58
59
-
When you want to withdraw your staked tokens, you must go through an unstaking process with a mandatory exit delay.
59
+
When you want to withdraw your staked tokens, you must go through an unstaking process with mandatory delays.
60
60
61
-
#if(testnet)
62
-
The exit delay for testnet is **2 days**.
63
-
#else
64
-
The exit delay for mainnet is **4 days**.
65
-
#endif
61
+
### Exit Delays
66
62
67
-
The exit delay exists to allow time for pending slashing conditions to be detected and to prevent validators from quickly exiting after misbehaving.
63
+
| Delay Type | Alpha (Mainnet) | Testnet |
64
+
|-----------|-----------------|---------|
65
+
|**Staking Exit Delay**| 4 days | 2 days |
66
+
|**Governance Withdrawal Delay**|~38 days |~1.6 days |
67
+
68
+
The **staking exit delay** is the minimum time after initiating withdrawal before you can claim your tokens. It allows time for pending slashing conditions to be detected.
69
+
70
+
If your tokens are deposited in the Governance Staking Escrow (GSE) for voting, the **governance withdrawal delay** also applies. This delay is calculated as `votingDelay/5 + votingDuration + executionDelay` to ensure voted-on proposals can be executed before voters exit. On mainnet this is approximately 38 days (0.6 + 7 + 30 days).
|**Register New Rollup Version Payload**| N/A |[`0x11f7Ab2324CA94af929A388477a7959E0108C3d6`](https://sepolia.etherscan.io/address/0x11f7Ab2324CA94af929A388477a7959E0108C3d6)|
0 commit comments