FAQ
This FAQ answers common questions about S.I.G.N. and the Sign ecosystem, with an emphasis on how the system is structured and how to use it correctly. It is not a replacement for the architecture and security documentation.
If you are new to the ecosystem, start with:
S.I.G.N.
What is S.I.G.N.?
S.I.G.N. is a sovereign digital infrastructure framework for deploying national-scale systems for money, identity, and capital. It focuses on enforceable policy controls, controllable privacy, and inspection-ready evidence so institutions can operate systems that hold up under oversight, disputes, and audits.
See S.I.G.N. Overview for the full narrative and design goals.
What are the three national systems in S.I.G.N.?
S.I.G.N. organizes national digital infrastructure into three system domains:
New Money System: policy-controlled digital money rails for CBDC and regulated stablecoins
New ID System: verifiable identity and credential issuance and verification across agencies and regulated operators
New Capital System: regulated real-world asset and programmable capital infrastructure for issuance, distribution, and reporting
These are described in detail under:
Is S.I.G.N. a blockchain, a single ledger, or a vendor platform?
No. S.I.G.N. is a system architecture and operating model that can use one or more ledger and data availability options, depending on sovereignty, privacy, performance, and compliance requirements.
The goal is to avoid coupling national policy and oversight to a single vendor or ledger design. See Reference Architecture for the layering model and trust boundaries.
How do Sign Protocol, TokenTable, and EthSign fit under S.I.G.N.?
S.I.G.N. is the top-level narrative and architecture. The products are implementation components that align to parts of the stack:
Sign Protocol provides the evidence and attestation layer used for verification, authorization proofs, and audit trails.
TokenTable provides capital allocation and distribution primitives, typically for regulated issuance and program distribution workflows.
EthSign provides agreement and signature workflows that can integrate with identity and evidence primitives.
See Products for the product map and intended use.
Sign Protocol
What is Sign Protocol?
Sign Protocol is an evidence and attestation layer for producing and verifying structured claims. A claim can represent a statement, an authorization, an eligibility result, an approval, a verification outcome, or other system-relevant facts that must be inspectable later.
The core idea is to make verification reusable across applications by standardizing how claims are structured, signed, stored, queried, and referenced.
See Sign Protocol.
Is Sign Protocol a blockchain?
No. Sign Protocol is not itself a base ledger. It can use underlying chains and storage layers for anchoring, settlement, and tamper-evidence, but it is best understood as a protocol layer that defines how attestations and related proofs are produced and verified.
This separation supports interoperability and reduces coupling between application workflows and any single ledger environment.
What is an attestation?
An attestation is a signed, structured statement about a subject, typically bound to a schema that defines its fields and semantics. An attestation is meaningful only relative to its verification context, including who signed it, what authority they had, what schema it conforms to, and how revocation and updates are handled.
For precise definitions, see:
What is the difference between an attestation and "evidence"?
An attestation is the signed statement. Evidence is the supporting material that makes the statement credible and inspectable, such as references to documents, cryptographic proofs, verification transcripts, or audit artifacts.
A well-designed system treats evidence as a first-class input to verification and dispute resolution. Evidence handling is closely tied to privacy and access control. See Security & Privacy.
What is a schema?
A schema defines the structure and semantics of an attestation. It specifies what fields exist, how they are encoded, and how verifiers should interpret them.
Schemas are critical for interoperability because they make attestations machine-verifiable and comparable across applications and organizations.
See:
What is the Schema Registry?
The Schema Registry is the system for registering and discovering schemas used by Sign Protocol. It enables reuse, consistent interpretation, and ecosystem interoperability, while providing a stable reference for verifiers.
See:
Where does attestation data live, on-chain or off-chain?
Both patterns are supported, and the correct choice depends on privacy, cost, latency, and audit requirements.
Common approaches include:
On-chain anchoring for integrity and global verifiability
Off-chain storage for sensitive or large payloads, with cryptographic binding to an on-chain commitment or identifier
See Reference Architecture and the developer documentation sections on writing and querying data.
How do I verify an attestation?
Verification typically includes:
Schema verification: confirm the attestation conforms to the referenced schema
Signature verification: confirm the signer and the signing domain
Authority verification: confirm the signer was authorized to issue that type of statement in the relevant governance model
Status verification: confirm revocation, expiration, supersession, or dispute status
Evidence verification: confirm referenced proofs or artifacts meet the verifier's acceptance policy
For implementation, see:
Can attestations be edited or deleted?
In general, you should treat attestations as append-only records. Instead of mutating history, systems typically:
Revoke attestations
Issue a superseding attestation
Attach dispute or correction attestations under defined rules
The correct approach depends on your governance and audit requirements. For operational guidance, see Governance & Operations.
What networks and runtimes are supported?
Network support evolves over time and depends on deployment and operational requirements.
For the authoritative list, see:
How is Sign Protocol different from EAS?
EAS is commonly used in EVM environments and is tightly shaped by the EVM execution and data model.
Sign Protocol is designed as an attestation and evidence layer that can be deployed across multiple environments and can support different storage, privacy, and verification models. The practical differences typically show up in interoperability, data-location strategies, and how the protocol integrates with non-EVM systems.
If you are choosing between the two, decide based on your target environments, verification requirements, and long-term governance constraints.
TokenTable and EthSign
What is TokenTable?
TokenTable is a product for capital allocation and distribution workflows. It is typically used where eligibility, allocation rules, controlled distribution, and reporting requirements must be implemented as an auditable system.
See TokenTable.
What is EthSign?
EthSign is a product for agreements and signatures, designed to support institutional workflows where execution, authorization, and evidence must be captured reliably.
See EthSign.
Do TokenTable and EthSign require Sign Protocol?
Not strictly. They can be used as standalone products, depending on deployment architecture.
In sovereign or regulated deployments, the common pattern is that agreements, allocations, and program operations benefit from a shared evidence layer so that verification and audit do not have to be rebuilt per application.
Contributions and community
Do you accept public contributions?
Yes. Contributions are welcome where they improve correctness, security posture, developer experience, and integration quality.
Typical contribution paths include:
Documentation fixes and clarifications
Bug reports and reproducible test cases
Pull requests to relevant repositories, where applicable
Follow the repository contribution guidelines for coding standards and review expectations.
How do I report a security issue?
Do not disclose sensitive vulnerabilities in public issue trackers.
Use the security reporting process defined by the project. If a dedicated security contact is not listed in the repository, start with the organization contact method provided in the documentation site or the repository metadata, and request secure disclosure instructions.
Also review:
Where should I ask questions or send feedback?
Use the most appropriate channel for the type of request:
Documentation issues: open an issue or pull request in the relevant repository
Developer support: use the community or developer channels referenced by the project
Product and deployment discussions: use the contact paths intended for institutional engagements
When possible, include environment details, expected behavior, actual behavior, and minimal reproduction steps.
Last updated
Was this helpful?