End-to-End Audit of Mina's Decentralised Treasury

Description. Anyone can withdraw funds from the Treasury Owner by calling executeProposal() with the empty public key as the Proposal address. The root cause is in o1js: it drops account updates at PublicKey.empty() from the final transaction, along with everything the caller proved about them.

Mina represents a zkApp transaction as a forest of AccountUpdates. For a nested smart-contract call, the caller proof commits to the callee AccountUpdate and its descendants. Mina then verifies the authorization attached to each update in the serialized transaction. This composition is sound only if every update committed to by the caller remains in the serialized call forest.

o1js uses AccountUpdates at PublicKey.empty() as internal dummy values. AccountUpdate.isDummy() identifies them solely by their public key:

isDummy() {
  // ZKSECURITY: the empty public key alone marks an update as dummy
  return this.body.publicKey.isEmpty();
}

When o1js finalizes the call forest, it omits every update for which isDummy() returns true. Omitting a parent also removes its descendants:

for (let { isDummy, ...tree } of [...nodes].reverse()) {
  // ZKSECURITY: an update at the empty key is dropped together with its subtree
  finalForest.pushIf(isDummy.not(), tree);
}

This test does not establish that the update is the canonical internal dummy. An update at the empty public key is removed even if it contains account preconditions, state changes, authorization data, or child updates. Application code can therefore prove statements about an AccountUpdate that does not appear in the resulting transaction.

This affects TreasuryOwner.executeProposal(). The method accepts a Proposal public key and constructs the corresponding Proposal under the Owner’s derived token ID. It relies on nested Proposal calls to check the lifecycle, approval status, recipient, and payout amount. The Owner debit occurs outside those calls:

// ZKSECURITY: proposalPublicKey is caller-supplied and may be PublicKey.empty()
const proposal = new TreasuryProposalSmartContract(
  proposalPublicKey,
  this.deriveTokenId(),
);

const proposalLifecycleId = await proposal.getLifecycleId();
// ZKSECURITY: ...

// ZKSECURITY: the debit lives on the Owner update, which is retained
this.self.balance.subInPlace(amountToPayOut);
// ZKSECURITY: all Proposal checks live on the Proposal updates, which are dropped
await proposal.execute(amountToPayOut, recipient);
this.approve(proposal.self);

An attacker can pass PublicKey.empty() as proposalPublicKey and provide a malicious local account witness while constructing the transaction. For getLifecycleId(), the witness supplies a lifecycle old enough to satisfy the check that remains in the Owner circuit.

The approval, recipient, and remaining-payout checks in proposal.execute() are not part of the Owner circuit. They run while o1js computes the witnessed callee update.

The Proposal updates contain the preconditions that would normally bind this state to an on-chain account. They also contain the Proposal authorization, the payout-accounting update, and the recipient payment. o1js classifies both Proposal updates as dummy and removes them along with their descendants and enforced protocol logic.

The nonempty Owner update remains, including its proof and balance debit. The attacker can add a separate top-level credit for the same amount. Mina then sees a balanced transaction with a valid Owner proof, but no Proposal update or Proposal proof.

Proof of concept. We reproduced this attack on an o1js LocalBlockchain with proofs enabled. The attacker called executeProposal(PublicKey.empty(), attacker, 2 MINA). The serialized transaction contained the 2 MINA Owner debit and a matching attacker credit, but no update for the Proposal.

The transaction was accepted with a genuine Owner proof and only the attacker’s fee-payer signature. The Owner lost 2 MINA and the attacker received 2 MINA. No Proposal account existed.

Impact. Anyone can permissionlessly drain the full balance of an unpaused Treasury Owner.

The issue is present in upstream o1js v3.0.0 and in the reviewed fork. It is not specific to Treasury: the same behavior can remove a nested AccountUpdate and its complete descendant subtree in other o1js applications.

Recommendation. We reported the underlying library issue to o1Labs, and it is being addressed in o1js. Mina Treasury must upgrade to the fixed o1js release before going live.

Client Response. Fixed in revision 479bdc2 by upgrading to o1js 3.1.0.

Description. When one contract calls a method on another, o1js does not constrain the token ID of the callee account. This lets an attacker deploy their own fake Proposal contract under the native token and hand it to executeProposal() to drain the treasury.

A Mina account is identified by (publicKey, tokenId). The same public key can therefore refer to distinct accounts under the native token and under a custom token. A nested call must bind both parts of the intended account identity.

o1js evaluates a nested smart-contract method inside AccountUpdate.witness(). The caller circuit then constrains the witnessed callee update to the contract instance selected by the caller. The public-key constraint is correct, but the token-ID constraint compares the witnessed value with itself:

// ZKSECURITY: from now on, this.self returns the witnessed update
innerContext.selfUpdate = accountUpdate;

accountUpdate.body.publicKey.assertEquals(this.address);
// ZKSECURITY: this.self.body.tokenId is accountUpdate.body.tokenId, so this is a tautology
accountUpdate.body.tokenId.assertEquals(this.self.body.tokenId);

The token ID supplied when the SmartContract instance was constructed is available as this.tokenId, but is not constrained here. A prover can substitute a same-key account under another token ID if that account can produce a valid proof for the called method and verification key.

This affects TreasuryOwner.executeProposal(). The Treasury Owner intends to call a Proposal under its derived token ID:

// ZKSECURITY: the derived token ID is never enforced on the witnessed Proposal updates
const proposal = new TreasuryProposalSmartContract(
  proposalPublicKey,
  this.deriveTokenId(),
);

An attacker can instead deploy a genuine TreasuryProposalSmartContract at an attacker-controlled public key under TokenId.default. The attacker chooses its initial state, including an old lifecycle, APPROVED status, recipient, and payout amount. The attacker then passes that public key to the real Owner.

During proof generation, the nested calls use the native-token Proposal. Their public-key checks pass, while the token-ID assertions impose no constraint. The Proposal proofs are valid for the native-token account and are retained in the transaction. The Owner proof nevertheless treats their results as coming from the Proposal account under its derived token ID.

Proof of concept. We reproduced the attack on LocalBlockchain with proofs enabled. The attacker deployed a native-token Proposal with attacker-selected approved state, then used it to request 2 MINA from an Owner funded with 10 MINA. The accepted transaction contained two proved updates for the native-token Proposal and no update under the Owner-derived Proposal token ID. The Owner lost 2 MINA, the attacker received 2 MINA, and the native-token Proposal recorded the payout.

