Ambiguous requirement of auditor signatures

The token params allow specifying multiple auditors (with the --auditors flag in tokengen).

In the validation (token/core/common/validator_auditing.go), only one auditor signature suffices for the token transaction to succeed. It is not immediately clear for the user that this is the case: one could assume that all auditor signatures are required.

Whether we want to accept "1 out of n" or "n out of n" auditor signatures, it should be clear from tokengen and perhaps readme or code comments how the validator behaves.

Thanks for raising this, I agree this is ambiguous from a user’s point of view.

From reading the issue and the current validator behavior, it seems like the implementation effectively follows a “1-of-N auditor signatures” model, but that isn’t clearly documented and could easily be interpreted as “N-of-N required”.

I’d like to contribute here by:
• Auditing the current behavior in token/core/common/validator_auditing.go
• Making the effective signature requirement explicit (1-of-N vs N-of-N)
• Updating relevant documentation (README / token-gen docs) and adding clarifying comments where appropriate

Before proceeding, I just want to confirm:
• Is the intended model 1-of-N auditor signatures by design?
• Or is this ambiguity meant to be resolved by making the requirement configurable?

Once clarified, I’m happy to put together a PR to address this

@adecaro

Thanks for the offer!

As far as I'm aware, the auditor requires the secret parts of the token inputs. In other words, if you receive a token in a transaction that is co-signed by Auditor 1, and then try to spend that token with a signature of Auditor 2, the second transaction will fail because it cannot find the cleartext information. If that's true, it would be risky to allow 1-of-N, because the network could get fragmented and some tokens could become unspendable (unless the developer implemented their own measures against that). I could be wrong about that though! @adecaro, can you weigh in here please?

@adecaro

Thanks for the clarification, that makes sense.

If the auditor needs access to the secret parts of the token inputs, then allowing 1-of-N signatures could indeed lead to fragmentation or unspendable tokens, as you described.

I agree that this is likely intended behavior rather than just a documentation gap, but it would be great to confirm the exact design expectation (1-of-N vs N-of-N).

Once clarified, I’m happy to:
• Update the documentation to clearly describe the intended signature model
• Add comments in the validator code to make the behavior explicit
• Ensure token-gen usage reflects the correct semantics

Looking forward to @adecaro’s input, thanks again for the detailed explanation.

@arner

Thanks both @arner and @sid200727 .

So, let's first look at what the current token drivers do. Both fabtoken and dlog require only one signature from any of the public keys listed as belonging to the auditors. It like having 1-out-of-N behavior.
The drivers do not check that these public keys belong to the same entity. So we can have the following situations:

There is only one auditor entity. During a key rotation phase, two valid public keys can be present at the same time.
There are multiple auditors each having one or more public keys in the list.

So, ultimately, it is the token driver that needs to decide which policies are supported.
Tokengen only loads these public keys in the public parameters, nothing else.

I would update the documentation with these details and leave to others the implementation of other policies in the current drivers or other drivers.

Wdyt?

Thanks for the clarification, that helps a lot.

Based on this, I understand that:

The current behavior in both fabtoken and dlog drivers is 1-of-N auditor signatures.
The validator does not enforce same-entity checks.
Multiple auditor public keys may coexist (e.g., during key rotation).

To remove ambiguity, I propose to:

Make the 1-of-N behavior explicit in the validator code (token/core/common/validator_auditing.go) via comments.
Update the README and token-gen documentation to clearly state that auditor verification currently follows a 1-of-N policy.
Clarify that alternative policies (e.g., N-of-N or entity-based checks) are not currently enforced by drivers.

If that sounds good, I’ll prepare a PR focusing on documentation and clarifying comments (no behavior changes).

Please let me know if you'd like anything else included.

Thanks for the clarification, that makes the current behavior clear.

I’ll proceed with a PR that:

Makes the 1-of-N behavior explicit in the validator code via comments.
Updates documentation to clearly state that auditor verification currently follows a 1-of-N policy.
Clarifies that same-entity or N-of-N policies are not enforced by current drivers.

I'll avoid behavior changes and focus on eliminating ambiguity.

Thanks!

@sid200727

Thanks much, @sid200727

Thanks for the clarification.

I’ve opened a PR #1404 to explicitly document the current auditor signature semantics.

The implementation follows a 1-of-N policy:
• If auditors are configured, at least one valid auditor signature must be present.
• Multiple auditor keys may exist (e.g., for key rotation).
• The validator verifies each provided signature independently.
• N-of-N semantics are not enforced.

The PR does not change runtime behavior — it only clarifies the existing semantics in code and documentation to remove ambiguity.

Please let me know if any additional clarification is needed.

Navigation Menu

Repository navigation

Ambiguous requirement of auditor signatures #1237

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Ambiguous requirement of auditor signatures #1237

Description

Activity

sid200727 commented on Feb 11, 2026

arner commented on Feb 11, 2026

sid200727 commented on Feb 12, 2026

adecaro commented on Feb 13, 2026

sid200727 commented on Feb 18, 2026

sid200727 commented on Feb 23, 2026

adecaro commented on Feb 23, 2026

sid200727 commented on Feb 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions