Public Institutions & Research

Four questions already bounded, and somewhere for each answer to land.

A research question is easy to name and expensive to bound: what would count as an answer, and what would change if one arrived. Three design decisions are still open here — how a subject reference is derived, who operates the transparency log, and how verification time is attested — and a fourth asks how far a reviewer can rely on a reason code alone. Each is a decision the protocol is waiting on, so an answer would settle it.

Institutions

One of these questions could already be in your field.

Each open question falls within cryptography, data protection or market infrastructure, so a group that already works in one of those would need no new remit to take one up.

  • Public institutions

    Bodies working on market infrastructure and on how confidential financial evidence can be checked across institutions.

  • Universities

    Groups in applied cryptography, data protection and finance, where the subject-reference question sits.

  • Research centers

    Centers working on cryptographic protocols and key management, where the transparency-log question sits.

  • Innovation hubs and public funding programs

    Programs that fund applied work on financial infrastructure and could host a study of one open question.

Research themes

None of the questions needs an issuer's evidence.

A study of confidential financial evidence usually stalls on access: the material belongs to someone under no obligation to share it. These four questions are about the record a verification leaves behind: the reference, the log, the time, the reason code. You would have no data-sharing agreement to negotiate, and an answer would hold for any issuer.

  • Subject references

    A subject reference ties entries to the same asset. A platform has to be able to compute it; an outsider must not be able to trace it back. The two pull against each other.

  • Transparency log operation

    Who operates a transparency log, under which key and with what attestation when that key rotates.

  • Attested time

    An issuer's key is judged as of a point in time. How is that time attested, and which timestamp authority should a verifier accept?

  • Coded outcomes

    How far a reviewer can rely on a reason code without seeing the evidence behind it.