Impact. Anyone can drain the full balance of an unpaused Treasury Owner.

The defective wrapper is present in upstream o1js v3.0.0 and in the reviewed fork. Other applications that call token-scoped contracts dynamically can likewise confuse same-key accounts under different token IDs.

Recommendation. We reported the underlying library issue to o1Labs, and it is being addressed in o1js. Mina Treasury must upgrade to the fixed o1js release before going live.

Client Response. Fixed in revision 479bdc2 by upgrading to o1js 3.1.0, which constrains the callee token ID to this.tokenId.

Description. The caller circuit of a nested call hashes the callee AccountUpdate without checking that its fields are canonical, so the hash does not uniquely determine the update. A prover can make the Treasury Owner proof commit to a proof-authorized Proposal update while the transaction carries an unauthorized update with the same hash. By applying this substitution to executeProposal(), using any existing Proposal, the attacker bypasses all checks of the Proposal state (including for the amount allowed to withdraw) and drains the Treasury Owner.

o1js implements a nested smart-contract call by executing the callee inside an AccountUpdate.witness() block. The caller circuit does not contain the callee circuit. Instead, it commits to the witnessed callee AccountUpdate and relies on Mina to verify the authorization of the corresponding public AccountUpdate.

This requires the private witnessed update and the public serialized update to have a unique representation under the hash committed to by the caller proof. If two representations produce the same hash input, the caller can reason about one update while Mina receives another.

The nested-call wrapper skips the normal AccountUpdate checks:

let {
  accountUpdate,
  result: { result, children },
} = await AccountUpdate.witness(
  provable({
    result: methodIntf.returnType ?? provable(null),
    children: AccountUpdateForest,
  }),
  runCalledContract,
  // ZKSECURITY: disables AccountUpdate.check() on the witnessed callee update
  { skipCheck: true },
);

With skipCheck: true, o1js applies only AccountUpdate.clientSideOnlyChecks, which checks the signed representation of the balance change:

let accountUpdate = skipCheck
  ? {
      ...provable(AccountUpdate),
      // ZKSECURITY: this replacement check validates only the balance change
      check: AccountUpdate.clientSideOnlyChecks,
    }
  : AccountUpdate;

Because AccountUpdate.check() is skipped, most Boolean and bounded fields are not constrained to their ranges before the AccountUpdate hash is used.

An explicit check in the nested-call wrapper asserts that authorizationKind.isProved == 1, with the intention of ensuring that method calls have to carry associated proofs. However, the adjacent isSigned value is never constrained to be Boolean.

The hash input packs these flags as

A canonical update with None authorization has both flags set to zero. Its packed value is therefore zero. A malicious private witness can instead set

This satisfies the caller’s isProved == 1 assertion and also packs to zero. If both forms use the dummy verification-key hash, they produce the same complete AccountUpdate hash. This does not require a Poseidon collision: the unchecked values produce identical input before hashing.

The caller proof can consequently use a private witness that appears proof-authorized, while the serialized transaction contains the hash-equivalent canonical None-authorized update. The private witness can provide an arbitrary return value and an empty child forest. Mina sees only the canonical public update and does not require the proof or descendants assumed by the caller.

TreasuryOwner.executeProposal() relies on two nested Proposal calls. getLifecycleId() supplies the value checked by the Owner, while execute() checks the Proposal state and accounts for the payout. The Owner balance debit occurs outside both calls.

An attacker can target any Proposal and replace both nested calls with None-authorized no-op updates. Malformed private witnesses provide the return values needed to prove the Owner call. The corresponding public updates contain no Proposal proofs, state checks, payout-accounting update, or recipient payment. Proposal accounts use Permissions.default(), for which access is none, so Mina accepts the public no-op updates without authorization. A separate top-level credit to the attacker balances the retained Owner debit.

Proof of concept. We reproduced the packing ambiguity and Treasury attack on LocalBlockchain with proofs enabled. In one atomic transaction, the attacker created a Proposal for 1 nanomina and requested the Owner’s full 10 MINA balance. The two execution updates used None authorization and contained no Proposal proof. The transaction was accepted and successfully paid out the full treasury balance minus the 1 MINA account creation fee to the attacker. The new Proposal remained UNKNOWN, its recorded amount remained 1 nanomina, and its paidOutAmount remained zero.

Impact. Anyone can withdraw up to the full balance of an unpaused Treasury Owner. The attack can use a Proposal created by another party during any lifecycle period, or create one on the spot during the PROPOSAL period.

The root cause applies to the packed AccountUpdate representation generally. Any field whose range or Boolean check is skipped may admit different values with the same packed representation. The affected code is present in upstream o1js v3.0.0 and in the reviewed fork.

Recommendation. We reported the underlying library issue to o1Labs. The upstream recommendation is to remove the AccountUpdate skipCheck option altogether and call AccountUpdate.check() in all code paths that witness account updates. Mina Treasury must upgrade to a fixed o1js release before going live.

Client Response. Fixed in revision 479bdc2 by upgrading to o1js 3.1.0, which removes skipCheck and applies the full AccountUpdate.check() to witnessed callee updates.

Description. The deployment exposes the Mina daemon’s full GraphQL API to the internet without authentication. The daemon Service offers two ports: 3000, served by a graphql-public-proxy sidecar that hides mutations, and 3085, the full daemon API. Both public routes select 3085:

# 1b-Mina-Daemon/helmfile.yaml, internet-facing Ingress
service:
  name: graphql-proxy
  port:
    # ZKSECURITY: full daemon API instead of the read-only proxy on 3000
    number: 3085

# 2c-Deploy-Stack/helmfile.yaml, upstream of the Treasury's public /mina/ route
minaNodeUpstream: http://graphql-proxy.devnet.svc.cluster.local:3085

The full API contains operator mutations that assume a trusted caller. For example, setConnectionGatingConfig can isolate the node from its peers.

It also contains archivePrecomputedBlock and archiveExtensionalBlock, which forward a caller-supplied block to the Archive without validating it against consensus. The Archive decides finality by height alone, so an attacker who also injects a forged descendant more than k blocks higher makes the first block canonical. The Treasury indexer trusts canonical Archive events as its record of Proposal activity.

The proxy on port 3000 likely does not prevent these mutations either. The deployed proxy image (version 0.0.12) is not public, but its most recent public build, the minafoundation/graphql-public-proxy image from July 2024, hides mutations only from HTTP requests. WebSocket connections are forwarded to the daemon unchanged, and the daemon also executes mutations received over a WebSocket.

