How Unsigned is built
Unsigned replaces a party that a small organization can never have: a neutral person who collects answers, keeps them secret, and reports only what is safe to report. Here that person is a hardware enclave, and its rules are public.
What it guarantees
- No party outside the enclave can read an individual answer: not the organizer, not the operator, not the developer.
- One answer per invited person. The organizer cannot add answers or tell which link belongs to whom.
- No results before the close time, unless everyone invited has answered, and none below the minimum group size.
- Comments come out only as themes. Then every answer is erased.
- The questions and rules cannot change after the survey is created.
Architecture
RESPONDENT (no wallet) ORGANIZER (NEAR account)
| |
| form page: encrypts the answer | creates the survey:
| to the enclave key (X25519 + AES-GCM) | questions, close time, minimum group
v v
OutLayer HTTPS API NEAR contract (public rules, results)
| |
v | anyone may request the tally
OutLayer enclave (Intel TDX) <-------------+
| sealed storage: code hashes, answers
| reads rules and time from NEAR
'--> NEAR AI Cloud, private model in a TEE
(themes, signed response)
The NEAR contract holds what must be public and permanent: the rules of each survey and its final result. The enclave holds what must stay secret: the keys, the invite codes and the answers. The two meet only through attested calls.
Features, and why each one exists
| Feature | What it does | Why it matters |
|---|---|---|
| Encrypted on the device | Answers are encrypted in the browser to a key that exists only inside the enclave. | Even OutLayer’s own API servers see only ciphertext. |
| One-time invite links | Each link carries a random code that works once. The enclave keeps only hashes of the codes. | Nobody can add answers. Codes leave the enclave only encrypted to the organizer, because on-chain output is public. |
| Rules fixed in public | Questions, close time and minimum group are written on NEAR at creation and copied by the enclave at setup. | Nobody can change the rules of a running survey. |
| Time from the chain | The close is decided with NEAR block time. | Validators agree on it and anyone can check it. The host machine’s clock is not trusted. |
| Minimum group size | Below the minimum, nothing is published. | In a team of four, even an average can point to a person. |
| Themes instead of quotes | A private AI model in its own enclave writes short themes. A copy check rejects any summary that repeats four words from an answer. | Managers recognize how people write. |
| Signed AI response | NEAR AI signs hashes of the exact request and response. The enclave checks both. | Anyone can confirm which private model produced the themes. |
| Erased after the summary | At tally time the enclave stores the result and overwrites every answer. | Nothing is left to read, leak or hand over. |
| Anyone can request the tally | After the close, any account can publish the results. A request without the AI key changes nothing. | Unwelcome results cannot be held back, or forced into numbers only. |
| Public test flag | Test surveys may close early, and are marked as tests in public. | On mainnet, the contract and the enclave both refuse an early close. |
Threat model
| Who | Tries to | Why it fails |
|---|---|---|
| Organizer | Read individual answers | They exist only sealed in the enclave, then are erased |
| Organizer | Get results early or from a few people | Close time and minimum group are enforced in the enclave |
| Organizer | Add fake answers | Only valid one-time codes are accepted |
| Organizer | Change questions after answers arrive | Questions are fixed on-chain at creation |
| Organizer | Block unwelcome results | Anyone can request the tally after the close |
| Email admin | Read invite links in mailboxes | Codes reveal nothing about answers or who answered |
| Manager | Recognize writing style | Only themes are released, with a copy check |
| Chain reader | Copy invite codes from public outputs | Codes are returned only encrypted to the organizer |
| Operator of the API | Read answers in transit | Answers are encrypted to the enclave in the browser |
| Outsider | Submit answers | No valid code, no answer |
Known limits
Splitting a team into separate surveys. An organizer could try to give each person a different survey and fill the other invitations with his own answers, so that each result shows one real answer. Because the enclave allows only one open survey per organizer, this would need a separate NEAR account for every survey, and it would only work if colleagues never compared the survey they received. The one shared link in the roadmap removes it completely.
Hardware trust. Security depends on Intel TDX, the GPU enclaves used by NEAR AI Cloud, and their attestation chains.
The relay. A small server forwards respondents’ calls and pays for them. It cannot read, change or add answers: they are encrypted to the enclave, and it holds no invite codes. It could only delay or drop requests, without knowing what they contain. If needed, it could be replaced by invite links that carry their own one-time NEAR function-call key, so the browser sends the answer through the contract without any server.
Request costs. A small relay keeps the payment key on the server, so it never appears in a page. Someone could still send many requests; each costs a fraction of a cent. A rate limit is future work.
Not a reporting channel. Individual cases, such as harassment, cannot be investigated through Unsigned, by design.
Roadmap
One shared link. Instead of handing out private links, the organizer posts a single link in the team’s channel. Each person joins with a work email, verified inside the enclave, and each address can answer once. Because everyone receives the same link in the same place, a team cannot be split into separate surveys without everyone seeing it, and the organizer never holds an invite code.
A rate limit on the relay, so that a flood of requests cannot drain the account that pays for respondents’ calls.
How the design was stress-tested
We used residuality theory, a method for software architecture by Barry O’Reilly. Instead of listing likely risks, it hits a simple design with many stressors, technical, human, economic and legal, and asks for each one: what is left of the system afterwards? The design is then changed so that the useful part survives. We started from the simplest version that worked and applied twenty stressors. A selection:
| Stressor | What it broke | What we changed |
|---|---|---|
| The organizer never closes the survey | Unwelcome results stay hidden | Close time fixed at creation; anyone can request the tally |
| The organizer edits a question after answers arrive | Answers become misleading | Questions written on-chain at creation, copied by the enclave |
| Someone reads the public chain | Invite codes appeared in a public transaction result | Codes returned only encrypted to the organizer’s key |
| A stranger requests the tally without the AI key | Could force a numbers-only result | Such a tally is refused and stores nothing |
| The AI service is down at tally time | Comments could be lost or exposed | The tally fails closed and can be retried; raw text is never released |
| A manager recognizes writing style | Anonymity breaks through the words themselves | Themes only, with a copy check inside the enclave |
| Many people answer in the same minute | Answers could overwrite each other | One sealed storage key per invite code |
| A court orders “who wrote this?” | Pressure on the operator | The system cannot answer: codes are never linked to people, and answers are erased |
We then counted how often each part of the system was affected. The organizer’s own powers were affected by 8 of the 12 main stressors, more than any other part; the enclave logic followed with 7. That gave the two rules the whole design follows: the organizer acts only at creation, and after that nobody controls the survey; and the enclave logic stays small and fully tested. The analysis continued during the build: the public-chain stressor above was found while writing the organizer tools, and fixed the same day.
Built with
NEAR, OutLayer and NEAR AI Cloud.