Proof of concept. On Mesa Lightnet, we injected a block containing a fake proposalCreated event, with no signature or proof, and made it canonical with a forged descendant. The unmodified indexer stored the event. A second, duplicate creation event made the Proposal processor block permanently, so later legitimate events were no longer processed. On a multi-node Lightnet, a single setConnectionGatingConfig call with isolate: true disconnected a non-producing node from all its peers; its chain stopped advancing and it reported itself offline.

Impact. The Treasury web app shows Proposal state as reported by Archive events, without checking it against the chain. By injecting events, any internet client can therefore control what users see:

• Fake Proposals appear with an attacker-chosen amount, recipient and description. Voting on them fails, since no Proposal account exists.
• Real Proposals can be shown as approved, rejected, paused or paid out, with arbitrary vote counts. A fake vote for a real voter marks their actual vote as a duplicate.
• Real Proposals can be shown with fake terms, such as a small amount and a benign recipient. Voting on them succeeds, since the web app only checks that the Proposal account exists, so voters can be led to approve a payout they never saw.

Injected vote actions also break tallying: the tally prover reads them from the Archive, so the real Proposal can no longer be tallied until the Archive is cleaned, and every injection queues expensive proving work at no cost to the attacker. A single malformed event also halts the processing of all later Treasury events.

The attacker can also disconnect the Treasury’s Mina node from its peers, which stops transaction submission and the Archive feed.

Recommendation. Point both the Ingress and minaNodeUpstream to port 3000, and block WebSocket connections on both routes. If the read-only proxy is insufficient, use an allowlist that contains only the required queries and sendZkapp, for both HTTP and WebSocket requests. The full daemon API should be reachable only on a private, authenticated route. As defense in depth, the web app should compare a Proposal’s amount and recipient with its on-chain state before voting.

Client Response. Fixed in revisions 57167b6 and 1c7a351, with helm charts mina-daemon-2.3.0 and decentralized-treasury-0.10.2. Public routes now go through version 0.0.14 of the proxy, which refuses WebSocket connections and hides all mutations except sendZkapp, and the full daemon API only listens inside its pod.

Description. Break-glass operations on the Pause Controller require signatures from three of its five participants, which the Backoffice collects through imported JSON bundles. Each bundle contains the operation and its arguments together with the messageHash to be signed. The submitter validates the complete bundle with verifyOperationPackage(), but the signer only checks its structure:

if (workflowRole === "signer") {
  // ZKSECURITY: messageHash is not recomputed from the displayed operation
  const pureOperation = assertPureSigningOperation(imported);
  setOperation(pureOperation);
  return;
}

const fresh = await onRefresh();
await verifyOperationPackage(imported, fresh);

The signer then signs the imported messageHash on the Ledger, which only displays it as an opaque field element.

Impact. A malicious coordinator can show signers a harmless operation while setting messageHash to the hash of a participant-set rotation. The three resulting signatures let the coordinator replace all break-glass participants with their own keys, and thereby permanently control pausing of the Treasury and its Proposals.

Client Response. Fixed in revision 265b1c9, which recomputes the message hash from the displayed operation before signing and rejects the bundle on mismatch.

Description. Anyone can make a Proposal impossible to tally by submitting a single vote with Vote.DUMMY and PublicKey.empty(). This is a second consequence of the empty-key pruning in o1js described in the first finding: casting a vote for the empty key should require a signature that nobody can produce, but o1js drops that requirement.

TreasuryOwner.vote() accepts both values:

// ZKSECURITY: assertValid() admits Vote.DUMMY
Vote.assertValid(vote);

// ZKSECURITY: publicKey may be PublicKey.empty()
await proposal.vote({ vote, publicKey });

// ZKSECURITY: pruned by o1js when publicKey is empty, so no signature is needed
AccountUpdate.createSigned(publicKey);

The signed voter update is meant to prove control of the voting key. For the empty key, o1js removes it from the transaction, so the attacker only signs as the sender.

The resulting action is special: the Vote Reducer uses the same value as batch padding and leaves it out of the action hash, while Mina appends it to the Proposal’s action state like any other action:

const isDummyVoteAction = VoteAction.isDummy(voteAction);
// ...
toActionsHash = Provable.if(
  // ZKSECURITY: true for (Vote.DUMMY, PublicKey.empty()), whether padding or a real action
  isDummyVoteAction,
  toActionsHash,
  appendActionToHashList(toActionsHash, VoteAction.toFields(voteAction)),
);

After the attack, no Vote Reducer proof can reach the Proposal’s action state, which tallyVotes() requires.

Proof of concept. On LocalBlockchain with proofs enabled, an attacker submitted TreasuryOwner.vote(proposal, PublicKey.empty(), Vote.DUMMY), signed only with their own key. The Proposal’s action state included the action, while the unmodified Vote Reducer left its hash unchanged.

Impact. For one transaction fee, anyone can prevent a chosen Proposal from ever being tallied, without voting weight or privileged keys. Repeating this against every Proposal blocks all governed Treasury payouts. No funds can be stolen this way.

Recommendation. Mina Treasury must upgrade to the fixed o1js release. The voter update then requires a signature for the empty key, which prevents the attack. For extra robustness, TreasuryOwner.vote() could also reject Vote.DUMMY, so that padding values are never dispatched as real actions.

Client Response. Fixed in revisions 479bdc2 and 519cb86, by upgrading to o1js 3.1.0 and by rejecting Vote.DUMMY in TreasuryOwner.vote().

Description. The Treasury imports the full Mina staking ledger from its JSON export and must reconstruct exactly the ledger root committed on chain. Two account fields are byte strings in Mina, which any account can set on itself with a signature, but are decoded as JavaScript strings by the Treasury:

public async parseStakingLedgerAccount(value: any): Promise<Account> {
  return new Account({
    // ...
    // ZKSECURITY: throws on any non-ASCII character
    tokenSymbol: TokenSymbol.from(value.token_symbol),
    // ...
    // ZKSECURITY: hashes the string as decoded by Node, not the original bytes
    zkappUri: ZkappUri.from(value.zkapp.zkapp_uri).hash,
    // ...

• Token symbol: Mina only requires at most six bytes. o1js’s TokenSymbol.from() rejects every non-ASCII character, for example "é", so a single such account makes the whole import fail. This check is upstream o1js behavior.
• zkApp URI: Mina only requires at most 255 bytes, not valid UTF-8. Via the daemon’s GraphQL API, a URI can be set to invalid UTF-8 bytes, which the ledger export writes out unchanged. Node replaces them with U+FFFD when reading the file, so the Treasury hashes a different URI and reconstructs a different ledger root. Here the import succeeds, but no staking-ledger proof can match the on-chain root.

Proof of concept. On LocalBlockchain, which applies transactions through the native Mina ledger code, an ordinary account set its token symbol to "é" with a signed update; TokenSymbol.from() then throws on the stored value. For the URI, we sent a signed update with the invalid UTF-8 bytes ed b0 80 to the public GraphQL endpoint of a Mesa Lightnet node. The transaction succeeded and Mina stored the exact bytes. On a ledger containing such a URI, the root computed by the official Mina binary differs from the one reconstructed by the Treasury’s parser.

Impact. For one transaction fee, anyone can prevent the current Treasury from using every future staking ledger. Without it, no voting ledger can be derived, so no Proposal can be tallied or executed. The attacker’s account keeps its value, so the problem persists across epochs until the parser is fixed.

Recommendation. Treat token symbols and zkApp URIs as byte strings, like Mina. The importer should read them from the export as raw bytes instead of decoding them as UTF-8, and compute the token symbol field and zkApp URI hash from those bytes as Mina does. The o1js string-based constructors can’t do this. The same applies to account storage, which serializes the token symbol as its string with the toJSON() method that o1js derives for Account, and recomputes the field in Account.fromJSON(). Storing the field itself, e.g. with a custom token-symbol type in Account that keeps the same provable layout, avoids this without changing the circuit.

In addition, remove the try/catch in Account.fromJSON() that silently returns Account.empty() on any parse error. The account storage relies on this method, so parse errors currently turn into a wrong ledger root instead of a visible failure (see also the invalid public key finding).

Client Response. Fixed in revision 96b2780, which reads token symbols and zkApp URIs from the export as raw bytes, hashes and stores them as Mina does, and removes the try/catch from Account.fromJSON().

Description. Mina stores public keys in compressed form, as an x-coordinate and a parity bit, and does not require the x-coordinate to lie on the curve. The Mainnet ledger contains two such accounts, which nobody can sign for:

• B62qpyhbvLobnd4Mb52vP7LPFAasb2S6Qphq8h5VV8Sq1m7VNK1VZcW
• B62qqdcf6K9HyBSaxqH5JVFJkc1SUEe1VzDc5kYZFQZXWSQyGHoino1

The Treasury’s parseStakingLedgerAccount() parses the account key and delegate of every staking-ledger record with PublicKey.fromBase58(). That function checks that the key is a valid curve point, and throws PublicKey: not a valid group element for both accounts. The import of the full ledger fails as a result.

Fixing only the file parser is not enough. The account storage codec (Account.fromJSON()) silently replaces such accounts with an empty account, which changes the ledger root. The voting-ledger index helper publicKeyBase58ToBigInt() parses the delegate with PublicKey.fromBase58() again.

Proof of concept. We ran parseStakingLedgerAccount() over an official Mainnet staking-ledger export from September 18, 2026 (288,898 accounts), whose root matches the on-chain ledger hash. It rejected exactly the two accounts above, which each hold 66,000 MINA and delegate to themselves. The Treasury circuits accept both accounts once they are decoded without the curve check.

Impact. On Mainnet, the Treasury cannot import any staking ledger, and therefore cannot tally a Proposal or execute a payout. No attacker is needed. Since the accounts can’t sign, they will stay in the ledger unless Mina removes them in a protocol upgrade. The current Devnet ledger is not affected.

Recommendation. Decode ledger public keys from Base58 without requiring a valid curve point, as Mina does, and construct them with PublicKey.from({ x, isOdd }). This is needed in parseStakingLedgerAccount(), in Account.fromJSON() for account storage, and in publicKeyBase58ToBigInt().

Client Response. Fixed in revision 96b2780, which decodes ledger public keys without requiring a curve point in the parser, account storage, and publicKeyBase58ToBigInt().

Description. Mina commits to each event by hashing its field array with Poseidon, without the array length. Poseidon pads an odd-length input with a zero, so an event ending in a zero field has the same hash as the event without that zero:

function hashWithPrefix(prefix: string, input: Field[]) {
  let init = salt(prefix);
  // ZKSECURITY: [...fields, 0] and [...fields] hash identically if fields.length is odd
  return Poseidon.update(init, input)[0];
}

Only the event hash is part of the proved AccountUpdate, while the event fields are carried as auxiliary data. Anyone submitting a transaction can therefore drop a trailing zero from an event without invalidating the proof or signatures.

All Treasury Owner events have an even number of fields and end with the sender’s public key, whose last field is its isOdd flag. Any sender with an even key can thus shorten their event by one field. The Treasury processor receives the event with one field fewer than expected, and mistakes it for a legacy format:

if (
  // ZKSECURITY: a shortened current event has exactly this length
  data.length === payloadFieldCount ||
  legacyFieldCounts.includes(data.length)
) {
  // ZKSECURITY: the discriminator is not removed, so all fields are shifted by one
  return { kind: "fields", fields: data };
}

Each event handler decodes these fields with its event’s fromFields() and then runs PublicKey.check() on the decoded keys. After the shift, the Proposal key’s isOdd flag holds an x-coordinate, so the check throws and the handler returns false. The event router then reports the event as unhandled.

EventsProcessor handles all Treasury events in a single global order. It treats an unhandled event as a failure, and after five failed attempts marks it as blocked. The processor’s cursor only moves past successfully handled events, and while a blocked event exists, the processor stops fetching new ones. No later Treasury event is processed.

Proof of concept. With the Treasury contracts deployed on Mesa Lightnet, we paused a Proposal and removed the final zero from the emitted event before proving. The node included the transaction and the Proposal was paused; the Archive returned the shortened event. Given this event, the unmodified Proposal event handler rejected it and the router reported it as unhandled, which makes the processor block.

Impact. Any user can halt the Proposal projection, which the web app relies on, until the processor is fixed. The cheapest way is to cast a vote during the voting period. The event is part of a valid transaction on chain, so it can’t be cleaned up.

Recommendation. Decode events by their type and schema instead of inferring the format from their length. A current event that is one field short should be treated as the same event with a trailing zero. More generally, an event that can’t be decoded should not halt processing of all other events.

Client Response. Fixed in revisions dfe6234 and 338e4ed, which decode events by their discriminator and schema, restore a dropped trailing zero, and quarantine undecodable events instead of blocking the processor.

Description. The o1js fork adds a UInt128 type, which is not part of upstream o1js. Its multiplication and division are computed in the native field, whose modulus $p$ is about $2^{254}$. Since two 128-bit values can have a product of almost $2^{256}$, these operations can wrap around $p$, and the constraints don’t prevent this.

mul() multiplies in the field and only range-checks the result:

mul(y: UInt128 | number) {
  // ZKSECURITY: the integer product can exceed p, and only its reduction mod p is checked
  let z = this.value.mul(UInt128.from(y).value);
  RangeCheck.rangeCheckN(UInt128.NUM_BITS, z);
  return new UInt128(z.value);
}

If the product exceeds $2^{128}$ but its reduction modulo $p$ is below $2^{128}$, the overflow goes undetected. For example, $2^{127}·(2^{127}+1)$ returns $124580867929049525641406541344198885375$.

divMod() witnesses the quotient $q$, computes the remainder $r=x-qy$ in the field, and checks that $q$ and $r$ fit in 128 bits and $r<y$:

let q = Provable.witness(Field, () => new Field(x.toBigInt() / y_.toBigInt()));
RangeCheck.rangeCheckN(UInt128.NUM_BITS, q);

// ZKSECURITY: only proves x = q*y + r modulo p
let r = x.sub(q.mul(y_)).seal();
RangeCheck.rangeCheckN(UInt128.NUM_BITS, r);
// ...
r_.assertLessThan(new UInt128(y_.value));

Since $qy$ can exceed $p$, a malicious prover can choose a different quotient for which $qy+r=x+p$. For example, for $x=0$ and $y=2^{127}+1$, the prover can return $q=2^{127}-1$ and $r=45560315531419706090280762371685220354$ instead of zero.

Impact. Circuits using UInt128 can accept wrong products and quotients for large inputs. This does not currently affect the Treasury, where all values entering UInt128 arithmetic are always smaller than $2^{96}$, so that no intermediate result gets close to $p$. However, the type is part of a general-purpose library fork and is likely to be reused.

Recommendation. Deprecate UInt128 in the o1js fork, and use a more constrained type (for instance, UInt96).

Client Response. Fixed in o1js fork revisions ac7eb03 and d670b3e, which constrain UInt128 multiplication and division over the integers, deprecate UInt128, and add a UInt96 type. The Treasury arithmetic was migrated to UInt96 in revision dbdd613.

Description. The Treasury Owner is an o1js TokenContract, and its Proposals are accounts under the Owner’s token ID. TokenContract.deploy() requires the Owner account to be new: before deployment, the account’s access permission is none, so anyone can create accounts under its token ID.

The CLI’s --allow-deploy-to-existing-account flag (also settable through ALLOW_DEPLOY_TO_EXISTING_ACCOUNT) removes this precondition:

async () => {
  if (!allowDeployToExistingAccount) {
    AccountUpdate.fundNewAccount(senderPublicKey, 1);
  }
  await treasuryOwner.deployWithWithdrawalPermission(withdrawalPermission);
  if (allowDeployToExistingAccount) {
    // ZKSECURITY: accepts an existing account, which may already have token accounts
    treasuryOwner.account.isNew.requireNothing();
  }
},

If the flag is used for the initial deployment, an attacker can prepare a Proposal account under the future Owner’s token ID beforehand. It gets the real Proposal verification key and state of the attacker’s choice: APPROVED, an attacker-controlled recipient and an arbitrary amount. The deployment does not touch this account, so afterwards, the attacker can call executeProposal() on it and is paid out by the Owner.

The documentation says to keep the flag disabled for an initial deployment, and according to the Mina developers, it mostly exists for testing. However, an attacker can create this situation: once the Owner’s deployment transaction appears in the mempool, the attacker can send MINA to the Owner address first. The deployment then fails because the account is no longer new, and retrying with --allow-deploy-to-existing-account is an obvious fix, but plays directly into the attacker hands.

Proof of concept. On LocalBlockchain with proofs disabled, an attacker created an approved Proposal account under the token ID of an address before the Owner was deployed there with --allow-deploy-to-existing-account. After deployment, calling executeProposal() on this Proposal moved 3 MINA from the Owner to the attacker.

Impact. If --allow-deploy-to-existing-account is used for the initial deployment, an attacker that monitors the chain can drain the Treasury Owner without creating, voting on or tallying a Proposal.

Recommendation. Remove the flag from the deployment tooling, or restrict it to local test networks. A deployed Owner cannot be redeployed anyway, since its verification key and permissions can’t be changed. If an initial deployment fails because the address already exists, deploy to a fresh address instead.

Client Response. Fixed in revision e1ba69e, which removes the --allow-deploy-to-existing-account flag, so the Owner can only be deployed to a new account.

Description. treasury/proposals/proposal-detail.tsx:932-936 uses ReactMarkdown to render a user-supplied string as Markdown, where images (for example, ![](https://example.com)) are allowed. Additionally, CSP is not configured and one could create tracking pixels in this way.

Impact. A malicious party could create a proposal to link voters’ public keys with their devices (IP addresses, browsers and everything sent via the HTTP header).

Recommendation. Set a Content Security Policy whose img-src excludes external origins, or disallow images in the Markdown renderer.

Client Response. Fixed in revision 1b5bfd0, which renders Markdown images in Proposals as their alt text.

Description. The service images are built with COPY . . from the operator’s checkout, and published with devops/scripts/publish-images.sh. .dockerignore only excludes environment files at the repository root and in devops/, so every nested one is copied into the image, for example apps/cli/.env.testnet and apps/api/.env.testnet. The publish script only refuses to run if git status shows changes, which does not cover these gitignored files.

The CLI environment file written by the bootstrap script contains the private keys of the sender, the Treasury Owner and the Pause Controller. For the Devnet deployment, a single command printed them from the public image:

docker run --rm --entrypoint cat minafoundation/dt-api:41c4809 /app/apps/cli/.env.testnet

The image of the latest revision, minafoundation/dt-api:265b1c9, contains a different set of these keys, and the database password of the API. According to the Mina developers, production deployments will use Ledger signing, and the private keys in these files are only used for development.

Impact. Whatever an operator puts into these files is published with the images. The environment files hold secrets by design, so this is a permanent risk for any credentials that end up there.

Recommendation. Exclude all environment files from the image, e.g. with a **/.env* rule in .dockerignore, and remove the published images that contain them.

Client Response. Fixed in revision 2784c29, which excludes .env* files at any depth from the Docker build context.

Description. To pause or unpause a single Proposal, TreasuryOwner.togglePauseProposal() makes two separate calls. The Pause Controller checks the break-glass signatures and increments its nonce, and the Proposal toggles its state:

// ZKSECURITY: checks signatures over (proposalPublicKey, nonce) and increments the Controller nonce
await pauseController.togglePauseProposal(proposalPublicKey, signatures, nonce);

// ZKSECURITY: the actual state change happens in a sibling call
await proposal.togglePause();

The two calls are only tied together by the Owner’s proof. The proof of the Controller call commits to its own AccountUpdate and its children, but not to its parent, and the call depth that places it under the Owner is not part of the AccountUpdate hash. Anyone who sees the transaction, for example in a node’s public transaction pool, can therefore copy the Controller update, move it to the top level, and submit it on its own with their own fee payer. The copy increments the Controller nonce without toggling the Proposal, and the original transaction then fails because its nonce is outdated.

Proof of concept. On LocalBlockchain with proofs enabled, we detached the Controller update from a toggle transaction and submitted it on its own, signed only by an unrelated fee payer. The Controller nonce advanced from 1 to 2 without any pause, and the original transaction then failed with Account_nonce_precondition_unsatisfied.

Impact. Anyone can prevent a Proposal from being paused or unpaused, by repeating this for every new attempt, for one transaction fee each. For example, the proposer of an approved Proposal that the break-glass participants want to pause can block the pause and execute the payout meanwhile. Pausing the whole Treasury still works, but stops all other Proposals too.

Recommendation. Consume the authorization in the same AccountUpdate that changes the Proposal. For example, give each Proposal its own pause nonce, and let the Proposal check and increment it while setting an explicit target state:

@state(UInt32) pauseNonce = State<UInt32>();

@method
public async setPaused(nonce: UInt32, paused: Bool) {
  const pauseNonce = this.pauseNonce.getAndRequireEquals();
  pauseNonce.equals(nonce).assertTrue("Invalid proposal pause nonce");
  const status = this.status.getAndRequireEquals();
  status.equals(ProposalStatus.PAUSED).equals(paused)
    .assertFalse("Proposal pause state already matches target");
  this.status.set(
    Provable.if(paused, ProposalStatus.PAUSED, ProposalStatus.UNKNOWN),
  );
  this.pauseNonce.set(pauseNonce.add(1));
}

The Pause Controller then only verifies the signatures, over the Proposal’s key and token ID, the nonce and the target state, without changing its own state, so a detached Controller update has no effect. We tested this change with proofs enabled: detaching the Controller update no longer affects the original transaction, and replaying signatures or submitting the wrong target state fails.

This also fixes togglePause() Does Not Take the Intended Pause State as Input from our previous report.

Client Response. Fixed in revision 825de0e as recommended, with a per-Proposal pause nonce checked and incremented in setPaused(), and signatures over the Proposal’s key, token ID, nonce and target state.

Description. In o1js, the circuit of every SmartContract method depends on the network. The method hashes its own AccountUpdate in AccountUpdate.hash(), whose prefix is taken from the active Mina instance, and Mainnet uses a different prefix than Devnet. Until Mina.setActiveInstance() is called, o1js uses a default instance with network ID devnet.

All Treasury clients compile the contracts before they select the network. The CLI commands call compile() before configureMinaNetwork(), for example in the Owner deployment and in proposal create. The web app’s prover worker compiles all three contracts in compileProposalContractsInCurrentThread() and only calls Mina.setActiveInstance() later, when building a transaction. The backoffice does the same. The contracts are therefore always compiled for Devnet.

Impact. On Mainnet, every proof for a Treasury method fails, so no Proposal can be created, voted on or executed, and no break-glass operation works. The Owner and Pause Controller are deployed with signatures, so a deployment from the CLI succeeds, but installs verification keys that can’t prove anything on Mainnet. Since setVerificationKey is impossibleDuringCurrentVersion, these accounts can’t be fixed before the next hard fork and have to be replaced. Testing on Devnet or Lightnet cannot catch this, but a Mainnet test deployment that calls a contract method will.

Recommendation. Select the network before compiling any contract, in every process and worker, and include the network ID in the keys of the compile caches.

Client Response. Fixed in revision af1d956 by selecting the network before compiling in every client and worker, with Mainnet as the default, and separating the compile caches by network.

Description. createProposal() records the current stakingEpochData ledger hash in the new Proposal, and every later tally uses this ledger. Besides the voting weights, tallyVotes() reads the Treasury Owner’s balance from it, and requires a Merkle witness for the Owner account under the recorded root:

const calculatedStakingLedgerRoot =
  treasuryOwnerAccountWitness.calculateRoot(
    treasuryOwnerAccountLeaf,
    accountLedgerHashPrefixes,
  );
// ZKSECURITY: impossible if the Owner account is not in the recorded ledger
calculatedStakingLedgerRoot.assertEquals(
  stakingEpochDataLedgerHash,
  "Treasury owner account witness does not match staking ledger hash",
);

In Mina, a newly created account only appears in stakingEpochData after about two epoch transitions. Proposals created before the Owner appears record a ledger without it, and can never be tallied. This only becomes visible at the tally, after the full voting period and proving run.

Impact. Nothing prevents such Proposals. The deployment runbook’s example starts the first lifecycle at the current epoch, and it explicitly allows a start slot in the past. The first proposal period can therefore open right after deployment, and Proposals created in the first epochs can never be tallied.

Recommendation. Only open the first proposal period once stakingEpochData contains the Owner account with a nonzero balance, for example by rejecting deployment configurations whose first proposal period starts too early.

Client Response. Fixed in revision f064b62 by requiring a Merkle witness for the Owner account in createProposal(), which proves that the Owner is in the recorded staking ledger with a positive balance.

Description. This issue was pointed out to us by the Mina developers during the audit. We include it for completeness.

getLifecyclePeriodSlotRange() computes each period’s slot range as:

const toSlot = Provable.if(
  noUpperBoundToSlot,
  UInt32.MAXINT(),
  // ZKSECURITY: requireBetween() includes this slot, which is also the next period's first slot
  fromSlot.add(TreasuryOwnerSmartContract.lifecyclePeriodDuration),
);

Since requireBetween() treats both bounds as inclusive, each period has one slot too many, and its last slot is also the first slot of the next period.

Impact. This has two effects:

• With the default period length of one epoch, the last slot of the proposal period is already in the next epoch. A Proposal created in that slot records the next epoch’s staking ledger, while the off-chain pipeline prepares one staking ledger per lifecycle, taken from the lifecycle’s epoch. Such a Proposal can’t be tallied.
• In the slot shared by the voting and cooldown periods, both a vote and the tally are valid, so the transaction order decides whether a vote in that slot is counted. A vote included after the tally is accepted, but never counted.

The processor also fails on the events of a Proposal with the wrong staking ledger, which blocks all event processing as described in the finding on blocking the Proposal processor.

Recommendation. Make the upper bound exclusive, i.e., end each period at fromSlot + lifecyclePeriodDuration - 1.

Client Response. Fixed in revision ac1834b by ending each bounded period at fromSlot + lifecyclePeriodDuration - 1.

Description. To tally a Proposal, the Vote Reducer processes its votes and tracks which voters have already voted in a nullifier tree. The Proposal’s tallyVotes() requires this tree to start out empty:

voteReducerPublicInput.fromNullifierRoot
  .equals(TreasuryProposalSmartContract.emptyNullifierRoot)
  .assertTrue("fromNullifierRoot does not match");

However, the off-chain proving state is stored per lifecycle, not per Proposal. The nullifier tree, batch traces and proofs all live in one SQLite file per lifecycle, under namespaces that only contain the lifecycle ID:

static namespaceFrom(lifecycleId: string): string {
  // ZKSECURITY: shared by all Proposals of the lifecycle
  return `nullifier-ledger-${lifecycleId}-nullifiers`;
}

The tracer starts each run from the persisted nullifier root. After the first Proposal of a lifecycle has been processed, that root contains its voters, so the proof for the next Proposal no longer starts from the empty tree. The documented proving flow runs every Proposal with the same --lifecycle-id, and describes the vote-reducer clear-state command, which would reset the tree, only as a tool for retries.

Proof of concept. We traced two Proposals of the same lifecycle through the Treasury’s SQLite vote reducer service and generated a valid Vote Reducer proof for the second one, with proofs enabled. Its fromNullifierRoot was non-empty, so it fails the check in tallyVotes().

Impact. Tallies are proved manually with the CLI. Following the proving documentation, the tally of the second Proposal with votes in a lifecycle fails when the tally transaction is built, after the full proving run. Running vote-reducer clear-state before each Proposal avoids this, but the documentation only describes that command for retries.

Recommendation. Key the nullifier tree, traces and proofs by lifecycle and Proposal, and check that the nullifier tree is empty before tracing a Proposal.

Client Response. Fixed in revision b1815ca by keying the nullifier tree, traces and proofs by lifecycle, Proposal address and token ID, and by refusing to trace when the nullifier tree is not empty.

Description. The voting-ledger scheduler builds each lifecycle’s snapshot database, which takes many hours on Mainnet. Since it is meant to run on spot nodes, trace-digest regularly uploads a checkpoint of the database to S3, and after a restart, process_candidate() in voting-ledger-scheduler-entrypoint.sh restores the checkpoint instead of starting over.

The database runs in SQLite’s WAL mode, where recent writes live in a separate -wal file until they are merged into the main file. When the process is interrupted, this file stays on the persistent volume. This even happens on a regular SIGTERM, since the handler in staking-ledger-to-voting-ledger.ts ends with process.exit(143) without closing the database.

pullCheckpoint() then writes the downloaded checkpoint over the main file, but leaves the old -wal and -shm files in place. The scheduler only deletes them when building from scratch, not when restoring. When the database is opened, SQLite applies the stale WAL to the restored file, which fails with database disk image is malformed, and the scheduler falls back to a full build.

Impact. Checkpoints never take effect after an interruption, so every spot interruption restarts the full build. If interruptions are frequent, the snapshot of a lifecycle is never completed, and none of its Proposals can be tallied.

Recommendation. Delete the -wal, -shm and -journal files before restoring a checkpoint, or download it to a temporary file and rename it. Close the database properly on SIGTERM.

Client Response. Fixed in revision c83a7f0, which downloads the checkpoint to a temporary file, deletes the -wal, -shm and -journal files before renaming it, and closes the database on SIGTERM.

Description. The Proposal processor handles all Treasury events in a single global order. If handling an event fails five times, EventsProcessor.processEventWithRetries() marks it as blocked and stops processing events until an operator retries it manually. It does not distinguish permanent failures from transient ones.

A vote event depends on the staking-ledger snapshot of its lifecycle, which is prepared by the voting-ledger scheduler (process_candidate() in devops/docker/voting-ledger-scheduler-entrypoint.sh). If the snapshot is not available yet, the vote-weight lookup in StakingLedgerVoteWeightResolver.loadWeights() throws data for lifecycleid is not available. The processor blocks within about 15 seconds and stays blocked after the snapshot becomes available.

Other transient conditions have the same effect. The scheduler builds the snapshot file <lifecycleId>.sqlite in place, which takes several hours, and only writes a .done marker at the end. LifecycleStakingLedgerServiceRegistry.getService() opens the file as soon as it exists, without checking for the marker, and caches it for the lifetime of the process. Events of a lifecycle whose snapshot is still being built fail with a root mismatch, in StakingLedgerVoteWeightResolver.assertRoot() or ProposalCreatedEventHandler.getTreasuryBalanceForLifecycle(). After a rebuild, the cached handle keeps pointing to the old snapshot.

Since the readiness check of the public API calls assertProcessorReady(), the API is also reported as unavailable while the processor is blocked. The same mechanism turns the malicious events from the public GraphQL finding and the shortened event finding into a global halt.

Impact. Normal operation can halt the Proposal projection and take the public API offline until an operator intervenes.

Recommendation. Only open a snapshot once the scheduler has marked it complete, and reopen it after a rebuild. Retry transient failures, such as a missing snapshot, with backoff instead of blocking. Only block on events that can never be handled, and do not let these halt the processing of unrelated Proposals.

Client Response. Fixed in revision 338e4ed, which opens a snapshot only once its .done marker exists, reopens it after a rebuild, retries failed events with backoff instead of blocking, and quarantines events that cannot be decoded. An event that is decoded but can never be handled is still retried indefinitely and blocks later events, but we found no way to produce such an event.

Description. The Proposal projection is built from all events that are pending or canonical (isSurviving()), but assertCoherentProposalBranch() only checks that the canonical ones form a single chain. The pinned Archive Node API (0.0.9) returns events from all pending branches whose tips are at the maximum height, and only picks the best block among the tips themselves. Two conflicting transactions on competing forks therefore both end up in the projection.

The indexer also identifies events by the Archive’s database-local account update ID (eventIdentity()). If the Archive database is rebuilt, for example from precomputed blocks, these IDs change, and all events the indexer re-reads are stored a second time.

Impact. The web app can show a state that never existed on any chain, for example two pause toggles cancelling out, or two partial payouts from the same state counted together. Payouts that add up to more than a Proposal’s limit make the processor fail, as described in the finding on blocking the Proposal processor.

Recommendation. Only project events of a single branch: canonical events, plus pending events that descend from the selected best tip. Identify events by transaction-relative data only.

Client Response. Fixed in revision 338e4ed, which only projects pending events on the ancestry of a unique best tip, falls back to canonical events when tips are tied, and identifies events by transaction hash, account update index and event index.

Description. The public processor API lets clients load related entities with ?join= parameters. appendJoinPath() checks each segment of a join path against the declared relations, but limits neither the depth of a path nor the number of joins. Since Proposals and votes reference each other, a path like votes.proposal.votes.proposal… can be repeated indefinitely, and is turned into a single, very large SQL query.

Impact. Anyone can overload the database that the indexer, processor and API share. In our test, 24 requests of about 5 KB each slowed a normal Proposal list request from 38 ms to 13.7 seconds, for as long as the requests continued.

Recommendation. Limit join paths to one or two levels, limit the number of joins per request, and reject paths that revisit an entity.

Client Response. Fixed in revision 7b4c919, which limits join paths to two levels and four relation steps per request, and rejects paths that revisit an entity.

The voting ledger credits the MINA balance of every account to its delegate, and to vote, the delegate has to sign an AccountUpdate:

AccountUpdate.createSigned(publicKey);

Weight whose delegate can’t sign still counts towards the total currency that the participation thresholds are based on, but can never vote. A delegate can’t sign if:

• its access permission requires a proof;
• nobody holds its private key, such as the burn address B62qiburnzzzz…mp7r7UN6X;
• its public key is not a valid curve point, like the two Mainnet accounts from the invalid public key finding.

The Treasury’s own balance is also unlikely to vote. The Owner delegates to itself and can’t change its delegate. With the default access: proof, it can’t sign, and even with proofOrSignature, its operators are unlikely to vote with the Treasury’s funds.

In the Mainnet staking ledger of September 24, 2026, 1.18% of the total currency can’t vote, mostly 15.2 million MINA delegated to the burn address. With the Mina Foundation’s working target of 55 million MINA in the Treasury, this would rise to 5.4%, and the 20% to 50% participation thresholds would correspond to 21.1% to 52.9% of the usable weight. Given how concentrated Mainnet delegation is, this does not come close to making Proposals impossible to pass.

Client Response. Acknowledged. The client documented the unusable voting weight in revision fbcd14a, and kept the protocol unchanged.

When tallying, TreasuryOwner.tallyVotes() checks the vote reducer proof against the Proposal’s on-chain action-state history. The proof has to supply five action states, which must all be non-initial, pairwise distinct, and among the five states stored on the Proposal account. The uniqueness check fixes the finding Action State Uniqueness Not Checked, Allowing Vote Discarding from our previous report.

A consequence is that a Proposal can only be tallied if its votes were dispatched in at least five distinct slots. Mina only shifts the action-state history when actions arrive in a new slot, so votes in the same slot produce a single new entry. If votes land in fewer than five slots, the history still contains the initial state, and the tally fails. Since no votes can be dispatched after the voting period, the Proposal can then never be approved, even if a single large voter already reached the participation threshold and majority.

Effectively, this acts as an additional, implicit participation threshold for accepting a Proposal, and is mentioned as such in the protocol documentation.

Client Response. Acknowledged. The client documented that votes must be included in at least five distinct slots in revision fbcd14a.

Description. To tally a Proposal, the CLI looks up the Owner account in the staking ledger and passes it with its Merkle witness to tallyVotes(). The lookup takes the first account with the Owner’s public key:

const treasuryOwnerIndex = stakingAccounts.findIndex((account) =>
  // ZKSECURITY: does not check account.tokenId
  account.pk.equals(treasuryOwnerPublicKey).toBoolean(),
);

Mina accounts are identified by public key and token ID, and anyone can create a custom-token account at any public key. An attacker who does this at the Owner’s address before the Owner is deployed, for example by front-running the deployment transaction, gets an account that precedes the Owner in every later staking ledger. The CLI then selects this account, and the tally circuit rejects it since it requires the native-token Owner. Every tally through the CLI fails, until the lookup is fixed.

Impact. The attacker gains nothing and only causes an annoyance that is easy to fix in the client, so this is unlikely to happen in practice.

Recommendation. Select the Owner account by both public key and TokenId.default, as the API’s default-token-treasury-account.ts already does.

Client Response. Fixed in revision f064b62 by selecting the Owner account by both public key and TokenId.default.

Description. The decentralized-treasury Helm chart runs all Treasury pods under a single ServiceAccount, including the public API, web and proxy. This account can scale the proving workers, and the runbook suggests attaching the S3 role of the proof pipeline to it. The token can’t be turned off for individual pods, and not even globally: the chart sets automountServiceAccountToken: {{ .Values.serviceAccount.automount | default true }}, and Helm’s default treats false as unset.

In the mina-staking-ledgers-provider chart, the Nginx server that the Treasury proxy exposes publicly shares a pod with the ledger-fetch loop. Their common ServiceAccount can list pods and create pods/exec sessions in the whole devnet namespace.

Impact. An attacker who gains code execution in a public pod can stop or overscale the proving fleet and modify the proof pipeline’s S3 data, or, through the ledger server, execute commands in any pod of the namespace. We did not find a way to get code execution in these pods.

Recommendation. Use separate ServiceAccounts for public and internal workloads, and bind the scaling permission and the S3 role only to the components that need them. Fix the automount template so that false takes effect, and turn it off for public pods. Split the ledger provider’s fetch loop and Nginx server into separate pods, so that the public server has no token.

Client Response. Fixed in helm-charts PR #346, pinned in revision c00e8f8. Each Treasury workload now has its own ServiceAccount, only the proving scheduler can scale workers and mounts a token, cloud roles can no longer be shared, and the ledger provider’s Nginx server runs in a separate pod without a token.