# Welcome to Zipwire Zipwire is used by part-time and freelance workers, their bosses, and the hard-working people within agencies, People Ops and HR departments. ## Quick links {% content-ref url="/pages/8JvCn434qgdJsDEh58wb" %} [What is it?](/overview/what-is-it) {% endcontent-ref %} {% content-ref url="/pages/hX8H628Vo5EKahw063kI" %} [Our Features](/overview/our-features) {% endcontent-ref %} ## Get Started We've put together some helpful guides for you to get setup with our product quickly and easily. {% content-ref url="/pages/pPtYDHv56zX5cShb03ef" %} [Set up your workplace](/zipwire-approve/set-up-your-workplace) {% endcontent-ref %} {% content-ref url="/pages/FMFghW6Ch4dDElAxn3pn" %} [Zipwire MCP Server](/use-cases/for-agents/zipwire-mcp-server) {% endcontent-ref %} {% content-ref url="/pages/0aZGFGgcMhVJhsKbl5y8" %} [Getting Started with the CLI](/tools-and-integrations/getting-started) {% endcontent-ref %} ## Pricing Zipwire uses different pricing models: Approve and Collect have free tiers, while Attest is paid from the start. {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} {% hint style="info" %} **Free Tiers Available** Zipwire Approve and Zipwire Collect start free with generous allowances. You only pay when you exceed the free limits. Zipwire Attest uses a one-time payment model per ID verification. {% endhint %} # What is it? Zipwire helps you manage your temporary, freelance or contract workers – anyone who's paid for the time they put in. ### Three products Zipwire currently has three products, all aimed at helping you manage people and identity verification. * **Zipwire Approve** is a really neat timesheet system and contractor management system, useful if you run a business using flexible workers - IT pros, consultants, personal trainers, cleaning staff. * **Zipwire Collect** is an easy-to-use automated document collection system, useful for ID checks, KYC, AML, customer due diligence and onboarding. * **Zipwire Attest** is a self-service platform where individuals can register, connect their Ethereum wallet, and get blockchain attestations for their identity and documents. Users can obtain Proof of Personhood attestations and create cryptographic proofs to verify specific information without revealing their full documents. Both Zipwire Collect and Zipwire Approve are aimed at staffing agencies or companies using temporary workers, but Zipwire Collect has a more general audience since it can be used by anyone who wants to collect documents from anyone else, for any reason. Zipwire Attest serves individual users who want to build their digital identity and reputation on the blockchain. {% hint style="info" %} **Separate Billing** The Zipwire Collect functionality is billed independently from Zipwire Approve and Zipwire Attest, so you can use one, two, or all three products. Since all products live together in the same app, using multiple products feels natural. Zipwire Approve and Zipwire Collect use consumption-based pricing with generous free allowances. Zipwire Attest uses a one-time payment model per ID verification. Our pricing is predictable and scales with your usage. It's in our interest to see your business grow. {% endhint %} ## Zipwire Approve: Explain it to me in plain English It's a kind of mini CRM for contract workers and agencies. It has the concept of the worker, the client, the assignment their on and rate, an approver or line manager, and the backoffice. Interestingly, the approver and the backoffice don't have to work for the same firm, so it works brilliantly when you have workers based onsite and their work is approved by the client. The other interesting thing is that the worker is an independent Zipwire user and their time journal is private, we only use it to fill-out their timesheet, and we do that according to configurable rules, eliminating most mistakes. Imagine that Amazing People Limited uses temp workers and puts them with their client, Prestigious Corp. First, Amazing People would need to collect certain documents from the temp worker before they can even start, and they may also collect documents from Prestigious Corp for compliance, but that's Zipwire Collect's job. Once the worker has cleared their ID and AML checks, they'll need to frequently report how long they worked so they can be paid for that time, and if they're freelance, they may even have to invoice Amazing People (who'll have to re-invoice Prestigious Corp with their margin). A line manager at Prestigious Corp will approve the timesheet that the worker has submitted and it is routed to the back office processors at Amazing People. There may be hundreds of workers at Prestigious Corp. Zipwire Approve helps both Amazing People and Prestigious Corp to collect all this time data and get everyone paid each week or month, and prepare correct invoices. It's a lot of work collating and checking everything if you're using emails, texts, photos of paper. Worse, workers often incorrectly complete their timesheet - often silly mistakes like forgetting a public holiday but sometimes they put the wrong pay rate in. Software for timesheeting is usually very basic and can even lead to more errors. These fat finger errors and typos, although probably unintentional, can raise doubts and damage trust. ### Is it right for me? It has tools for charging clients for the supplied "human resource", making it ideal for staffing agencies, but it works perfectly for companies who run lots of flexible workers, like gyms and their many personal trainers, construction companies and their skilled contractors, or nursing homes. Workers can be configured with pay and charge rates: how much the worker gets paid versus how much they're charged to the end client. Zipwire Approve has unique features which make it easy to record time using WhatsApp, the command line (CLI), and AI language models. This radically reduces mistakes, because: * Workers keep a detailed record in a central, private journal. * Zipwire Approve uses this data to fill out their timesheet according to the rules of the assignment. * The timesheet has a very low chance of being wrong, much reducing waste. You'll find features to aid with managing assignments, clients, reporting, invoicing and search, and we're working on some exciting **new features** to allow: * Charging clients for work and paying workers out in seconds using cutting edge digital payment tokens and digital wallets. These features will be charged for separately so you're not paying for stuff you don't use. ### What's different about Zipwire Approve? A lot. It has a **radically different design** to any other timesheet system**.** Zipwire Approve was designed from the ground-up for the flexible way we work, post pandemic**.** #### Track as you work For starters, freelancers can rapidly track as they go in detail by shooting off a quick message on WhatsApp, "yesterday I worked all day on project A", or from the terminal with the [Zipwire CLI (zw)](/tools-and-integrations/tools). Otherwise, workers have to either scribble notes in a diary, or just try to remember the whole month. At the end of the month (or whenever), Zipwire Approve fills out their timesheets, plural... #### Going plural Plural? It's becoming common for contractors to work for two distinct clients, through different agencies. If a person is working for two firms using Zipwire, it's smart enough to put the right times on the right timesheets and send them to the relevant people at each firm, even though they track everything in a single journal. #### Fewer mistakes Zipwire tracks detailed time in the journal and *then* fills out the timesheet according to the rules set for that particular assignment, so the timesheet is always correct. It also highlights anomalies like bank holidays, a common cause of timesheet rejection and invoice rework. #### Optional invoicing It's not just about timesheets. Zipwire can also produce the invoice from the sender and the invoice to the client, either per timesheet or as a bundle on one big client invoice. Rekeying everything into the your invoices is a common source of errors which erode the trust of your hard-earned clients. #### No passwords There are no passwords because people use passkeys or Ethereum wallets - one less thing to worry about for the People Ops department. We have two factor authentication covering critical functionality. You worker's journal is private and so they own and control this data. Zipwire Approve only uses it to fill-out their timesheet, and copies of the timesheet are sent to the relevant parties via teams inboxes, see below. #### Items are sent to teams And not individuals. When the boss suddenly has to leave town it can cause hold-ups in approval, paying the contractor, charging the client and cashflow headaches. By sending to a team, deputies can instantly be added to the team to approve or process items and unstick the pipeline, without anyone having to resend anything. And lots more, see our features list. ## Zipwire Collect: Effortless onboarding and ID checks for your modern workforce Zipwire isn't just about making timesheets easier; it's about making your entire worker management process smoother. That's where **Zipwire Collect** comes in. **The burden of onboarding people** Getting new temporary workers set up can be a hassle. You need to collect and verify various documents, like passports, visas, proof of address and even professional insurances. This often involves chasing people down for missing paperwork, leading to delays and frustration, and may involve retaining evidence and records of checks should for compliance. **Zipwire Collect streamlines and automates the onboarding process, saving you time and ensuring compliance.** Here's how: **Government-approved remote ID and AML checks** With our Yoti integration you can ask people to complete a "selfie check" using their mobile phone and get a detailed report on its authenticity as well an conduct optional Anti-Money Laundering background checks. **Pre-built packs** Define the documents you need based on location and worker type (e.g., passport for overseas workers, proof of address for local contractors). **Automatic chasing** No more chasing down missing documents! Zipwire Collect automatically prompts new workers to submit the required documents. **AI-powered verification** Reduce the risk of errors with Zipwire's AI system. It can analyze documents to verify authenticity and expiry dates. **Conditional logic** Set up smart rules to only collect specific documents based on information in others. For example, only request a visa if a passport isn't from a certain country. **Secure storage** All worker data is encrypted and stored securely, giving you peace of mind. **Benefits everyone:** * **HR and managers:** Save time chasing paperwork and focus on other tasks. * **Your workers:** Get set up quickly and easily without the hassle of manual document submission. * **Your business:** Ensure compliance with right-to-work checks and other regulations. **Zipwire Collect integrates seamlessly with Zipwire Approve,** meaning timesheet tracking can begin as soon as the onboarding process is complete. This creates a smooth, efficient experience for both you and your workers. **Ready to simplify onboarding and streamline your entire workforce management? Try Zipwire Collect today!** ## Zipwire Attest: Your Digital Identity on the Blockchain In today's digital world, proving who you are online is becoming increasingly important. Whether you're accessing DeFi protocols, participating in DAOs, or using Web3 applications, having a verifiable digital identity can open doors and build trust. That's where **Zipwire Attest** comes in. **The problem with digital identity** Traditional identity verification often means sharing your personal documents with every service you use. This creates privacy risks, security vulnerabilities, and a fragmented experience where you have to prove yourself repeatedly to different platforms. **Zipwire Attest gives you control over your digital identity through blockchain attestations.** Here's how it works: **Self-service registration** Simply visit our website, connect your Ethereum wallet, and register for an account. No complex setup or technical knowledge required. **Government-approved ID verification** Complete a secure ID check using our Yoti integration - the same technology trusted by banks and government services. This verifies your identity and proves you're a real person. **Blockchain attestations** Upon successful verification, you can claim attestations directly to your wallet: * **"IsAHuman" attestation**: Proof of Personhood that you're a verified human * **"Private Data" attestations**: Cryptographic proofs of your documents (passport, AML report) without revealing the actual data **Selective disclosure with cryptographic proofs** When you need to prove something about yourself (like your age or nationality), you can generate a cryptographic proof that reveals only the specific information needed, without sharing your full documents. **Universal verification** Your attestations work across all dApps and platforms that support EAS (Ethereum Attestation Service). Once attested, you can use your proofs anywhere in the Web3 ecosystem. **Privacy-first approach** Your personal documents never leave your control. Only cryptographic hashes are stored on the blockchain, ensuring complete privacy while maintaining verifiability. **Benefits for you:** * **Privacy**: Share only what you need to, when you need to * **Control**: Your identity data belongs to you, not to platforms * **Efficiency**: Get verified once, use everywhere * **Trust**: Build reputation across the Web3 ecosystem * **Security**: Cryptographic proofs ensure data integrity **Benefits for platforms:** * **Verified users**: Know you're dealing with real humans * **Compliance**: Meet regulatory requirements while respecting privacy * **Trust**: Reduce fraud and build confidence in your community * **Efficiency**: No need to run your own identity verification **Ready to take control of your digital identity? Get attested with Zipwire Attest today!** # Who can use it? Zipwire is suits any situation with a worker, their boss and someone who processes a timesheet, usually with a view to paying the worker. Our app can be used by a range of businesses and individual users across industries, from technology recruitment to outdoor activity centres. See examples in the next section.
Staffing Agencies & Recruiters Recruiters and temp agencies will get great value from Zipwire. Our product is designed for the complex relationship between agency, flexible worker and end client. The staffing agency can create their Zipwire workplace and configure its branding so that senders and approvers are all reminded of the services provided by the agency. Senders can be configured with the rate they are paid and the rate they are charged to the client at. The billing plan allows the agency to customise the minimum billable unit of time, such as hours or half-days, and the maximum for each day, and even set weekend and overtime rates. Where the workers are freelancers with their own companies, you can configure Zipwire to automatically create an invoice from their company and attach it to the timesheet. You can also setup client invoicing in various currencies. Senders track time in their private journal and Zipwire fills in the timesheet according to the rules and computes pay and charge totals. Rate changes can be scheduled ahead of time. Your senders can update their journal by sending a description of their work to Zipwire via WhatsApp, or from the terminal using the [Zipwire CLI (zw)](/tools-and-integrations/tools). Approvers receive WhatsApp notification of timesheets to act on, and can approve or reject via a quick message.
People Ops & HR Companies that directly hire freelancers or run a group of temps, can create their Zipwire workplace as per usual, but configure the client as either themselves, or as subsidiaries, departments, cost-centers or the work-sites they operate. Zipwire is free for small groups of senders, under 10 people at the time of writing. Typically, when setting up timesheet senders, the pay and charge rates are kept the same and the client invoicing features are ignored. However, each business is different and sometimes companies cross-charge and may even add a service charge to the cost-center for the services the department provide.
Founders & Small Businesses If you run a company and hire freelancers directly, then you can set your Zipwire workplace up and add the timesheet senders, then set yourself as the approver. Zipwire is free for small groups of senders, under 10 people at the time of writing. In this scenario, you configure your own company as the client and skip any settings regarding charging and client invoicing. When setting rates for your workers, simply set both the pay and charge rate to the same amount as you'll unlikely be charging yourself for their services. Zipwire's back office processing workflow includes stages for progressing timesheets through payment, charging the client, chasing late payments, etc. These steps probably aren't needed and can be clicked through. A future update will allow you to exclude some steps.\ \ Larger businesses sometimes cross-charge departments. In this situation, Zipwire can be used as if the department supplying the resource is a staffing agency and the client is the other department. See above.
Lone Freelancers & Gig Workers If you are freelancer and are working directly with a client, then you can use login to Zipwire and begin recording time in your journal. When you create a timesheet, you'll be given the opportunity to invite your approver and an optional processor, who might be someone in HR at your client. This is useful when you have been hired through word of mouth, rather than via a recruiter, and you need a simple timesheet approval system. Alternatively, you can ask your client's HR team to create a new Zipwire workplace and set you up as the sole timesheet sender, your line manager as the approver and themselves as the processor. For just you, this will not cost them anything and they will not have to enter credit card details.
Individual Users - Digital Identity Individuals can use Zipwire Attest to build and manage their digital identity on the blockchain. This self-service platform allows you to register independently without needing a business account, connect your Ethereum wallet to receive attestations directly, and complete government-approved identity verification. Zipwire Attest puts you in control of your digital identity, allowing you to prove specific facts about yourself without revealing unnecessary personal information. You can use it for age verification to prove you're over 18 without sharing your full passport, confirm your nationality for international services, meet KYC requirements for DeFi access, prove humanity for DAO participation, verify professional credentials without exposing personal details, or access gated communities and platforms that need to filter out bots. The platform takes a privacy-first approach where your personal documents never leave your control. Only cryptographic hashes are stored on the blockchain, and you choose exactly what information to reveal. When you need to prove something about yourself, you can generate selective disclosure proofs that reveal only the specific information needed.
Accounts Payable At the moment, this group cannot yet login to Zipwire to review their charges. But we're working on it. Staffing agencies and talent-hunting teams use Zipwire to manage the contract staff that they place with their clients. Zipwire can produce totals and generate PDF invoices to help an agency charge their client for the services rendered, but at present the client cannot login and view anything. Allowing the client to directly view their timesheets and charges is on our feature roadmap.
## Example industries The following give some ideas as to how Zipwire can help operate two very different types of business, with regard to their flexible, time-based staffing.
IT Recruitment Recruitment is the classic use-case for Zipwire. In this scenario, there is the recruitment agency, their client and the freelancer. The agency finds or has a pool of talented people it can place with their client and they charge a unit rate for these services, based on the time they devote to their client. Of course, the freelancer needs compensating and this is typically a slightly lower rate than the agency is charging for their services. In this case, the agency would create their Zipwire workplace and add the sender, and the approver, who is usually the sender's line manager, and one or more people within the agency's back office team to process the timesheets. Invitations are sent out to all the people involved with special links which connect the recipient to their new Zipwire assignment. When the all invoicing features are configured, Zipwire will produce an invoice from the freelancer's company that accompanies their timesheet, automatically. It will also expose actions for creating invoices to charge the client for the slightly increased amount. All data feeds into Zipwire's data warehouse for search and reporting.
Care Homes Nursing homes and assisted living accommodation rely on flexible staff from specialist agencies. Zipwire is perfect for this situation. The arrangement is similar to IT recruitment above, except that nursing staff may not operate as a small company, which is common for IT and software engineers. The agency creates their Zipwire [workplace](/zipwire-approve/unboxing-key-concepts/workplaces) and first [assignment](/zipwire-approve/unboxing-key-concepts/assignments) and [client](/zipwire-approve/unboxing-key-concepts/clients). The assignment is used to group [senders](/zipwire-approve/unboxing-key-concepts/senders) into a [team](/zipwire-approve/unboxing-key-concepts/teams-and-inboxes) and their line manager(s) and the client represents the care home or trust. Sender invoicing can be disabled if the workers are not expected to be invoicing the agency. However, the agency can use Zipwire to quickly produce accurate invoices to send to their care home client. Note that Zipwire does not have features to track the time when people started work and when they ended or took breaks. However, the [activities](/zipwire-approve/unboxing-key-concepts/activities) feature has been designed to represent clients, client sites and shifts.
Outdoor Activity Franchise In this example, Zzzzzzaaargh Activities Inc. operates long zip wires in cool places around the countryside of the United States. They run these franchises with a flexible set of often students who work a few days a week and may be away for long periods during school time. In this situation, the central franchise operator in head office supplies some useful services to their franchisees. They can setup a single Zipwire workplace and configure their clients as their various franchises around the country. They can create an assignment per franchise client and add the flexible workers on an hourly billing plan. They can set a different pay rate and charge rate in order to cover the cost of managing payroll on behalf of their franchisees. The approvers could be senior people within each franchise. Since Zipwire allows many assignment per client, they can have one assignment for the junior team members and another assignment for the senior people. This company would likely disable the sender invoicing, but enable the client invoicing so that they can invoice all the franchise companies for the people ops services provided.
The Freelance Coder Francis, a freelance software engineer is doing some work for a few months for a mutual friend Anika's new company. She wants to track the amount of time she works on it each day and bill for her time each week. She can use Zipwire as a lone sender of timesheets for free. All she needs to do is login and start recording her time in her private journal then, when she's ready to get paid, she can create her timesheet and at that point Zipwire will provide an opportunity to create a new workflow. This workflow must have an approver and can have an optional processor. She adds the email addresses of these people, who may be Anika to approve and someone who works for Anika doing the processing. Invitations will be sent out to these people to join Zipwire. In this situation, there is no Zipwire workplace and Francis has effectively assigned herself her own workflow. Note that Francis can begin to work with another customer and continue using Zipwire by simply logging time against a new activity. The new activity will need linking to a workflow and she can create a whole new one with a different approver and processor. She can also ask the new customer if they'd consider setting up their workplace on Zipwire and creating an assignment with her as a sender. She can then link her new activity to the workflow assigned by her new customer. As you can see, senders can use Zipwire with more than one customer or agency.
# Our Features There are too many features to list completely, and we're listening to customers and adding more all the time. ## Zipwire Approve
Single private journalSenders record what they work on in a single place, no matter how many people they work for
WhatsApp integrationChatGPT-powered bot understands natural language. Update your journal, manage activities, add private notes, and edit entries by chatting conversationally. Approvers approve with a reply
MCP ServerConnect Zipwire to any MCP (Model Context Protocol) client. Manage timesheets, activities, workflows, invoicing, and more programmatically via the Model Context Protocol standard
Any length timesheetsTimesheets can cover a week, month or any length of time, depending on rules
AttachmentsA timesheet can have a document attached, as well as the optional automatic invoice
Automatic invoicesInvoices can be generated from the sender's business to their agency or employer
Client invoicesFor agencies managing clients, Zipwire can generate invoices for the supplied workers
Work anywhereIt should go without saying but many timesheet apps simply don't work on small screens
Billing rulesMinimum billable unit of time, overtime and weekend rates, easily configured
Mixed currenciesPay workers in one currency and charge clients for them in another
AuditingLogin identity, IP address and location are recorded for timesheet actions
PDFsDownload PDF copies of timesheets for keepsies outside of Zipwire
SearchItems are stored in a bottomless data warehouse where they can be searched and reported on
Autofilled timesheetsWe use journal data to fill out the timesheet according to the billing rules, reducing errors
No passwordsLogin with Google et al, means no forgotten passwords, a constant headache in other apps
Encrypted on the cloudAll data is sent encrypted and stored encrypted on Google's cloud servers
Team inboxesItems land in team boxes so a deputy can pick up when their boss is away
Cashflow reportsSee how much money is passing through each stage of the workflow to identify bottlenecks
Tags and filtersApply tags to timesheets and use filters to organise your view
CSV exportsDownload data in the super useful CSV format
Custom columnsAdd custom data to senders to help produce richer reports
Public holidaysNational holidays are shown in the journal and on the timesheets
Processing stagesDefine custom workflow stages (draft, submitted, approved, paid) with role-based permissions and automated transitions
Skills ExtractionAutomatically extract and tag skills from journal entries and timesheets for workforce analytics
Verifiable TimesheetsGenerate cryptographic proofs and selective disclosure for compliant timesheet verification without exposing sensitive data
Accounting software syncAutomatically sync generated invoices to FreeAgent, Xero, QuickBooks and other accounting providers, eliminating manual data entry
And more...
## Zipwire Collect
Identity checksWe use a government-approved IDSP to run the kind of selfie-checks trusted by banks
UK Right to Rent TemplatePre-configured collection template for UK landlords to verify Right to Rent status with automated document workflows
AML checksOur IDSP partner Yoti can optionally also provide an AML background check report
Send via WhatsAppSnap and send for documents
Machine VisionDocument recognition and data extraction
EncryptionDocuments are encrypted by Zipwire and then encrypted again by our cloud provider
Sovereign dataYour customers choose where in the world to store their documents
Automated chasingWe send out reminders for the documents still outstanding
Reusable packsConfigure commonly used packs of documents for ease of use
Packs of packsPlace a pack inside another to build up larger, more advanced collections
Conditional collectionsOnly collection a doc or pack when, e.g. they submit a foreign passport
"Any of the following"Give your recipient a range of options such as different types of utility bill, "any 2 of these 5 options"
Bulk uploadWe use AI to figure out what the document is. So people can throw a whole folder of files at us and we'll sort out what's needed
Recollect from storageIf you should send a new collection to the same person, Zipwire will check you don't have a valid file already in storage
And more...
## Zipwire Attest
Self-service registrationIndividuals can register directly on our website, connect their Ethereum wallet, and start the attestation process
Ethereum wallet connectionConnect any EOA (Externally Owned Account) wallet to receive attestations directly
Government-approved ID verificationComplete secure ID checks using Yoti integration, the same technology trusted by banks and government services
Optional AML background checksGet additional Anti-Money Laundering background check reports for enhanced verification
"IsAHuman" attestationsReceive Proof of Personhood attestations that prove you're a verified human being
"Private Data" attestationsGet attestations for your documents using Merkle root hashes, keeping your data private
Cryptographic proof generationGenerate selective disclosure proofs to reveal specific information without sharing full documents
Universal compatibilityYour attestations work across all dApps and platforms that support EAS (Ethereum Attestation Service)
Privacy-first designYour personal documents never leave your control - only cryptographic hashes are stored on-chain
One-time verificationGet verified once and use your attestations everywhere in the Web3 ecosystem
Verifiable on-chainAll attestations are recorded on the Base blockchain and can be verified by anyone
Developer-friendlyOpen standards and clear documentation for developers to integrate attestation verification
Age verificationProve your age from your passport without revealing any other personal information
Nationality verificationConfirm your nationality without sharing your full name or address
Professional credentialsVerify qualifications and professional standing without exposing personal details
And more...
## Pricing Zipwire uses different pricing models: Approve and Collect have free tiers, while Attest is paid from the start. ### Zipwire Approve Timesheet and contractor management with WhatsApp integration and automated invoicing. {% content-ref url="" %} {% endcontent-ref %} ### Zipwire Collect Document collection and ID verification for onboarding and compliance. {% content-ref url="" %} {% endcontent-ref %} ### Zipwire Attest Self-service blockchain attestations for digital identity and proof of personhood. {% content-ref url="" %} {% endcontent-ref %} {% hint style="info" %} **Free Tiers Available** Zipwire Approve and Zipwire Collect start free with generous allowances. You only pay when you exceed the free limits. Zipwire Attest uses a one-time payment model per ID verification. {% endhint %} # Can I test drive it? The best way to get a thing is to go ahead and use it. Zipwire starts off free and we only charge if you go beyond the free allowance, so we don't collect 💳 card details. You can just start using it! ## Can I kick it? Yes. You can. You've been walking around reading our docs, kicking the tyres, and now it's time to get in and take it for a drive around the block. Both Zipwire Approve and Zipwire Collect are designed so you can open the door and get in and start driving without handing over your card details. # Setting up Zipwire Approve What happens once you click Get Started on the home page? Here's a brief guide to the onboarding process and how you can approach testing Zipwire Approve out. ## Acting out the roles Remember that Zipwire Approve is a workflow involving a few parties. Most people either want to first try the product out using some people in the office, or they pick a customer they're really friendly with. You can do it completely on your own but you'll need three devices to act out the three roles, sender, approver and processor, or perhaps two devices and your spouse's computer. Otherwise, contact and one of us will pretend to do some work and send timesheets or be an approver. Whatever you need. You can also create three different passkeys or wallets on the same device and keep logging out and back in again, but it can get confusing as to which of your alter-egos is playing which role. #### Before we begin * Keep in mind that **when we say agency, we also mean Human Resources department or People Ops, or just a team in Head Office** where people and pay are managed. * People login with a passkey or wallet, instead of having usernames and passwords in Zipwire. {% hint style="info" %} If you create a passkey and later try to sign in with a wallet, Zipwire will treat them as separate authentication methods. To link a new authentication method to an existing account, you'll need to use account recovery with your email or phone number. {% endhint %} #### Step 1 After clicking **Get Started** you'll be funnelled into our onboarding process where you'll be presented options on which role you'll be playing. #### **The Freebird** This option is for people working alone and only wanting to track time and send timesheets to their own customers. {% hint style="info" %} No workplace organization will be created. Most features will be unavailable. {% endhint %} {% hint style="warning" %} **Heads up: your first timesheet triggers invitations** As a Freebird, you won't be asked who approves or pays your work until you actually create your first timesheet. That's the moment Zipwire asks for the approver's and payer's email addresses - and as soon as you submit the sheet, Zipwire emails an invitation to each of them straight away. If you're just journaling time to see how it feels, that's fine - nothing gets sent until you create and submit a timesheet. But don't be surprised when real invites go out the moment you do. {% endhint %} #### **The** **Approver** This one is for line managers and people who approve people's time. In this role, you'll create a workplace which represents the company you work for. You'll be running everything, creating assignments and inviting the workers, setting their rates, and inviting the timesheet processors. {% hint style="info" %} This option is unusual as it's normally the timesheet processors who control everything. {% endhint %} #### The Processor This is designed for staffing agencies, HR departments and the like. You'll setup your workplace and become its administrator. You'll create and control the assignments, clients, workers, rates and approvers. {% hint style="info" %} This is the most common choice. {% endhint %} #### Your workplace You'll then enter just a few simple details about your workplace. You'll need to enter your company email. Note that a hotmail or other address won't be accepted. This is because you'll be setting up your colleagues and creating a new team, and these people will be expected to all work alongside you and share the same email domain. #### Confirm your email You know the drill. We'll email you an activation link and it'll probably be in your junk folder. This confirms that you have access to your work email. #### Add your colleagues Depending upon your role, you'll be adding colleagues to help with approving or processing timesheets. These will all need to have email addresses at the same email domain, because they work with you. These people will all be placed in a new Zipwire team. You do not have to add anyone else. #### Add the approvers or processors On the next screen, if you're a processor then you'll be creating the team that are doing the approvals. If you are the approver, then you'll instead be setting up the processing team. These people will all be placed in another new Zipwire team. You also do not have to add anyone else. They may have any email address. #### Add the senders These are your workers; the people sending timesheets. Most people testing will add only a single person. They may have any email address. #### Confirm everything and naming things The final screen explains what'll happen next and what you've configured so far. You can go back and change stuff. Note that we'll be creating a couple of new teams, a new assignment and a new client. Continue when you're ready and sit tight for a while. #### Your new assignment! After 10 seconds or so you'll end up looking at your new assignment. There'll be alerts because there are still a few things to configure. You'll need to setup your billing plan, and set the rates for your sender(s). Also, you can configure the invoicing details for your clients, if you want to have Zipwire create invoices for them, and the invoicing details for your workplace. Remember, Zipwire can create the invoices *from* the sender *to* your workplace and stick them on the timesheet. To do this, we need to know your workplace company details. #### # Setting up Zipwire Collect What happens once you click Get Started on our website? Here's a brief guide to the onboarding process and how you can approach testing Zipwire Collect out. ## Acting out the roles It's unlikely you'll dive straight in by testing an unknown app out with your precious customers without having used it yourself. So we'll assume this is a test exercise. You'll need two people, or at least one person with two completely separate logins. Preferably, you'll also use two different devices, perhaps your laptop and your phone. For document collections we have two roles, the **Collection Requestor** and the **Collection Recipient**. The requestor is the person who usually works at a company and wants to run KYC or otherwise collect some information from a new hire or client. The recipient is the person who receives the request to send documents. The requestor will setup their workplace and then add the recipient's details and create a new collection request. Nothing is sent to the recipient until the collection is opened in Step 3. #### Logging in Zipwire doesn't have its own usernames and passwords at all. You authenticate with a passkey or wallet. Each of these authentication methods are treated as separate identities, so you'll need a different passkey or wallet for the requestor and a different one for the recipient. You can create multiple passkeys on different devices or browsers, or use different wallets. #### Step 1 Go to the Zipwire Collect home page (not the Zipwire Approve page) which talks about document collection and find one of the **Get started** buttons, and then click it! You'll be asked to login. See the note above and go for it. After login you'll be returned to a page asking for your workplace details. Enter the details of your *real* workplace, rather than any fake/test details. It's just easier to get setup with your real details if you think there's a chance you'll continue to use Zipwire. {% hint style="info" %} You can erase your account and your workplace when you're done via **My account.** You can also abdicate the throne by adding a second administrator for the workplace and removing yourself. This can be done under **Our teams**. {% endhint %} Enter your workplace details and hit **Continue**. You'll be emailed a link to follow to confirm that you are indeed in control of the email address you supplied with the company domain. Click the link and you'll be returned to the workplace setup page where you can proceed. After a couple of moments while we get things setup, you'll be taken to the **Create** new collection page. **Step 2** Enter the email address of the recipient. As mentioned, this can be another email address you control, a family member or a colleague. Once submitted, you'll then be asked for their name and mobile number. Be sure to spell and capitalize your recipient's name as they'd prefer it. The mobile number will be used to send a WhatsApp message. **Step 3** Zipwire will create a new user account for your recipient, or if the email address is known to Zipwire already, it'll use that account. You'll then land on the Create page for your recipient. This is the editor for your collection and you'll be able to add documents and packs. For the collection, we recommend you **set the collection up to request a real document you have to hand**. Note that **nothing has yet been sent to the recipient**. Feel free to play around with the editor and the various options, how to save changes etc. When you're ready, hit **Open** to finalize the collection, send notifications to the recipient and wait for responses. **Step 4** If you are also the recipient and you've entered your own mobile number, you can jump onto your phone and reply with a photo of a document. This won't immediately work! Before we can store the document, we need to know *where* in the world you'd like your data held, so you'll get a reply asking for your choice.

Asking you where you want to store the documents you send us.

Reply with your choice using its two-letter code and we'll reply to say that it's done and you can now send that document again! Try sending it again... It'll take around 30 seconds to process and you'll get a response if it matches!

Zipwire's confirmation of a match via WhatsApp

Documents you upload via WhatsApp are processed, matched (assuming they've been requested) and stored, but they are not automatically sent to the requestor. To send documents, you'll need to head to our website and press a button (we are working to improve the bot to let you do all sorts of stuff). Anything you send will be stored, regardless of whether it is a match for an open collection. **Be careful!** If you follow the link using your phone, remember **to use a different login** to what you used for the requestor. **Step 5** If you've logged in via your phone, you should be taken to the area where we hold your documents and list all your collections. You should see the document you've uploaded and be able to hit **Send** to dispatch a copy to the requestor. {% hint style="info" %} When you send a document, it is decrypted and copied to the storage location of the requestor where it is encrypted again using a key for their account. Although the data is sent on secure channels and never leaves our cloud provider's private global network, your requestor may not hold their documents in same region as you. {% endhint %} As a requestor, you can forcibly close collection. Any outstanding documents will be marked as refused and you will no longer receive any nagging notifications to send documents for this request. **Step 6** Swap back to the requestors login or device. Refresh the page of open collections and you should see your document is available to **Accept** or **Reject**. Once all documents are accepted you can close the collection so it is formally done. # Logins & Invitations How your identity is important in Zipwire. ### Account Reservations Zipwire is used to approve work and get people paid, so it's important that you have confidence that the people using the app with you are who they say they are. There are currently three kinds of actors, [senders](/zipwire-approve/unboxing-key-concepts/senders), [approvers](/zipwire-approve/unboxing-key-concepts/approvers) and [processors](/zipwire-approve/unboxing-key-concepts/processors), who are invited to use Zipwire using their email address. It is **important** that you enter their email address carefully to ensure their invitation link is sent to the right person. If a person has a couple of email addresses, e.g. a personal and a work address, then it doesn't matter which one is used so long as the *right person* receives the link. {% hint style="info" %} Sending invitations to work emails is more secure. If the email address is wrong, the message is likely to fail to reach anyone at all. Plus, it's harder for an attacker to create a fake address with a corporate ending. {% endhint %} Behind the scenes, Zipwire *creates and reserves* a user account for the invited. When they follow the link they'll see their invitation and some basic details about who sent the it and to what it relates, including an email address of the sender so they can get in touch to ensure the invitation is legitimate. They'll then need to login for the first time, assuming they are new to Zipwire. They have two options: 1. **Create a passkey** - A secure, passwordless authentication method. They can create it directly in their browser, or if they're at work and want to keep it personal, they can scan a QR code with their phone to sign in without storing the passkey on the work device. 2. **Connect a wallet** - Link their Ethereum wallet for authentication. Once they authenticate, Zipwire links their passkey or wallet to the reserved user account which activates it so it's no longer reserved but claimed and in-use. If the wrong person follows the link, then this should be obviated by the unexpected name which will appear on their account. For example, you invite Sridhar as an approver but the name changes to Tony. {% hint style="info" %} Passkeys and wallets are unique to each authentication method. A user who creates a passkey and later tries to sign in with a wallet will be treated as attempting a different authentication and will need to use account recovery to link the new method to their existing account. {% endhint %} ### Auditing When a user acts upon an item Zipwire imprints any captured information about the actor and their computer into the item. For example, when an someone approves a timesheet via the website, we'll have information about their authentication method (passkey or wallet), the IP address of the device they're using and where in the world that is, and any other actions they took. And if they use WhatsApp, then we'll know their phone number. This information is permanently written into the timesheet. By writing this information into the item itself rather than keeping logs, you have control over deleting this data as part of any privacy regime or data policy in your jurisdiction. ### Two-factor Authentication We recommend people use two-factor authentication to secure their account. When enabled, Zipwire allows people to track time and make trivial changes but protects more sensitive operations, challenging the user to enter their two-factor key. {% content-ref url="/pages/c6OuLa26KyyqVWLxAG3c" %} [Two factor in Zipwire](/fundamentals/security/two-factor-in-zipwire) {% endcontent-ref %} ### Troubleshooting {% content-ref url="/pages/fLrzWo7u0KWkMoeS9sGb" %} [Tangled Identities](/troubleshooting/tangled-identities) {% endcontent-ref %} # Zipwire Collect: Rapid Onboarding, Effortless Compliance Zipwire Collect simplifies and automates the onboarding process for your contract staff, saving you time and ensuring regulatory compliance. Here's how Zipwire Collect benefits your business: ### **Streamlined Onboarding** * **Pre-built Packs:** Create customized document packs containing the exact documents required for different worker types (e.g., passport for overseas workers, proof of address for local contractors). No more scrambling to figure out what each worker needs to submit. * **Automatic Chasing:** Eliminate the time-consuming task of chasing down missing paperwork. Zipwire Collect automatically prompts new workers to submit the required documents, keeping the onboarding process moving smoothly. * **Reduced Manual Work:** Free up your HR team's valuable time by automating document collection and verification. They can focus on more strategic tasks, like reviewing applications and interviewing candidates.

Increase response rate by reaching your customers where they're at and letting them upload photos.

### Effortless Document Uploads via WhatsApp: Reduce Friction, Boost Response Rates Imagine this: a new contractor needs to submit their ID for onboarding, but they're swamped and can't readily scan it. Traditionally, this would involve back-and-forth emails or chasing down a physical copy. Zipwire Collect offers a better way. **Seamless Uploads with WhatsApp:** * **Convenience at their Fingertips:** Zipwire Collect leverages the familiarity and ease of WhatsApp. Workers can simply snap a picture of their documents directly within the app and upload them securely. * **Increased Response Rates:** Reaching your workers on their preferred platform makes them more likely to respond and submit documents promptly. This reduces delays and keeps the onboarding process moving smoothly. * **Reduced Friction:** Eliminate the hassle of scanning documents or emailing back-and-forth. WhatsApp uploads are quick, easy, and can be done on the go, from any smartphone. **Zipwire Collect makes document collection effortless for both you and your workers. This translates into faster onboarding times, improved communication, and a more positive overall experience.** ### **Enhanced Compliance and KYC** * **AI-powered Verification:** Reduce the risk of errors and fraud with Zipwire's AI system. It can analyze documents to verify key information like expiry dates, ensuring compliance with right-to-work checks and Know Your Customer (KYC) regulations. * **Conditional Logic:** Set up smart rules to only collect specific documents based on information in others. For example, only request a visa if a passport isn't from a certain country. This ensures you gather the necessary documentation for each worker's specific situation. * **Secure Storage:** All worker data is encrypted and stored securely in the cloud. This gives you peace of mind that sensitive information is protected against unauthorized access. ### **Benefits Beyond Onboarding** * **Improved Worker Experience:** A faster, more efficient onboarding process creates a positive first impression for your contract staff. * **Reduced Risk:** Proper document verification minimizes the risk of employing unauthorized workers and helps you avoid potential fines or legal issues. * **Scalability:** Zipwire Collect easily scales with your business needs. Whether you're onboarding a few contractors or a large team, Zipwire Collect can handle the volume efficiently. **Zipwire Collect integrates seamlessly with Zipwire Approve.** This means timesheet tracking can begin as soon as the onboarding process is complete, creating a smooth, efficient experience for both you and your workers.

Documents are encrypted twice and stored in a location your customers choose.

### Prioritizing Security: Protecting Your Worker's PII At Zipwire, we understand the importance of safeguarding your workers' Personally Identifiable Information (PII). We take a multi-layered approach to security to ensure your data is always protected: * **Double Encryption:** All uploaded documents are double-encrypted before being stored on our servers. This adds an extra layer of security, making it extremely difficult for unauthorized individuals to access sensitive information. * **User-Selectable Server Location:** Choose where your data is stored! We offer a variety of server locations around the world, allowing you to comply with regional data residency regulations or simply keep your data geographically close. * **Strict Access Controls:** Only authorized personnel have access to worker data, and access is granted on a least-privilege basis. **Transparency and Control:** We believe in transparency and giving you control over your data. You can access and manage your worker data at any time through the Zipwire Collect platform. Additionally, you have the option to delete data permanently once it's no longer needed. **Peace of Mind with Zipwire Collect:** By prioritizing security and offering user-selectable server locations, Zipwire Collect gives you peace of mind knowing your workers' PII is always protected. This allows you to focus on building a strong workforce and fostering positive relationships with your contract staff. *** **Zipwire Collect simplifies contractor onboarding with pre-built document packs, automatic reminders, and secure WhatsApp uploads. AI verifies documents for compliance, while double encryption and user-selectable server locations ensure maximum security. Experience faster onboarding, reduced costs, and happier workers - sign up today, it's free!** # Data Ownership in Zipwire Our product is radically different from traditional, clunky agency systems, especially when it comes to data ownership. ## Data Ownership in Zipwire Zipwire implements a unique approach to data ownership that prioritizes user control and privacy. This section outlines the key features of Zipwire's data management system. #### Personal Login Credentials Zipwire uses personal login credentials. This ensures continuous access to user data, independent of employment status or agency relationships. #### Private Time Journal Zipwire Approve includes a private time journal feature. This single journal can track time across multiple agencies simultaneously. When submitting timesheets, users map activities to each agency's specific workflow. #### Secure Document Storage Zipwire Collect stores documents in an encrypted vault associated with the user's personal login. Sensitive documents are encrypted and stored in a country of the user's choosing. This feature allows users to control access and share copies with agencies as needed. #### Data Portability Zipwire ensures data portability across job transitions. User data remains accessible regardless of changes in employment or agency relationships. #### Multi-Agency Support For users working with multiple agencies that use Zipwire, the system facilitates easy document sharing without requiring duplicate uploads. Users retain control over data sharing preferences. #### AI-Powered Updates Zipwire includes a WhatsApp bot that allows voice message updates to the time journal. The AI processes this information and updates the private journal automatically. You can also update your journal from the terminal using the [Zipwire CLI (zw)](/tools-and-integrations/tools). #### Privacy and Security All user data in Zipwire is encrypted and securely stored. Direct access to the full data set is restricted to the user, enhancing privacy and data security. #### Data Syncing and GDPR Compliance Zipwire implements a data copying and syncing mechanism. This ensures that users cannot be locked out of access to their data. Additionally, this feature aids in GDPR compliance by allowing users to maintain control over their personal data. Our approach to data ownership is designed to provide users with control over their professional data. This system ensures consistent access to work history, documents, and time records, regardless of changes in professional relationships. # Data Portability and Proofs How cryptographic proofs and data portability create structural optionality, enabling you to move verified records across system boundaries without permission. ## The Problem with Data Silos Today's digital world locks your data behind system boundaries: * **Identity verification** locked in each platform. Every new service requires re-verification, even though you've already proven who you are. * **Professional credentials** are only verifiable by calling the issuing institution. No certificate, just gatekeepers. * **Work history** vanishes when you change agencies. Your timesheet approvals, signed-off work, and performance records don't follow you. The common thread: **you don't own portable proof of these facts**. You own access to systems that claim these facts are true. ## What Zipwire Attest Changes Today Zipwire Attest and ProofPack introduce something fundamentally different: **portable, verifiable identity proofs** that move across system boundaries without losing integrity or authorship. ### The Core Difference A **cryptographic proof** is self-contained evidence that: * Proves a fact (like your age or identity) without requiring the original system's permission * Maintains its integrity through cryptographic signatures * Can be verified by anyone, anywhere, at any time * Doesn't leak more information than necessary (selective disclosure) This is different from a PDF certificate or a screenshot. Those can be forged. A cryptographic proof **cannot be altered without detection**. ### What's Available Now With **Zipwire Attest**, you can get blockchain attestations for: * **Identity verification** - Verified once via government-approved Yoti checks * **Age thresholds** - IsThirteen, IsFourteen, IsSixteen, IsEighteen, IsTwentyOne * **Proof of personhood** - IsAHuman attestation * **AML clearance** - HasClearAML status These attestations are portable. Once verified, you can use them across any Web3 platform supporting EAS (Ethereum Attestation Service). ## Structural Optionality Data portability combined with cryptographic signatures creates what we call **structural optionality**: you're not forced to trust the incumbent custodian of your data. ### What This Means in Practice #### You Can Re-Use Verified Data * Verified once by Zipwire through government-approved Yoti checks * Use that attestation across any Web3 platform supporting EAS (Ethereum Attestation Service) * No need to verify your identity repeatedly for every new service * Move between platforms without losing your verified identity #### You Control Disclosure * Share only your date of birth with an age-restricted service (ProofPack reveals only that field) * Share nationality verification without revealing your full passport * Share AML clearance status without exposing the underlying checks * Different proofs for different contexts - you choose what to reveal #### Future: Work History Portability Switch agencies and your attested work history, signed timesheets, and client approvals remain yours (coming with Zipwire Approve integration). ## How ProofPack Enables Portability ProofPack is Zipwire's portable proof format (see [Understanding ProofPack](/fundamentals/security/understanding-proofpack) for the full structure). It's a standardized, cryptographically-signed document that contains: ### Three Verification Layers 1. **JWS Envelope** - Cryptographic signatures prove the document hasn't been tampered with (see [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws)) 2. **Blockchain Attestation** - On-chain record on Base blockchain (via EAS) proves Zipwire verified the underlying data (see [Crypto & Blockchain Basics](/fundamentals/security/crypto-and-blockchain-basics)) 3. **Merkle Tree Structure** - Enables selective disclosure (reveal only specific fields) ### Key Properties * **Portable**: ProofPacks are JSON files. Download them, email them, store them locally. * **Verifiable Anywhere**: Anyone can verify a ProofPack using open-source tools and blockchain queries, or just drop it into [zipwire.io/verify-proof](https://zipwire.io/verify-proof) for a quick check. * **Privacy-Preserving**: Only the fields you choose to reveal are included in the proof. * **Tamper-Evident**: Any modification breaks the cryptographic signatures. * **User-Editable**: Download the JSON and hand-edit to create custom selective disclosures. The JWS envelope becomes invalid, but the Merkle tree remains covered by the blockchain attestation. * **AI-Verifiable**: ChatGPT and Claude can read the JSON, validate the Merkle tree structure, and guide you to verify the attestation on [Base EAS Scan](https://base.easscan.org/). For technical details, see [Proof Verification](/zipwire-attest/proof-verification). ## Upcoming: Attested Work History and Approvals Zipwire is extending the power of portable proofs beyond identity verification to **work history** and **approvals**. ### Attested Timesheets Imagine a world where: * Your signed-off timesheets are **cryptographically attested** * The approver's signature is **verifiable on-chain** * You can **prove hours worked** without accessing your old agency's system * Future employers can **verify your work history** through portable proofs This is coming with Zipwire Approve integration. ### Proof of Work Done Timesheet approvals today are trapped in agency systems. Tomorrow: * **Portable approval records** - Approver signatures become blockchain attestations * **Verifiable work history** - Prove to future clients that you delivered (and they paid) * **Professional reputation** - Build a portable record of successfully completed assignments ### How It Works 1. **Worker submits timesheet** via Zipwire Approve 2. **Approver signs off** via WhatsApp or web interface 3. **Approval becomes a blockchain attestation** (on Base via EAS) 4. **Worker receives ProofPack** - portable proof of the approved work 5. **Worker shares ProofPack** with future clients, agencies, or lenders This transforms approvals from **internal system records** to **portable professional credentials**. ## Real-World Benefits ### For Individuals (Available Now) * **Age-restricted services** - Prove you're old enough without revealing your exact age or full ID * **Web3 platforms** - Use your identity attestation across any EAS-compatible service * **Proof of personhood** - Demonstrate you're a unique human without revealing personal details * **AML compliance** - Share clear AML status with platforms that require it * **Privacy control** - Choose exactly what information to reveal in each context ### For Contract Workers (Coming Soon) * **Prove income** to lenders without accessing old agency systems * **Demonstrate track record** to new clients with verifiable approvals * **Maintain work history** across multiple agencies and job transitions * **Control your narrative** with selective disclosure (share only relevant projects) ## Example: Safety-Critical Industries Industries with regulatory requirements for **recent experience** and **certified work history** face particularly acute portability challenges. ### Aviation Maintenance Aircraft maintenance engineers must prove: * Recent experience on specific aircraft types * Currency on critical tasks (engines, avionics, structural work) * Valid certifications and type ratings * Sign-offs on safety-critical maintenance **Current reality**: Paper logbooks, manual verification, lost history when changing employers. **With attested work records**: Each maintenance sign-off becomes a verifiable ProofPack. Prove currency on Boeing 787 avionics work without contacting three previous MROs. Regulators verify credentials without phone calls. Insurance decisions based on cryptographic proof rather than paper trails. Similar patterns exist in nuclear power, medical device manufacturing, pharmaceutical production, and other fields where "who did what, when, and were they qualified?" matters for safety and compliance. ## Trust Chains and Verification ProofPack proofs aren't isolated claims - they're part of verifiable trust chains linking back to authoritative sources. For details on how trust chains work and how to verify them, see: * [Proof Verification](/zipwire-attest/proof-verification) - Technical verification details * [Trust Chain Verification](/zipwire-attest/proof-verification#trust-chain-verification) - How attestations link to authorities like NIST ## Privacy and Security ### What's Not Portable * **Your private keys** - Never leave your wallet * **Unencrypted documents** - Only cryptographic hashes are on-chain * **More data than you authorize** - Selective disclosure is enforced cryptographically ### What Is Portable * **Cryptographic proofs** - Merkle tree structures proving specific facts * **Attestation references** - Blockchain attestation UIDs for verification * **Revealed fields only** - You control exactly what data is in each ProofPack ### Data Deletion Even with portable proofs, you maintain control: * **Delete documents** from Zipwire's encrypted storage at any time * **Attestations remain** on blockchain for verification (they're just hashes, not personal data) * **ProofPacks remain valid** even after deleting source documents For more details, see [Privacy and Security](/zipwire-attest/privacy-and-security). ## Technical Standards and Interoperability Zipwire uses open standards for maximum portability: ### Blockchain Standards * **EAS (Ethereum Attestation Service)** - Industry standard for on-chain attestations * **Base Network** - Low-cost Layer 2 blockchain from Coinbase * **EIP-1271 and ERC-6492** - Smart wallet signature standards ### Cryptographic Standards * **JWS (JSON Web Signature)** - IETF standard for signed JSON documents * **Merkle Trees** - Well-understood cryptographic data structure * **ES256K and RS256** - Industry-standard signature algorithms ### Developer Integration * **NPM packages** - `@zipwire/proofpack` and `@zipwire/proofpack-ethereum` * **Open specification** - Full ProofPack format documented on GitHub * **AI/LLM-friendly** - Structured JSON format for automated verification ## The Complications (And How We Address Them) ### Attack Surface **Problem**: Portable data creates new risks (data exfiltration, context collapse, injection attacks). **Our Approach**: * Selective disclosure limits what can be exfiltrated * JWS signatures prevent injection of forged proofs * Revocable attestations allow invalidation of compromised proofs ### Format Agreement **Problem**: Portable data is only useful if the receiving system understands it. **Our Approach**: * Use industry standards (EAS, JWS) * Open specification for ProofPack format * Compatibility with entire Web3 ecosystem via EAS ### Consent and Re-Use **Problem**: Does portability imply consent to re-use? **Our Approach**: * Each ProofPack is created for a specific purpose (nonce-based) * Users explicitly generate each proof * Revocable attestations allow withdrawal of consent ### Fraud Vectors **Problem**: Forged portable records could be injected into other systems. **Our Approach**: * Blockchain attestations provide unforgeable source-of-truth * Trust chains allow verification back to known authorities * Revocation mechanisms allow invalidation of fraudulent attestations ## The Future: Horizontal Approval Traces With attested approvals from Zipwire Approve, we enable **horizontal approval traces** across organizations: * **Worker submits timesheet** to Agency A * **Client approver at Company B** signs off via WhatsApp * **Approval becomes blockchain attestation** linking worker, agency, client, and timesheet hash * **Worker uses ProofPack** to prove delivery to Agency C for next contract * **Agency C verifies** the approval chain without contacting Agency A or Company B This is **portable reputation** built on cryptographic proofs, not locked in proprietary systems. ## Comparison: Traditional Identity Verification vs. Zipwire Attest | Feature | Traditional Verification | Zipwire Attest + ProofPack | | -------------------- | ------------------------------------- | ------------------------------------------------------- | | **Data Location** | Locked in each platform's system | Portable, user-controlled | | **Verification** | Requires system access or phone calls | Cryptographic, self-verifying | | **Re-verification** | Required for every new platform | Verify once, use everywhere | | **Permission** | Need provider's cooperation | No permission needed | | **Portability** | Not portable between platforms | Cryptographically-signed JSON | | **Privacy** | All-or-nothing (full ID document) | Selective disclosure (age only, nationality only, etc.) | | **Longevity** | Lost if platform shuts down | Verifiable as long as blockchain exists | | **Interoperability** | Platform-specific | Open standards (EAS, JWS) | | **Trust Model** | "Trust the platform's database" | "Verify the cryptographic proof" | ## GDPR and Data Portability Rights Zipwire's approach aligns with GDPR's "right to data portability" (Article 20): * **Machine-readable format** - ProofPacks are structured JSON * **User-controlled** - You decide what to export and when * **Portable to other services** - ProofPacks work across any EAS-compatible platform * **No vendor lock-in** - Your attestations exist on public blockchain Additionally, GDPR's "right to erasure" (Article 17) is supported: * Delete documents from Zipwire's storage at any time * Only cryptographic hashes remain on-chain (not personal data under GDPR) For data retention policies, see [Attestations, Privacy, Timing, and Data Deletion](/fundamentals/security/attestations-privacy-timing-data-deletion). ## Getting Started ### For Individuals 1. **Register at Zipwire Attest** - Self-service, no business account needed 2. **Connect your wallet** - EOA or Smart Wallet (e.g., Coinbase Smart Wallet) 3. **Verify your identity** - Government-approved Yoti verification 4. **Receive attestations** - Blockchain attestations on Base via EAS 5. **Generate ProofPacks** - Create portable proofs for specific use cases See [Getting Started with Zipwire Attest](/zipwire-attest/zipwire-attest). ### For Developers 1. **Install ProofPack SDK** - `npm install @zipwire/proofpack @zipwire/proofpack-ethereum` 2. **Integrate verification** - Use SDK to verify ProofPacks in your application 3. **Query EAS attestations** - Verify on-chain attestations on Base 4. **Build workflows** - Create applications that accept portable proofs See [Proof Verification](/zipwire-attest/proof-verification) for technical integration details. ### For Contract Workers (Coming Soon) 1. **Use Zipwire Approve** - Track time, submit timesheets 2. **Get approvals via WhatsApp** - Approvers sign off remotely 3. **Receive attested approvals** - Blockchain attestations of signed timesheets 4. **Build portable work history** - ProofPacks of completed assignments Watch for announcements about attested timesheet approvals. ## Related Resources * [Data Ownership in Zipwire](/overview/data-ownership-in-zipwire) - How Zipwire protects your data across all products * [Privacy and Security](/zipwire-attest/privacy-and-security) - Security measures and privacy guarantees * [Proof Verification](/zipwire-attest/proof-verification) - Technical details on verifying ProofPacks * [Attestation Schemas](/zipwire-attest/attestation-schemas) - Available attestation types and their uses * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) - How selective disclosure works ## Key Takeaways 1. **Data portability + cryptographic proofs = structural optionality** - You're not locked into custodian systems 2. **ProofPack is the portable proof format** - Cryptographically-signed, blockchain-attested, selectively-disclosable 3. **Trust chains are verifiable** - Trace attestations back to authoritative sources 4. **Upcoming: attested work history** - Approved timesheets become portable professional credentials 5. **Open standards ensure interoperability** - Works across Web3 ecosystem via EAS **The power shift**: From "the system says it's true" to "here's cryptographic proof it's true." # Pricing Zipwire uses different pricing models: Approve and Collect have free tiers, while Attest is paid from the start. ## Our Pricing Philosophy Zipwire uses different pricing models tailored to each product: * **Zipwire Approve & Collect** - Free tiers with generous allowances, pay for additional usage (no feature gates) * **Zipwire Attest** - One-time payment per ID verification * **No hidden fees** - Transparent pricing with no setup or cancellation charges {% hint style="info" %} **No Feature Gates** Zipwire Approve and Zipwire Collect include all features in the free tier. You only pay when you exceed the usage limits - there are no paid-only features. {% endhint %} ## Zipwire Approve **Timesheet and contractor management with WhatsApp integration and automated invoicing.** ### What's Included in Free Tier * Up to **10 active senders** (workers) * Unlimited approvers and processors * WhatsApp integration * Basic reporting and exports * PDF timesheet downloads * Team inboxes and workflows * Everything - we don't charge for features ### Paid Usage * Additional senders beyond the 10 free allowance * All features remain available - you only pay for additional usage {% content-ref url="" %} {% endcontent-ref %} ## Zipwire Collect **Document collection and ID verification for onboarding and compliance.** ### What's Included in Free Tier * Up to **20 documents** that can be collected * All document types and machine vision * ID verification and AML checks * Automated chasing and reminders * Advanced compliance features * Bulk upload capabilities * Everything - we don't charge for features ### Paid Usage * Additional documents beyond the 20 free allowance * All features remain available - you only pay for additional usage {% content-ref url="" %} {% endcontent-ref %} ## Zipwire Attest **Self-service blockchain attestations for digital identity and proof of personhood.** ### Pricing Model Zipwire Attest uses a **one-time payment** model per ID verification: * **ID Check Only** - One-time payment for basic identity verification * **ID + AML Check** - One-time payment including Anti-Money Laundering background check * **No free tier** - Paid from the first use ### What's Included * Self-service registration * Ethereum wallet connection * Government-approved ID verification via Yoti * IsAHuman attestation * Private Data attestation * Cryptographic proof generation * Optional AML background check {% content-ref url="" %} {% endcontent-ref %} ## Billing and Payment ### How Billing Works #### Zipwire Approve & Collect 1. **Start immediately** - No credit card required to begin 2. **Track usage** - Monitor your consumption in real-time 3. **Automatic billing** - Only charged when you exceed free limits 4. **Monthly invoices** - Clear breakdown of charges #### Zipwire Attest 1. **One-time payment** - Pay upfront for each ID verification 2. **Immediate access** - Start verification process after payment 3. **Consumption** - Payment is consumed when Yoti report is available 4. **Retry mechanism** - If verification fails, purchase is paused for 24 hours before allowing retry ### Payment Methods * Credit cards (Visa, Mastercard, American Express) * Bank transfers (for enterprise customers) * Digital wallets (coming soon) ### Enterprise Options For larger organizations with specific needs, we offer: * Custom pricing plans * Dedicated support * SLA guarantees * On-premise deployment options * Custom integrations {% hint style="warning" %} **Enterprise Inquiries** For enterprise pricing and custom plans, please contact our sales team directly. {% endhint %} ## Frequently Asked Questions ### Can I use multiple products? Yes! All products can be used together or independently. Approve and Collect have their own free allowances, while Attest is paid per verification. ### What happens if I exceed the free limit on Approve or Collect? You'll be automatically charged for the additional usage. You can monitor your usage in real-time and set up alerts. ### How does Zipwire Attest billing work? Attest uses a one-time payment model. You pay upfront for each ID verification, and the payment is consumed when the verification report is available. ### What if my ID verification fails in Attest? If the ID check fails, your purchase is paused for 24 hours before allowing a retry. This prevents immediate re-payment for failed attempts. ### Can I cancel anytime? Yes, you can cancel your paid plan for Approve and Collect at any time. You'll continue to have access to the free tier. ### Do you offer refunds? No refunds are offered for consumption-based products (Approve and Collect) since you're billed for actual usage. Attest refunds are only available if the product is defective - refunds are not available for user-initiated cancellations or failures to consume the product after payment. ### Is there a setup fee? No, there are no setup fees or hidden charges. ## Getting Started Ready to try Zipwire? You can start using Approve and Collect immediately without entering payment details. {% content-ref url="/pages/BBuwfJ35LSFN8l7EbDcO" %} [Can I test drive it?](/overview/can-i-test-drive-it) {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="" %} {% endcontent-ref %} # How Zipwire Approve is radically different and speeds up pay day Designed to solve the endless pain of pay day for workers, their boss and the awesome people who toil away behind the scenes processing everything. [**Get started with Zipwire Approve →**](https://zipwire.io/approve) Getting everyone paid each month can feel like endless busywork. For freelancers, filling out timesheet and preparing an invoice is a pain. They often forget, or leave off the invoice, or it's wrong for all manner of reasons. Many timesheet portals are very poorly made and don't work on mobile or modern browsers, or they have to create and send an Office document, and they'll simply put it off until next time. It's also a pain for their boss who has to go in and approve dozens of timesheets, or be contacted on a weekend because of a late submission. They suffer similar problems to the freelancer if the system is clunky or file based. Then there’s the busy folks at the receiving end who are flicking between Excel and Outlook, chasing people up, double checking invoices and rates, looking for bank holidays on top of preparing invoices for their clients and pulling down a line of credit. It’s a lot of work, and once done, it starts all over again in a couple of weeks. ### Designed to target key pain areas Zipwire sits at the heart of your staffing agency and has been thoughtfully designed to radically reduce this burden. Explaining how Zipwire's features help, let's dive in to the story of payday. #### Worker pain It's Friday evening and Mrs Worker is at her desk. Now, being Friday evening, either something will go massively wrong and keep her late, or someone is leaving and people are dragging them to a party, or the highway is closed and they've got to beat the traffic. The last thing Mrs Worker wants to do is a timesheet. So she either skips it and waits for next time and lives off money in the bank, or she smashes the thing out in a rush, forgetting Monday was a public holiday, and that she had a rate change and so now the invoice is wrong. Oh, and she did a 12 hour day a fortnight ago and slept in to make up for it the next time, but her current timesheet system, which uses bizarre decimal work days, goes wonky when she puts 1.5 in. She's also had a Post-it note on her screen for weeks to remind her that she'd left early for her son's sports day at the start of the month. #### Worker pain killers Well, the first thing is to allow her to track time away from the official timesheet, so she can track what really happened, in detail. Actually, the first thing is to remove any username and passwords so she doesn't forget and can just sign in with a passkey or wallet. The next thing is to make this fast and easy to do by designing a rapid UI which let's her copy what she did from the week before, and copy it down the current week. Then, make it even easier by letting her speak a journal update from her phone, via WhatsApp, which understands her short description of her week using AI. And as she's a techie, she can also update her journal from the place where she spends most of her time: her beloved command line terminal, using the [Zipwire CLI (zw)](/tools-and-integrations/tools). Nice. Finally, when she wants to submit her timesheet, Zipwire automatically fills it out according to the rules of her engagement, so it cannot be wrong. We'll warn her if she's put time down on a bank holiday, too. Oh and let's go ahead and automatically create her invoice while we're at it. #### Approver pain Many line managers around the world will get an email with a Word document inside. And they have to open it, which is fine when they're at the "big computer" but maybe they're on the ward, or up some scaffolding, or on the sofa. They reply "approved" over and over before remembering Monday was a public holiday and they just approved some mistakes. Ugh. But the Mr Bossman in this story is lucky because this agency is using the amazing timesheet portal they had made 15 years ago. It doesn't work on his mobile, and the device in his study doesn't have his password saved. Annoying. Oh but what if Mr Bossman is not on the sofa, but on a sun lounger in Bali and their phone is OFF? How will everyone get paid now?! #### Approver pain killers As with the timesheet senders, let's allow Mr Bossman to sign in with a passkey or wallet, and then send him the timesheet over WhatsApp. Ooh. He can just reply "approve" or "reject" before his other half yells at him for working on holiday. The second important design choice is to send the timesheets into a team inbox which not only he can see, but also his deputy can see. So his deputy approves everything and saves everyone's mortgage from defaulting and a cashflow headache at the agency! Three cheers for the deputy (and for Zipwire's designers). #### Processor pain If you're using emailed Word documents and various attached invoices, then I don't even know where to begin? How do you even?? **Do you just throw people at the problem?** But even if you have a clunky timesheet portal with its decimal work days, you've still got so much to reconcile and prepare for pay day. And you've most likely got to borrow the cash to pay everyone and produce accurate invoices for all your clients. Then handle contractor queries, forgotten passwords, adjust for mistakes or issue credit notes, and enter it all in your accounts package. Let me guess. You make the commute to the office because you have two big screens and you need all that space for all the Excel workbooks, your accounts website, millions of Outlook attachments, a folder full of Word docs, or perhaps a few browser tabs open on your timesheet portal - which keeps logging you out. You've got to search for stuff, check invoices, figure out who hasn't submitted, chase line managers, check rates and remember rate changes. For all your timesheet wranglers out there, we feel your pain. #### Processor pain killers Many of these pains are mitigated by the features we've designed for timesheet senders and their approvers Timesheets land in team inboxes, and you can divide and conquer by splitting the processing teams up. The timesheets are much less likely to be wrong because Zipwire has filled it out in accordance with the rules, and where you have freelancers that invoice you, they're attached and accurate and even include the rate change that happened halfway through the month! Zipwire gives you a series of stages to move the timesheets through so you know where they're all at, feel a sense of control, and there are tags and filters to help you organise them all. What's more, in the click of a button Zipwire can create you an invoice for one or all the timesheets for your client, including payment details, tax and cross currencies. #### More to come To be honest, there's so much busywork in managing temp workers that we're still thinking up ways that Zipwire can help, such as putting a little highlight on the timesheets worth looking at - those with unusual times. In fact we have an idea for automating almost all of it, including the invoice factoring and payouts. It was a long read but we hope you get an idea of how Zipwire has been designed to radically reduce the costly busywork. # A Tour of a Zipwire Timesheet A visual walkthrough of every feature on a Zipwire sheet (what most people call a timesheet) — flags, skills, verified proofs, and the actions available to approvers and processors. A Zipwire sheet — what you might know as a timesheet, work sheet, or report sheet — is more than a list of hours. It's a verified record of work — with automatic anomaly detection, AI-extracted skills, and a cryptographic proof you can download and keep forever. {% hint style="info" %} **Why "sheet" and not "timesheet"?** We call it a **Sheet** in the product — you'll also hear it called a **work sheet** or a **report sheet**. A sheet is usually built from tracked time, but it doesn't have to be: the units billed can come from somewhere other than a clock. "Timesheet" implies time is always the underlying unit; "Sheet" deliberately doesn't assume that. {% endhint %} This page walks through every section of a real sheet so you know exactly what you're looking at. {% hint style="info" %} **Technical contractor?** Everything you see here can also be done from the command line. The Zipwire CLI lets you track time, create sheets, and send them without leaving your terminal — the same mental model as Git. See [Why the Zipwire CLI is a Big Deal](/tools-and-integrations/cli-introduction). {% endhint %}
A Zipwire sheet for Luke G Sender covering 5 days in May 2026, showing the warning badge, flags banner, daily time bars, skills table, and approval actions

A complete Zipwire sheet with flags, skills extraction, and approval controls.

*** ## The Card Header At the top you see the sender's name, the number of days covered, and the period. Two badges can appear on the right: * **Recent** — the sheet arrived recently and hasn't been acted on yet. It fades once the sheet has been reviewed. * **Warning badge** — a visual signal that something on this sheet is worth attention before you approve. It appears whenever one or more flags are present (see below). You'll see this on the inbox list too, so interesting sheets stand out before you even open them. Below the sender name, a timestamp shows when the sheet was received and its current status — here, *"Received 17 minutes ago. The item needs approving."* *** ## Flags
Sheet view showing a 'Something to flag — Overworked' banner, with Monday showing 9 billed hours against a standard 8-hour day

The flag banner calls out anything worth an approver's attention.

The orange **"Something to flag"** banner lists every condition Zipwire detected automatically. In this example: **Underworked**, **Overworked**, and **No rate plan**. Flags are not a verdict — they don't block approval. They're information. The approver decides what to do with them. Flags are recalculated if a processor adjusts which units are billed, so they always reflect the current billed state, not just the snapshot from submission. See [Timesheet Flags](/zipwire-approve/unboxing-key-concepts/timesheet-flags) for the full list of conditions Zipwire checks for. *** ## Daily Time Bars The body of the sheet shows one row per day. Each row has: * The **date and a short activity description** — what the sender logged for that day * A **coloured bar** representing billed hours, with the hour count displayed at the end Days with no billable time — public holidays, weekends — appear as empty rows with a label. In this example, Monday 25 May is labelled *"Spring bank holiday"* with no bar. The bars are colour-coded by activity, so at a glance you can see whether work was spread across multiple projects or concentrated on one. {% hint style="info" %} **Hourly vs. day rate billing.** The example above shows an hourly-billed contractor — each bar represents hours logged. For day rate contractors, Zipwire uses **half-day units** instead. The sender bills a minimum of half a day and a maximum you configure on their billing plan. The bars still appear, but they represent units (full days and half days) rather than raw hours. See [Billing Plans](/zipwire-approve/unboxing-key-concepts/billing-plans) to configure which model applies. {% endhint %} *** ## Activity Breakdown Below the daily rows, a summary chart shows how time was distributed across activities as percentages. This example shows: * HMRC > MTD > Coding — 66% * HMRC > MTD > Consulting — 19% * HMRC > MTD > Testing — 16% This gives agencies and approvers an instant read on what kind of work was actually done during the period, without having to add up each day manually. *** ## Total Charge The billed amount is shown here. When a **No rate plan** flag is present — as in this example — the total will be £0.00 or $0.00. This means the sender submitted before a rate plan was configured on their workflow. The sheet can still be approved; billing can be resolved separately. See [Rate Plans](/zipwire-approve/unboxing-key-concepts/rate-plans) for how rates are applied. *** ## Skills The **"These skills were used"** section lists every professional skill the AI identified from the sender's activity descriptions. Each entry shows: | Skill | Category | Confidence | | -------------------- | --------- | ---------- | | Coding | Technical | 90% | | Fraud prevention | Technical | 70% | | VAT obligations | Technical | 80% | | Consulting | Soft | 90% | | Client communication | Soft | 90% | Skills are extracted automatically — the sender doesn't fill this in. The AI reads the activity names, companies, projects, and any notes, then identifies both technical and soft skills. **These skills become part of the verified record.** When the sheet is approved, the skills are frozen into an immutable snapshot, included in a Merkle tree, and attested to the Base blockchain via EAS. The sender can then generate a selective-disclosure proof — a signed token that cryptographically proves they used a specific skill, without revealing their client, rates, or any other fields they choose to keep private. See [Skills Extraction](/zipwire-approve/unboxing-key-concepts/skills-extraction) and [Verifiable Timesheets](/zipwire-approve/verifiable-timesheets) for how this works. *** ## Hours Summary and View Controls At the bottom of the time section, a summary line shows total hours and the number of working days: *"32 hours over 4 days."* This accounts for the public holiday — five calendar days, four billable. The **Hide times** button collapses the day-by-day bar chart, leaving just the activity breakdown and totals. Useful when you're scanning a busy inbox and only need the headline figures. *** ## Comments The comment thread lets approvers, processors, and senders exchange messages directly on the sheet. The conversation is part of the sheet's history and audit trail. In this example, the approver has already left a note: *"Approved! Thanks for your hard work, Luke."* *** ## Actions Three buttons appear at the bottom: * **Approve** — approves the sheet as the current user. The button label reflects your role: *"Approve as Finn"* in this example. On approval, the frozen record is created, the Merkle tree is built, and attestation to the blockchain begins automatically. * **Reject** — sends the sheet back to the sender with the option to add a reason. * **Download PDF** — generates a PDF of the sheet. For approved sheets this is a **verified proof** — a signed document that includes the attestation details and can be shared as evidence of the work. *** ## What Happens After Approval Approval triggers several things automatically: 1. The sheet is locked — no further edits 2. A frozen record is created capturing all fields, skills, and context 3. A Merkle tree is built from the frozen data 4. The Merkle root is attested to the Base blockchain via EAS 5. The sender can generate selective-disclosure proofs from the verified record The result: an approved Zipwire sheet is not just a document — it's a cryptographically verifiable proof of work that the sender can carry with them, share selectively, and use to prove experience without revealing anything they don't want to. See [Verifiable Timesheets](/zipwire-approve/verifiable-timesheets) to learn more. *** ## Learn More {% content-ref url="/pages/ZtmlRIhT3qTCeoUYY5T1" %} [Timesheet Flags](/zipwire-approve/unboxing-key-concepts/timesheet-flags) {% endcontent-ref %} {% content-ref url="/pages/2z6WecyLa8YDtBkj0K6K" %} [Skills Extraction](/zipwire-approve/unboxing-key-concepts/skills-extraction) {% endcontent-ref %} {% content-ref url="/pages/bBE0TkceIu9QSt3a5zX3" %} [Verifiable Timesheets with Selective Disclosure](/zipwire-approve/verifiable-timesheets) {% endcontent-ref %} {% content-ref url="/pages/HMQINGP6nnIrp2MV6EP0" %} [Rate Plans](/zipwire-approve/unboxing-key-concepts/rate-plans) {% endcontent-ref %} # Why we don't track start and end times It's important to understand that Zipwire does not track start and end times. Many people want to track exactly when people arrive and leave, and any breaks they take. At present, Zipwire doesn't do this and only tracks the time spent on an activity. ## Why not? There are a few reasons why Zipwire does not track start and end times. * Most working people arrive and leave at the same time each day, and so don't need to record this information. The activity they track time against can include the usual hours in its name, such as **ABC Leisure > Townsville > 7am - 4pm**. See [Naming activities](/use-cases/for-senders/naming-activities). * In some countries, contract staff who are stipulated to arrive and leave at certain times fall into a different legal category. * Thankfully, many people today work flexibly and it doesn't matter precisely when they start or stop work. * People round up or down to the time when they're supposed to start or stop and effectively don't track the exact truth. * You can use the notes feature to print additional information on the timesheet. * It makes using the Journal much quicker because the UI can be designed for rapid input of duration rather than picking times. * It allows Artificial Intelligence to understand much shorter, more convenient descriptions such as "Last week I worked all week on night shift" where *night shift* is the name of an activity which implies the normal working times. Please reach out to us if you have a compelling reason to track times. We are considering opening the Journal up as an API so other tracking systems can automatically write duration and notes into Zipwire. # Unboxing key concepts This page explains the primary concepts and will give you a firm grounding in how Zipwire hangs together. Fold out the sub pages and choose a concept, or continue to hit **Next** below. # Accounts These are the database records held by Zipwire which store your user information. An account is also used to represent the core existence of a **Workplace**. Each account has a bunch of identities which is how we link your passkey or wallet authentication, for example, to your Zipwire user. # Timesheets We call these **Sheets** in the product, not Timesheets, because a sheet doesn't have to be about time at all. Most of the time (pun intended) a sheet is a collection of contiguous days and the number of time units being billed for on that day, plus some information on what was worked on. But the units billed can come from somewhere other than a clock, so "Timesheet" would imply an assumption the model doesn't make. A sheet has a status, may have attachments, comments and messages, as well as a history of actions, an audit trail and knowledge of the **Workflow**. # Timesheet Flags When a timesheet is submitted, Zipwire automatically scans it for conditions worth an approver's attention. Anything notable is surfaced as a **flag** — a short banner shown at the top of the timesheet view. Flags don't block approval. They're information, not a verdict. ## How Flags Are Computed Flags are calculated twice: at submission, and again if a processor later adjusts which billing units are billed. This keeps them in sync with the current billed state rather than just a snapshot from when the timesheet was first sent.
Timesheet view showing a 'Something to flag — Overworked' banner, with Monday showing 9 billed hours against a standard 8-hour day

The flag banner appears at the top of the timesheet. Here, Monday was billed at 9 hours — one hour over the standard day.

## The Flags ### Holiday Worked Time was logged on a public holiday. Zipwire checks the timesheet's locale (e.g. `en-GB`, `en-US`) against a public holiday calendar. The flag fires on any day where minutes were logged — regardless of whether those hours ended up being billed. ### Weekend Worked Time was logged on a Saturday or Sunday. ### Overworked The sender billed **more** units than the standard day length defined in their billing plan. For example, if the standard is 8 hours and the sender billed 9 hours on a Monday, this flag appears. Standard hours are taken from the active billing plan; the fallback is 8 hours if no plan is found. ### Underworked The sender billed **fewer** units than standard — a partial day where a full day might have been expected. Same calculation as Overworked, but in the other direction. ### Foreign Activities One or more activities on the timesheet belong to a **different assignment** than the one the workflow was created for. This can happen when a sender works across multiple assignments and logs time against the wrong one. Only applies to assigned workflows. ### Multiple Workplaces Activities reference more than one workplace. Most timesheets are scoped to a single workplace, so this may indicate cross-billing or a data entry error. ### Billing Plan Change Mid-Period The sender's rate plan changed partway through the timesheet period. This is legitimate but worth noting — different rates may apply to different days within the same sheet. ### No Rate Plan The timesheet is on a workplace-assigned workflow but all financial totals are zero. This typically means no rate plan was in effect at billing time; the sender may have submitted before their contract was fully configured. # Senders We refer to anyone who sends timesheets as a sender. Typically this is the contract worker, freelancer or temporary worker. They may work for one or more **Clients** or may work directly within the very workplace that's using Zipwire. Sometimes, a sender may also be an **Approver**. # Approvers These are the people who approve the timesheets sent by the senders and are often their line manager. They are sometimes also contract workers, or may be employees of the client. In more unusual cases they are also a **Processor**. When a sender sends a timesheet, it will be sent to the Approver who can approve or reject it. # Processors After the timesheet is approved it is sent to the Processor. To get everyone paid before their mortgage defaults, they rapidly move the timesheet forward through a number of states as they work on making payments and/or charging their clients for the work, if applicable. Processors may work at a staffing agency or within the People Ops department in a company, or the processor could be a solo founder who has hired some freelancers. # Workflows A **Workflow** describes the approval path for timesheets: how they flow between people, who acts at each step, and what they're authorized to do. ## Workflow Components A workflow defines: * **Steps** — Sequential stages in approval (typically: Send → Approve → Process) * **Actors** — Who performs each step and their capacity (Sender, Approver, Processor) * **Invoicing Configuration** — How invoices are generated (PDF or accounting provider sync) * **Rate References** — Which rate plans apply at each step ## Assignment Workflows vs. Self-Created Workflows **Assignment Workflows** (created from Assignments): * Read-only for senders * Defined by the workplace/agency * Tied to an assignment and its billing/rate configuration * Cannot be modified by senders **Self-Created Workflows** (personal/freelancer workflows): * Fully editable by the creator * Used to define approval paths for personal projects * Can configure custom rates and invoicing Though you can't see it, workflow data is written into each timesheet itself so you can delete and change a workflow without it affecting timesheets already in flight. ## Invoice Sync Integration Workflows can be configured to automatically synchronize invoices to your accounting software. When you enable Invoice Sync for a workflow, generated invoices are sent directly to connected providers like Xero, QuickBooks, or FreeAgent—eliminating manual data entry and keeping your accounting system up to date. ### Setting Up Invoice Sync To enable Invoice Sync on a workflow: 1. **Connect your accounting provider** — Go to the Connections tab in your profile and authenticate with your chosen accounting software (e.g., Xero). 2. **Return to My Workflows** — Your connected provider will now appear as an available option alongside the built-in PDF Maker. 3. **Enable the provider** — Click Enable on the provider you want to use. The system will retrieve your available Contacts and Projects from that provider. 4. **Select Contacts and Projects** — Choose which contacts and projects invoices should be synced to. If you don't see what you need, you may need to create them in your accounting software first, then return to enable the workflow again. Once enabled, invoices generated through this workflow will automatically sync to your selected contacts and projects in your accounting software. # Assignments An Assignment is a **managerial bundle** created by a workplace or agency to configure work for a group of senders. ## What's Inside an Assignment The assignment brings together everything needed to manage contractor work: * **Senders** — Who is working (contractors, freelancers) * **Approvers & Processors** — Which Teams will review and process timesheets * **Billing Plan** — A reusable template defining how timesheets are structured (time units, tier grid per weekday) * **Rate Plans** — Per-sender payment tables that reference the billing plan (what each sender gets paid at each tier) * **Activities** — Preset work categories that appear in senders' journal * **Client Link** — Who the assignment is for * **Invoicing Configuration** — How invoices are generated (PDF or accounting provider sync) ## Assignment → Workflow When an assignment is created, it automatically generates an **Assignment Workflow**—a read-only workflow that senders see. This workflow shows them: * The approval path their timesheets will take * Who will review their work * Invoicing details Senders cannot modify the assignment workflow; it's defined by the workplace/agency. # Billing Plans A **Billing Plan** is a reusable template that defines the structure of how timesheets are filled in—what time units are allowed and how they're organized per day. ## What's Inside a Billing Plan * **Time Units** — Hours (24 per day) or Half-Days (6 per day) * **Tier Grid** — A week-long grid per day specifying which tier (A, B, or C) or NA (not available) applies to each time slot * **Standard Hours** — Expected hours per day (typically 8) that defines the boundary between standard and overtime tiers * **Billing Cycle** — Frequency (flexible, weekly, or monthly) ## Why It Matters Senders record detailed work in a private Journal, but the final Timesheet is constrained by the Billing Plan. **Example: UK Billing Plan** * Uses **half-day units** (minimum work unit = 4 hours) * Grid might show: A, A, B, B, NA, NA (4 half-days available Mon-Fri, weekends off) **Example: US Billing Plan** * Uses **hourly units** * Grid shows 24 hours per day with tiers A-C for standard/overtime/premium ## Tiers for Rate Incentives The grid uses **Tier codes (A, B, C)** to support different payment rates: * **Tier A** — Standard hours (e.g., £75/hr) * **Tier B** — Overtime (e.g., £100/hr) * **Tier C** — Premium/night work (e.g., £150/hr) * **NA** — Not available (off hours) This allows you to incentivize or discourage long work days without forcing senders to lie about their hours. ## Reusability A single Billing Plan can be used by multiple Rate Plans across different senders in an assignment or across assignments. For example, "BP1: 8-hour hourly UK" might be used by 10 different senders, each with their own rate plan and pay rates. # Rate Plans A **Rate Plan** is a per-sender payment table that defines what they get paid (and what clients are charged) at each tier defined in the Billing Plan. ## Rate Plan Structure Rate plans are **two-sided**: | Side | Definition | | ---------- | ------------------------------------ | | **Pay** | What the sender earns per unit | | **Charge** | What's billed to the client per unit | Each side has **three tiers** (A, B, C) that directly correspond to the tiers in the Billing Plan: * **Tier A** — Standard hours rate * **Tier B** — Overtime rate * **Tier C** — Premium/night rate ## Multi-Currency Support You can pay senders in one currency and charge clients in another: * Sender gets paid: £75/hr (GBP) * Client is charged: $95/hr (USD) ## Sender-Specific & Temporal Each **sender gets their own rate plan** within an assignment, allowing: * Different rates for different skill levels (Alice: £75/hr, Bob: £100/hr) * **Scheduled rate changes** — Update rates on a specific date without affecting timesheets already submitted * **Multiple effective periods** — You can have Rate Plan v1 (Jan 1 - Jun 30) and Rate Plan v2 (Jul 1 onwards) ## References Billing Plan Every Rate Plan references a **Billing Plan**, which defines the tier structure and time units: * "Use billing plan BP1 (8-hour hourly grid) with these rates: Tier A £75/hr, Tier B £100/hr" * Multiple senders can share the same billing plan but have different rate plans (different pay rates) # Teams & Inboxes Processors and approvers are organised into Teams, which each have an Inbox which can hold items. This is so that the timesheets come to the whole Team and drop into its Inbox instead of going to individuals. This makes it easier for people to share the approval and processing work and means people can be added and removed and instantly see (or not see) all the stuff within. Teams have change audit trail which is not visible, but can be accessed by Zipwire support if you need. In future, we might allow you to add people to a Team which represents people who work for your Client. This could perhaps allow them to login and see their timesheets and how much they're being charged for. A user looking at **Their timesheets** won't see these team inboxes visually broken out; the view is instead divided by assignment. # Workplaces A workplace represents either the company for which all the processors work, or the company the approvers work for. It is the primary security access and administration boundary within Zipwire. A workplace has a proper name and a short name, has Clients, and can create assignments and assign workflows to senders. It often represents your staffing agency, but if you're not an agency, then it'll be your company directly using contract workers, in which case the client can be just set as yourself, or maybe you could represent departments, branches or cost-centers as clients. # Clients Clients are who the work is ultimately being done for. With a staffing agency, clients are usually the corporate customers into which contractors are placed, but when there is no agency and workers are directly hired, the client could be configured as another branch or department or subsidiary of the workplace. # The Journal This is the day-by-day account of what a sender has worked on, the **Activity**, and for how long. It is not visible to anyone but the sender. When a sender creates a timesheet, the information in their Journal is used to fill-out the timesheet according to the rules in the billing plan for the assignment. # Going Plural A sender can work for more than one client, through more than one agency, at the same time - and Zipwire is built around that being completely normal, not an edge case. ## One journal, many clients The [journal](/zipwire-approve/unboxing-key-concepts/the-journal) is a single, private record that belongs to the sender, not to any workplace or agency. Whether someone works for one agency or five, they keep one journal and log their day-to-day work there just once, regardless of how many places that work ends up being billed to. ## Sheets are generated, not typed Because the journal and the [sheet](/zipwire-approve/unboxing-key-concepts/timesheets) are deliberately separate things, a sender doesn't have to keep several different timesheets in step with several different sets of hours. They enter time once in the journal, tagged against whichever **Activity** it belongs to, and Zipwire works out which assignment - and therefore which client, workflow, and billing plan - each entry belongs to. ## Under the hood When it's time to send, Zipwire doesn't produce one sheet from the whole journal. It walks the journal entries, groups them by the assignment each activity is linked to, and sends out a separate copy of the sheet for each one - each routed to the right approver and processor team, correctly filled out under that assignment's own billing plan. A sender working two agencies at once ends up sending two sheets from one act of journalling, without doing the matching themselves. ## Why this only works because the login is personal Going plural isn't a separate feature bolted on top - it falls directly out of [data ownership](/overview/data-ownership-in-zipwire) in Zipwire. Because the account and the journal belong to the individual rather than to whichever agency set them up, there's nothing stopping the same person, the same login, and the same journal from serving several agencies at once, or picking up a new one the moment an old engagement ends. # Activities These are named things that senders work on or ascribe time to. So they may represent a project, or a type of work, but they could be the name of a shift, like "Nights" or "7am to 3pm". An Activity has three parts X > Y > Z to help people organise and structure their names. It doesn't much matter what you name an activity, but short, recognisable names are best. Activities must be linked to Workflows so that Zipwire can collect up all the journal data and organise it by assignment, i.e. put the right stuff on the right timesheet and send it to the right people. Activities can be assigned to senders within the assignment, in which case they will already have a linkage. Otherwise, activities are created by the sender when entering time in their journal and they make the link later when they come to create their timesheet. See also: {% content-ref url="/pages/x69tXPz2BDx962KBCF7f" %} [Naming activities](/use-cases/for-senders/naming-activities) {% endcontent-ref %} # Payment Methods Senders may add one or more Payment Methods to their account. These methods can then be linked to a workflow and the method details will be flowed through on all the associated timesheets. {% hint style="info" %} **Note** - When a sender includes payment information in their invoice details, this information will be superseded by any deliberate Payment Method set on the workflow. {% endhint %} Payment Methods are accessible via the tab in your account settings, see link with your name, top right. ### Adding Payment Details Payment information is different across the world, so Zipwire uses AI to understand and structure the information you enter. To add a payment method, choose the country that the bank resides in, enter a name and then type in the all the details you think someone will need to send you money - as if you were going to email your bank details to a friend in another country. So long as you describe it well, it'll take a variety of text! Examples: * "Robert Johnson, Royal Bank of Canada, Transit: 00001, Account: 123456789" * "Name: Jussi Virtanen IBAN: FI21 1234 5600 0007 85 BIC: ABCDFIHH Bank Name: Finland Bank" ### Blockchain Payments Enter as much about the blockchain address, network or chain as you can and write the name of the token(s) you accept. As above, Zipwire will defer to the knowledge of AI to work out what the address is and store it properly. Examples * "Send Bitcoin to " * "Send USDC or USDT to X-avax1cxqnllsxg6qqe5zg7rjgdp6prw5s6kdk8emel" {% hint style="info" %} **Important** - Zipwire currently has no payments mechanism built in. The information is simply passed on to the processor of your timesheet. Ultimately it is up to them what they do with this information and whether they can send money to you. Please consult with whoever pays you. {% endhint %} # Skills Extraction Automatically discover professional skills from your work history as you log timesheets. AI extracts skills from activities, preventing them from getting lost in your work records. Skills live in your timesheets but stay buried. You log detailed activity descriptions—the projects, technologies, companies—but when you need to write a proposal or update your CV, those skills aren't labeled or easy to find. **Skills extraction automatically discovers professional skills from your timesheet activities** using AI, so you never lose track of what you've built. ## How It Works When you create a timesheet, the system analyzes your activities: * **Activity names** — What did you work on? * **Companies and projects** — Organizational context * **Duration** — How much time did you spend? * **Comments** — Any notes you added? An LLM reads this context and identifies skills you've used. It returns: * **Skill name** — "React", "Project Management", "TypeScript" * **Category** — "Frontend Development", "Leadership", "Language" * **Confidence score** — 0.0–1.0 indicating extraction reliability ## What You Get **Automatic skill profile:** As you log work, your skills accumulate automatically. No manual entry. No forgetting. **Grounded in real work:** Skills come from activities you've actually logged with timestamps and context—not guesses or self-reported claims. **Soft skills too:** The system catches leadership, mentoring, stakeholder management, and other soft skills you performed and documented. **Non-blocking:** If extraction fails (bad response, network issue), your timesheet still gets created. Skills are a bonus, not a blocker. ## Use Cases **Portfolio building:** Your extracted skills feed your public profile automatically. No tedious manual skill lists. **Job matching:** Hiring platforms can match you to opportunities based on your actual extracted skills, not self-reported ones. **Proposal writing:** When you need to write a proposal, your extracted skills are there: "I have 500+ hours of React, 200+ hours of TypeScript, and led a team of 3 engineers." **Audit trail:** Extracted skills are tied to logged work, creating a verifiable record of what you've done. ## Integration with Verifiable Timesheets Extracted skills are included in your **frozen timesheet record** when it's approved. They become part of the Merkle tree and are attested to the blockchain via EAS, so you can prove your skills with cryptographic evidence. See [Verifiable Timesheets](/zipwire-approve/verifiable-timesheets) to learn how your extracted skills become verifiable, portable proofs. ## Learn More {% content-ref url="" %} {% endcontent-ref %} {% content-ref url="/pages/bBE0TkceIu9QSt3a5zX3" %} [Verifiable Timesheets with Selective Disclosure](/zipwire-approve/verifiable-timesheets) {% endcontent-ref %} {% content-ref url="/pages/P1oSNNJGnWqncV3gLSln" %} [Timesheets](/zipwire-approve/unboxing-key-concepts/timesheets) {% endcontent-ref %} # Logical structure Here's how Zipwire organises its key concepts. ### Structure #### Your workplace and its clients The [workplace](/zipwire-approve/unboxing-key-concepts/workplaces) in Zipwire represents the business or organization that manages everyone, assigns work to workers and creates teams of approvers and processors. The workplace has an Administrators Team and its members have full rights over the workplace. In more unusual cases, a user may be an administrator of more than one workplace. If so, additional UI controls will appear to allow that user to switch between the workplace they're acting upon. As in real life, the workplace can (and likely does) have many clients, and each client can have many assignments. #### Assignments and teams The [assignment](/zipwire-approve/unboxing-key-concepts/assignments) is a collection of settings about what the name of the assignment is and who the senders are, and who will approve and process their timesheets. When you go first setup your workplace, you'll be taken through some steps to create your first assignment. This will also create two new [teams](/zipwire-approve/unboxing-key-concepts/teams-and-inboxes) for its approvers and processors–each time you create a new assignment, Zipwire will create two new teams. The teams are actually independent of the assignments and are logically just children of the workplace. This means you can use the same team to approve or process many assignments. If you're a staffing agency, you may want a single team for all the people who process timesheets, and you can do this. It's possible to switch the entire team that does the processing (or approving) on an assignment. Teams can be renamed anytime, or deleted, once it has no assignments and no members. #### Organizing with assignments You can use [assignments](/zipwire-approve/unboxing-key-concepts/assignments) however you wish to break up groups of senders, approvers and processors. {% hint style="info" %} Usually it's the approvers that determine when to make another assignment, just as in a company, it's the line managers that lead groups of people. {% endhint %} In general, people tend to work under a line manager who may have a deputy. These people would approve people's timesheets and so they would have an assignment for their team, and that would have a Zipwire team holding the line manager and her deputy. Another reason to create or even split an assignment up is because of different configuration. This is rare because each sender can have their own [rate plan](/zipwire-approve/unboxing-key-concepts/rate-plans), and each rate can have its own [billing plan](/zipwire-approve/unboxing-key-concepts/billing-plans). # Set up your workplace This page describes how to create your Zipwire workplace which represents your company or organisation. ## Kicking the tyres People trying out Zipwire with a few friendly colleagues can follow this guide. We recommend you use your real Workplace details but set the teams, assignment and client up as something like 'Test'. {% hint style="info" %} You can test Zipwire out on your own but you **must have three completely separate authentication methods**. This could be: * Three different passkeys (created on different devices or browsers) * Three different wallets * A combination of passkeys and wallets We recommend you use multiple devices or browsers as you will need to act out the roles of the sender, approver and processor as different people. It is possible to log out of Zipwire and log back in as the "other person" but it's easy to get confused and have a bad time. Feel free to reach out to and we can play along as one of the roles if that's helpful. {% endhint %}
Step 1: Choosing your role For strangers arriving on the Zipwire homepage and following the **Get started free** links and other calls to actions, you'll first be presented with options to choose what role you'll be playing in Zipwire. The **freebird** option will register you as a new user but will not take you down the workplace creation route. This is because individual senders rarely want the features for managing many freelancers. Choosing either **approver** or **processor** will take you down the workplace setup route. This simple onboarding flow will not only setup your workplace, but also your first assignment and the client who it is with.
Step 2: Inviting your team The onboarding process will collect information about the name of your workplace, its domains for email (the part after the @ sign), and the industry its in. Invites will be sent out to anyone added during this workplace onboarding flow. You'll be presented a UI through which you can add your teammates. If you chose approver in the previous step, then these will be fellow approvers such as team deputies, and for processors this will be colleagues in a payroll team. When adding colleagues, it's expected that these people will have work email address on the domain of your workplace. You'll then have the opportunity to invite people to the processors team (if you're an approver) or approvers team (if you're an approver).
Step 3: Adding senders You can manually add senders, or upload a list of them all if you're feeling brave, and this upload function is also available later. For people testing Zipwire, you probably only want to add one or two members of the team to act as freelance workers.
Step 4: Final checks and naming things The final step will recap the members of the approvers and processors teams, and all the senders. You can go back and fix things. We recommend changing the names of the assignment that will be created and the client. There'll be a short delay in setting this up as we write many changes to the database and fire out all the invites.
Final configuration is done within the assignment UI You'll land on the assignment manager page "within" Zipwire proper. At the top will be some alerts to highlight that you've still got work to do before everything is setup. At this point your workplace is setup, invites have gone out and workflows have been assigned to senders. The things needing attention are the **billing plan, rate plan** and **workplace invoicing.** Go into each one and configure them as you need. You may also wish to add some **assigned activities** so that senders can quickly add time against this work. This is optional and senders can add their own activities in their journal and link this work to the assigned workflow.
Customize your workplace branding Your workplace is setup and ready but you should set your brand's color and a URL pointing to its logo. You workplace branding is used on timesheets as a small touchpoint. Zipwire also places a virtual business card on everyone's dashboard. The card has a contact name and address. You can set these on the assignment manager page.
# Processing stages The timesheet workflow extends beyond create and approve into a series of states within the processing phase. Processors are presented with a tabbed view of all their timesheets. Each tab is a collection of timesheets that are all in a particular state. Each state represents a stage in the processing work that's typically performed in a staffing agency. {% hint style="info" %} Not all users of Zipwire will work in this way, but they may have analogs to these stages in their own domain. In future, Zipwire will allow customization of these states and stages. {% endhint %} ### New Approved timesheets land in the new tab where they can be quickly screened for errors and accepted or rejected. ### Prep Once accepted, there's normally some activities to be done to prepare to pay its sender, and potentially charge the end client. For some agencies, this may include drawing down money from a credit line to fund payroll. The client's invoice can be prepared and sent, too. ### Pay Once these preparations are complete, the sender can usually be paid. Timesheets in this tab have not been paid and have a button to indicate payment has been made and move the timesheet on. ### Receive In most situations, the contractor is paid well before the end client pays their invoice and so timesheets may sit in this tab for weeks. Each timesheet has a button to mark the sheet as having had its client moneys received, or that they are late. ### Late Timesheets in this tab were marked late in the previous stage and need chasing or following closely by credit control. ### Done Finally, timesheets with no further outstanding actions come to rest in the done state. At this point, they can be archived. # Understanding invoicing Zipwire can assist with getting accurate and immediately invoices from your senders, and creating invoices for your clients. Let's dive in, as they say a lot on YouTube. ## Sender Invoicing Freelancers often work under their own one-person company and then invoice the staffing agency for their time. The agency pays this invoice within a week or so and then the agency issues its own invoice to the client for this time. There are several common problems with this. 1. The sender often forgets to send an invoice and needs chasing for it. 2. The sender has to produce the invoice, which can be time consuming and they can procrastinate and hold up the agency and cause cashflow problems. 3. The timesheet comes with an invoice, but they don't match or their rate is wrong. 4. Someone has to check every single timesheet, invoice and rate to detect such errors. Zipwire has a built-in sender invoice generator which will automatically attach an accurate invoice for the timesheet. #### Configuring and enabling Sender Invoicing Three things are needed for the magic to happen, these are: 1. Sender Invoicing must be enabled on the billing plan applied to the sender, see picture below. 2. The workplace must have its inbound invoicing details set, so Zipwire know who to address the invoice to, see the **Invoicing** tab within **My workplace**. 3. The sender must have configured their outbound invoicing details, so Zipwire knows who the invoice is from. Once all three are setup, invoices will automatically appear as attachments on the received timesheets. The sender will only see their invoice once they send the invoice.

Enabling Sender Invoicing within the billing plan editor.

## Client Invoicing Regardless of whether or not there is a sender invoice attached, you can use the monetary information on the timesheet to produce invoices to your client for the people you have supplied. ### Single sheet client invoices You can create a client invoice for each timesheet when its in the Prep stage. When Client Invoicing is setup, a button to show the invoicing controls will appear in the view when you are in **Their timesheets** on the **Prep** tab. When you create a client invoice, it will be downloaded by your browser and will eventually also be attached to the timesheet in the background. You may need to refresh the view to see the attachment. ### Combined client invoices An invoice which has a line item for each timesheet can also be generated. When you hit the button to make a combined invoice, all the timesheets in the current view in the **Prep** stage will be combined into one larger invoice which will be downloaded and also attached to each timesheet. Use the Tags and Filters feature in the view to control which timesheets are included in the combined invoice. ### Invoice numbers Each time you create either a combined or single client invoice, Zipwire increments an invoice number counter. At present, the exact format of the invoice number (or identifier, since it is alphanumeric) cannot be controlled. Please email to show your support for having a customizable format. ### Configuring client invoicing Each client has its own invoicing settings within the client editor area. The general details settings collect information about the client's proper legal name, its address and the name of a person to address the invoice to. The more interesting settings are on the other tab. It's through this interface that you can configure the payment information and tax details to "print" on the invoice. At present, Zipwire only supports generating PDF file invoices. A PDF is a digital hardcopy and so we refer to writing to the PDF as printing. #### Currencies You'll need to start out by choosing the currencies that you'll be invoicing the particular client in. {% hint style="info" %} If a timesheet has its charge rate in a currency that is not configured for client invoicing then you will not be able to generate a client invoice for that timesheet. {% endhint %} When you create a client invoice, it will group line items by currency and apply the relevant tax amount. This grouping really only applies to *combined* client invoices since single ones are a group of one. In any case, under each group, positioned closely to it so it visually relates, your payment details will be "printed". #### Payment details This is where you type in how the client should pay the invoice, which is usually a bank account name and its numbers, or an IBAN identifier or a crypto wallet address. You must choose which currencies the details apply to. #### Tax details The tax details are similar and will result in the text being printed on the PDF close to the currency group of line items to which it relates. The % is simply the amount of tax to levy on the items in the currency group. Again, you must choose the currencies to which the tax details apply. # Using assignments Assignments are at the heart of Zipwire and help you organise everyone. The client assignment is a named bundle of configuration, including the details of several groups of people. * Who will be sending timesheets. * Who they will be sending them to for approval. * Who will process them. {% hint style="info" %} In future, we think it'd be cool to let you add the people in Accounts Payable at your client so they can login to Zipwire and directly see the timesheets they're being billed for, and maybe even add payment functionality. We're also considering letting you specify who within your workplace might manage the account. {% endhint %} The assignment also holds the [billing plan](/zipwire-approve/unboxing-key-concepts/billing-plans) which holds rules around the billable time units, and all the rates senders are paid for work associated with this assignment, stored in the [rate plan](/zipwire-approve/unboxing-key-concepts/rate-plans). Assignments are logical children of your [clients](/zipwire-approve/unboxing-key-concepts/clients). ## Teams The groups of approvers and processors are arranged into [teams](/zipwire-approve/unboxing-key-concepts/teams-and-inboxes). You tell the assignment which team will do the approving or processing. This is not the case for senders which are not placed into teams. The senders are linked directly to the assignment. You can therefore switch the team which is approving, or processing. This also means you can setup a single processing team for your back-office people and put this team on all assignments. When you have a new joiner in the back-office, they only need to be added to the single processing team and they will see timesheets from all assignments. Or you might setup a general processing team, plus another dedicated team for a particular assignment or client. As you can see, it is very flexible. ## Assigned activities You can add activities to the assignment and they'll be pushed out to all the senders so that when they add journal entries, they will see the activity. Assigned activities are pre-linked to the assigned workflow so the sender will not have to manually link it. See [sending your first timesheet](/use-cases/for-senders/send-your-first-timesheet).

The assigned activities UI.

This feature makes it simpler for a sender to get started tracking time. It's often used where the activity name carries information like a cost-center ID which could be incorrectly entered (or missed) by the sender. {% hint style="info" %} Keep in mind that senders can still create their own activities and link them to your assigned workflow. There's no feature in Zipwire to prevent a workflow from having user-made activities linked to it. {% endhint %} ## When to make a new assignment The need for a new assignment should arise naturally because any existing one either has the wrong name, or is for a different client, but in general, assignments are focused around the senders and their manager(s). Typically, an assignment represents a group of people working for a particular boss. Assignments can have many billing plans configured. Each sender can use a particular billing plan, which is set in the rate plan. This means you can have a single assignment but differing billing. However, a new assignment can be used whenever you need to split the configuration in some way, perhaps because the contact details are different across two groups of senders, or their hiring manager. You can also split an assignment to solve more unusual situations. For example, if you have different pay or charge rates depending upon the work, then you can create two assignments each with an assigned activity which describes the work. Remember that activity names can be any text, including shift times, or cost centers. {% hint style="info" %} Watch out! If you have a sender in two different assignments for the same client, then you will need to remember to change their rate in both assignments. As mentioned, having two rates is a feature and solves for unusual situations. {% endhint %} ## Workflows The flip-side of an assignment is the workflow. While a People Ops department or agency might see things in terms of assignments, the senders see things in terms of a workflow. As we discussed, the assignment holds a bunch of configuration, of which the key part is who will do what. In essence, a workflow stores who will do what with the sender's timesheets. A workflow is assigned to each of its senders. The sender's activities used in their journal must be linked to a workflow. This linkage is saying "here's who deals with signing-off on the time spent on activity Y". When a timesheet is created, a copy of the workflow is written into it. Therefore, if you alter a workflow or delete it, it will not impact any timesheets that have already been created. {% hint style="info" %} The workflow knows of the teams responsible for the approve and process steps and it's the team inbox ID and not its members that gets written into the timesheet. Adding or removing members from a team will have immediate impact, because timesheets are sent to team inboxes, not to individuals. Contact {% endhint %} {% content-ref url="/pages/x69tXPz2BDx962KBCF7f" %} [Naming activities](/use-cases/for-senders/naming-activities) {% endcontent-ref %} # Holiday assignment Assignments and activities can be used in creative ways. You can use assignments to keep track of holiday time. * Create another assignment for the client and give it a good name. * Assign the same senders as are assigned to the working assignment. * Switch the approvers and processors teams to the same as for the working assignment. * Configure the billing plan units and invoicing. * Leave the rates at zero. * Add an activity such as Corp > 2023 > Leave 25d Standard Now the senders can put time against this in their journal along with their regular work. When they come to create timesheets, Zipwire will create two timesheets, one for each assignment, and each will be routed through to the same teams for approval and processing. {% hint style="info" %} Watch out! Remember to add new senders to this assignment each time you add them to the working assignment. {% endhint %} # Letting the Client Own the Workplace An agency doesn't have to be the one running the show - the client can own the workplace instead, with the agency slotted in as the processor. The usual setup has the agency create the workplace: the agency invites senders, sets up assignments, and puts its own people forward as approvers and processors, with clients recorded underneath as just names to bill. That's not the only way to arrange it. A [workplace](/zipwire-approve/unboxing-key-concepts/workplaces) is just the primary security and administration boundary in Zipwire - whoever creates it is the one who can create assignments, invite people, and see everything. There's nothing stopping the **client** from being that party instead of the agency. ## Why you'd do this * The client wants direct visibility and control over the record of work, rather than seeing it second-hand through whatever the agency chooses to share. * The agency is being brought in purely as a payments/processing service - getting contractors paid and invoices settled - rather than as the party that owns the working relationship. * The client already runs several contractors directly and just wants one agency to handle the processing side for all of them, without handing over administration of the workplace itself. ## How it's set up * The **client** creates the workplace, rather than the agency. * The client adds the **sender** (the contractor) directly to an assignment - there's no need for the agency to sit between the client and the sender at all. * Instead of putting its own staff forward as [approver](/zipwire-approve/unboxing-key-concepts/approvers) and [processor](/zipwire-approve/unboxing-key-concepts/processors), the client invites the **agency's team** in as the processor (and, if it suits, the approver too). * The client's own people can still hold the approver role themselves, using the agency purely to process payment and invoicing - or they can hand off both roles to the agency and just keep an eye on things. The sender → approver → processor chain doesn't change. What changes is who owns the workplace the chain lives inside, and therefore who's ultimately in control of it. {% hint style="info" %} Because a sender's Zipwire login belongs to them, not to whoever set up the workplace, none of this affects the sender's side of things. They see the same journal and the same timesheet either way, regardless of whether the client or the agency is the one running the workplace. {% endhint %} {% content-ref url="/pages/BHyhtIffT7Kz03RvMNRc" %} [Workplaces](/zipwire-approve/unboxing-key-concepts/workplaces) {% endcontent-ref %} {% content-ref url="/pages/lceFNzBxeDHf8vz61bGd" %} [Processors](/zipwire-approve/unboxing-key-concepts/processors) {% endcontent-ref %} # Verifiable Timesheets with Selective Disclosure Timesheets attested to the blockchain as cryptographic proofs. Prove your work history with selective disclosure—no employer verification call needed. Perfect for regulated industries requiring recent Timesheets prove you worked. But they're just documents—easy to falsify, hard to verify. **Verifiable timesheets are blockchain-attested proofs of your work.** When your timesheet is approved, we create an immutable frozen record, build a Merkle tree, and attest it to the Base blockchain. You can then generate selective-disclosure proofs revealing only the claims you choose. The verifier checks the proof cryptographically—no call to us needed, no trust required. Just proof. ## The Problem They Solve ### AI-Generated CVs LLMs can write a convincing CV in seconds: "500 hours of React. Led a team of 5. Shipped production systems." Did any of it happen? There's no way to know instantly. ### Regulatory Recency Requirements In regulated industries—aviation, finance, healthcare—employers must verify *recent* work experience before hire: * **Pilots:** Must have flown within the past 90 days * **Compliance officers:** Need recent regulatory experience * **Healthcare workers:** Must have recent clinical hours Checking recency today means days of manual verification: calling references, hunting through CVs, hoping records exist. It's slow, error-prone, and leaves room for fabrication. ### The Trust Gap When you claim experience, employers have two bad options: 1. Hope they trust you and risk hiring someone who can't do the job 2. Spend days running reference checks and hunting for documented proof There's no instant way to verify: you actually did this work, you actually have this skill, with no room for exaggeration or AI-generated fantasy. ## How It Works ### 1. Timesheet Approved → Frozen Record Created When you submit your timesheet and it's approved, we create a **FrozenTimesheet**: an immutable snapshot containing: * Your work details (dates, hours, activities) * [Extracted skills](/zipwire-approve/unboxing-key-concepts/skills-extraction) * Approver signature * Work and billing summaries * Engagement context (clients, projects, agencies) ### 2. Merkle Tree Built → Root Hash Generated We build a deterministic Merkle tree from the frozen data. Each leaf represents a piece of information: * A skill you used * A day you worked * Your approver * Billing information The root hash is a single cryptographic value representing the *entire* timesheet. ### 3. Root Hash Attested to Base Blockchain We publish the root hash to the **Base blockchain** via **EAS (Ethereum Attestation Service)**. It's signed by us (Zipwire) and permanently recorded on-chain. Your work is now verifiable. ### 4. Create a Selective-Disclosure Proof You decide what to reveal. ProofPack generates a signed token (JWS) that cryptographically proves your disclosed claims come from the attested timesheet (see [Understanding ProofPack](/fundamentals/security/understanding-proofpack) for how this is structured):
Selective disclosure interface showing Merkle tree and checkboxes for choosing which timesheet fields to reveal in the proof

Select which fields to reveal in your proof. Checked fields (approvedAt, approver, assignment, skillsUsed, worker, workSummary) will be publicly visible in the proof. Unchecked fields remain private.

* **"React experience?"** Prove it without disclosing client names or exact dates * **"Approved on this date?"** Prove it without showing salary or hours * **"Recent work?"** Prove you've worked in the past 90 days without revealing projects ### 5. Verifier Checks the Proof The employer, client, or service uses ProofPack to verify your proof: 1. Check the JWS signature 2. Verify the Merkle proof connects disclosed fields to the attested root 3. Confirm the root hash exists on-chain on Base 4. Trust the claims without exposing your full timesheet No call to Zipwire. No central IdP. Just cryptographic certainty. ## Real Use Cases ### Job Applications "I have 500 hours of TypeScript experience." Generate a proof. Employer verifies it cryptographically in milliseconds. No reference checks. No waiting for "I forgot they worked here." ### Regulatory Recency Verification A pilot applying for a job generates a proof of flight hours from the past 90 days—on-chain, tamper-proof. A compliance officer proves recent regulatory work. An RN proves recent clinical experience. Instant verification. No manual hunting. ### Client Audits "Can you prove the hours you billed?" Generate a proof of total hours and approver signature from your frozen timesheet. Cryptographically verifiable. ### Contractor Verification Platforms matching freelancers to jobs verify skills and experience directly from on-chain attestations instead of trusting self-reported profiles. ### Compliance and Background Checks Regulated industries need verifiable work history for hiring compliance. Blockchain attestations provide tamper-proof records that satisfy regulatory requirements without manual verification calls. ## Why This Matters **No verification call required.** Employers verify the proof cryptographically in milliseconds instead of spending days calling references. **AI-proof.** CVs are easy to generate with an LLM. Blockchain attestations are not. Your work is cryptographically signed and on-chain. **Privacy-preserving.** You reveal only what's necessary. Past clients, exact salary, other projects stay private. But verifiers still trust the claims you do make—because they're backed by cryptographic proof. **Permanent record.** Your approved timesheets live on-chain forever. No lost references. No "I can't remember if they worked here." No convenient amnesia. **Portable.** One timesheet, many uses. Prove hours to one employer, skills to another, contractor status to a third—all with the same on-chain record. ## Technical Details **Merkle trees with random salts:** Each leaf has a random salt preventing preimage attacks and enabling selective disclosure. Different hashes on rebuild are intentional—the handler stores the tree once at approval. **Base blockchain:** Layer 2 Ethereum, fast and cheap. Via EAS (Ethereum Attestation Service), the industry standard for on-chain attestations. **ProofPack:** Open standard for creating and verifying selective-disclosure proofs. JavaScript and .NET implementations available. No vendor lock-in. **JWS tokens:** Compact, portable proofs that work in HTTP headers, API requests, or as standalone tokens. ## Getting Started 1. **Create and approve a timesheet** — All fields populate automatically 2. **Frozen record generated** — Automatic, no action needed 3. **Merkle tree built and attested** — Your work is now on-chain 4. **Mint selective-disclosure proofs** — Via Zipwire API, choose what to reveal 5. **Share proof (JWS token)** — With any verifier who needs to check your work 6. **Verifier uses ProofPack** — No Zipwire API call needed, just cryptographic verification ## Privacy and Security **Privacy-first design:** Your personal data never leaves your control and never goes on-chain. Only cryptographic hashes are stored on the blockchain. You choose exactly what to reveal in each proof. **Security features:** * Government-approved ID verification (via Zipwire Attest) * Optional AML background checks * Cryptographic proofs ensure data integrity * On-chain attestations prevent tampering See [Blockchain Attestations](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml/blockchain-attestations) for deeper technical details. ## Learn More ### Documentation {% content-ref url="/pages/2z6WecyLa8YDtBkj0K6K" %} [Skills Extraction](/zipwire-approve/unboxing-key-concepts/skills-extraction) {% endcontent-ref %} {% content-ref url="/pages/kzmdzG6x7y91vzCPFJMX" %} [Your Digital Identity on the Blockchain](/zipwire-attest/zipwire-attest) {% endcontent-ref %} {% content-ref url="/pages/o6oB9rNFDKiUMPlCA1As" %} [Blockchain Attestations](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml/blockchain-attestations) {% endcontent-ref %} ### ProofPack For code examples and integration details, see the [ProofPack Repository](https://github.com/zipwireapp/ProofPack). ### Blog Post For a detailed walkthrough with real-world examples, see: [Verifiable Timesheets: Prove Your Work Without Revealing Everything](https://zipwire.io/blog/articles/2026-05/verifiable-timesheets/verifiable-timesheets-with-selective-disclosure) # Effortless Document Collection for Any Need [**Get started with Zipwire Collect →**](https://zipwire.io/collect) Zipwire Collect takes the hassle out of gathering information, streamlining document collection for any scenario - from a single proof of address to a full compliance onboarding with dozens of conditional documents. Rather than one long feature list, we've split the platform's ideas across a handful of short pages so you can go at your own pace. Here's the order we'd suggest: * [**Get Started**](/zipwire-collect/get-started) - sign up and create your first collection. * [**Lifecycle of a Collection**](/zipwire-collect/lifecycle-of-a-collection) - how a collection is created, opened, nudged along and closed. * [**Using Packs**](/zipwire-collect/using-packs) - the building block for grouping documents, setting completion rules, nesting packs, and adding conditional logic. * [**Manual Entry**](/zipwire-collect/manual-entry-for-streamlined-information-gathering) - collect forms, codes, and confirmations alongside documents. * [**Machine Vision**](/zipwire-collect/machine-vision) - automatic document identification and field extraction. * [**Document Inspection**](/zipwire-collect/document-inspection) - the range of review types, from fully automated to in-person, plus document freshness rules. * [**What the Respondent Sees at Their End**](/zipwire-collect/what-the-respondent-sees-at-their-end) - how your carefully nested packs flatten into a simple list for your respondent. * [**UK Right to Rent Template**](/zipwire-collect/uk-right-to-rent-template) - a worked example showing conditional logic and nested packs in action. * [**Bulk Upload**](/zipwire-collect/bulk-upload) - respondents can send a whole folder of files at once. * [**Creating a Collection with AI**](/zipwire-collect/creating-a-collection-with-ai) - describe what you need in plain language and let AI draft the collection. * [**Sign It Once, Prove It Forever**](/zipwire-collect/signable-documents-cryptographic-proof) - attach a document for signature and get cryptographic proof that doesn't depend on Zipwire. * [**IDSP, IDVT, KYC, KYB and AML**](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml) - compliance-grade identity and business checks, including Yoti-powered selfie checks. **Zipwire Collect goes beyond simple document collection, offering a feature-rich platform that saves you time, reduces errors, and ensures a smooth experience for everyone.** # Get Started The following guide will help you get started quickly with Zipwire Collect. ## Sign-up Zipwire uses passkeys and wallet authentication to sign in securely without passwords. You can create a passkey in your browser, or if you're at work and want to keep it personal, scan a QR code with your phone to sign in. Alternatively, you can connect your Ethereum wallet. When you sign-in, we'll create a new user account and link it to your authentication method. If you're new to Zipwire and you're signing-up via the Zipwire Collect promo page, we'll ask you for your work email, your workplace name and industry, then create a new workplace account. We'll send an email to your work email and, once you've confirmed, we'll drop you on the **Create** tab of **Their docs**. {% hint style="info" %} **Feeling brave?** You can also sign up over WhatsApp by messaging our full-featured bot on **+1 (949) 806-6089**. It's a US number because that's just how our WhatsApp bot is provisioned, not because the service is US-only. Just send **"Hello"** to kick things off, then tell it a bit about who you are and what you're trying to collect - the bot will take it from there. Or skip the typing: [**tap here to open WhatsApp with a "Hello I want to collect docs" message ready to send**](https://wa.me/19498066089?text=Hello%20I%20want%20to%20collect%20docs). {% endhint %} ## Creating a new collection If you're not already there, then head for **Their docs** which is the hub for managing your workplace collection requests. #### Workplace relationships Collections are created by you the **requestor** and completed by the **respondent**. To create a new collection we need to know who your respondent is so we can create a connection between your workplace and this person, which we call a relationship. When you enter your respondent's details we'll first use the email address you've entered to see if that person is already known to Zipwire. If they are *not* found in our database, Zipwire will create a new placeholder account for them and send out an invitation via email and also WhatsApp, so long as you provide their mobile number. If your respondent's email *is* already known to Zipwire, then we'll just send out the invitation. In either case, you'll see a new person listed under **Our people**, a hub which shows all the relationships your workplace has. If you want to collect documents from an existing relationship, you can come here first, find their name and hit **Manage** to see their profile. Then you can hit the **Collect documents** button. {% hint style="info" %} It can take a few minutes for new relationships to show up on the **Our people** hub. {% endhint %} #### Workplace and relationship documents If your workplace does not already have a relationship with your target respondent, you can create a new collection on the **Create** tab within **Their docs**. In other words, 1. Go to **Their docs** and the **Create** tab. 2. Enter your respondent's email address and hit **Continue**. Zipwire will check to see if it knows this email address and if it does, then you'll be taken to the **Create** tab within the hub for that respondent. If Zipwire does not know the email, then you'll be asked for their name and mobile number, so Zipwire can create a new relationship for them, then you'll be taken to the **Create** tab as above.

The Create tab within the hub page for the respondent, "Finn" in this case.

3. Enter the name of the collection – heed the advice on the page and provide a good, clear name and then hit **Create**. After a few seconds, you'll be presented with an empty collection. 4. Enter a clear description of what you are collecting and why. Use this to communicate with your respondent to provide clear instructions. 5. Use the **Add document** or **Add pack** to add a document to the empty collection. You can choose from many different document types, including manual entry forms. Use the **Instructions** field to communicate with your respondent and articulate a clear description of what document you need and what information you'll expect to be visible on it.

The empty collection request editor with the bottom panel showing the UI for adding a new document.

6. Click **Add** to add the document to the collection and gain access to further settings for the item. 7. To add a **Pack**, repeat the steps above but choose **Add Pack**, give it a name and click **Add**. An empty pack item will be added to the collection. You can then hit **Edit pack** to navigate down into the pack where you can add documents and further packs. Use the **Back** button at the top to navigate back up and return. {% hint style="info" %} Once open, your respondent will not see these packs in this way. All documents will be "flattened" and presented in a single, long list. See [Using Packs](/zipwire-collect/using-packs). {% endhint %} 8. When you're done adding documents and packs and you're ready to send an invitation to your respondent, click **Open**. Your respondent will be emailed an invitation, they will also see a notice on their Zipwire dashboard, and if Zipwire knows their mobile number, we'll ping them a link. {% hint style="info" %} **Private Collections** You can also open a collection for your workplace to privately collect files. This allows you to track the collection of documents without the respondent knowing. Collections log the time of upload as well as when a document is accepted. In some jurisdictions, holding such records and being able to show them is critical for legal compliance. {% endhint %} ### Exporting templates Templates are collection requests that you've stored whilst editing. You can use templates to avoid redefining a collection again and again. You can also choose a previously saved template when adding a pack to a collection. We recommend you familiarise yourself with packs. [Using Packs](/zipwire-collect/using-packs) Often you'll be collecting the same sets of documents from many people, and those sets are commonly needed for a particular purpose. For example, you may wish to collect the documents to prove a contractor has the proper insurances you need. You could create a template for this by first creating a new, empty collection named **Business Insurance Pack**. To do this, you'd first create and define an insurances collection for a respondent, but never actually open and send it, instead exporting the collection as a template, then you'd discard the collection. The next time you visit the **Create** tab to create a new collection, you'll be able to pick the Business Insurance Pack template. Let's break this into steps: 1. Pick a respondent and go to their **Create** tab. You won't be opening the collection so it doesn't matter who the respondent is, though you may want to choose a colleague just in case you accidentally do open it. 2. As if creating a new collection, enter the name 'Business Insurance Pack' and click **Create**. 3. Add any documents and sub-packs to the empty collection and configure as needed. 4. Scroll down and click **Export** and wait for it to finish exporting. You can't see it yet, but you now have a Business Insurance Pack template stored. 5. Hit **Discard collection** and hit **Save** to actually discard it. 6. Back on the **Create** tab for the respondent, you'll see a template picker control where you can now choose the new template and hit **Create** to create it. 7. Alternatively, you can create a new, empty collection and when you add a pack, you can choose this template.
{% hint style="info" %} At the time of writing there is no support for removing exported templates. We are working on an interface through which you can manage your templates. In the meantime, please contact support and we can remove it from our end. {% endhint %} That's it. If you have any trouble, please reach out to our support team. # Signable Documents Zipwire Collect can attach a PDF to a collection item and have your respondent cryptographically witness it, so you both end up with tamper-proof evidence of exactly what was signed. ## What is a signable document? When you're designing a collection request, you can add a **Signable document** item and attach a PDF that your respondent needs to review and sign, for example a contract, policy acknowledgement or agreement. Unlike a normal upload, a signable document isn't just filed away. Zipwire reads the paragraph structure of the PDF and builds a **Merkle tree** from it, a cryptographic structure that lets anyone later prove exactly what the document said, paragraph by paragraph, without needing to re-share the whole file. When your respondent signs, that Merkle tree's root is **attested on-chain** using the Ethereum Attestation Service (EAS), always from Zipwire's own attester wallet: * If your respondent has a wallet linked, the attestation is addressed to that wallet as recipient — free and frictionless, with no signing action or gas cost on their part. * If they don't have a wallet linked, Zipwire addresses the attestation to itself instead, acting as a **cryptographic witness** on their behalf. {% hint style="info" %} **Coming soon:** wallet holders will be able to sign the attestation themselves, directly from their own wallet, instead of Zipwire signing on their behalf. That adds a small amount of signing friction and a tiny gas cost, in exchange for the strongest possible identity guarantee. {% endhint %} Once complete, both you and your respondent keep a copy of the PDF, the Merkle tree, and the attestation UID(s) in your own protected Zipwire storage. Either party can later reconstruct a Merkle proof and look up the on-chain attestation to prove exactly what was signed and when, independently of Zipwire. ## Two signatures: yours, then theirs A signable document is actually signed twice, once by each side of the request: 1. **You sign first, as the requestor.** After you attach a PDF to a Signable document item, a **Sign** button appears in the designer. Clicking it builds a small Merkle tree covering the exact bytes of the file you uploaded, plus who you are and when you signed, and has Zipwire attest to that tree's root on-chain. This is a **file-integrity signature**: it locks in and proves that the file the respondent is about to see is byte-for-byte the one you uploaded, and it cryptographically witnesses your intent to send it. You can't send the collection to your respondent until every Signable item in it has been signed this way. 2. **Your respondent signs second.** Once they open the collection and reach the signable item, they review the extracted document and sign it themselves, in the same wallet-or-witnessed manner described above. Their tree references your earlier file-integrity attestation, so a verifier can see that both signatures concern the exact same file. This two-step design mirrors how a paper contract works: the party requesting a signature effectively "sends" a specific, fixed version of the document, and the signer then signs that exact version, not some version that could have changed in transit. ## A network of supporting evidence If your respondent already holds other Zipwire attestations — an ID check, `IsAHuman`, `HasClearAML`, or an age tier — their signing attestation doesn't stand alone. Zipwire looks up every identity-interesting attestation already linked to their wallet and: * references the single strongest one directly, using the attestation's on-chain `refUID` field, and * lists every one it found in a `signerIdentityAttestations` leaf on the signing tree, so a verifier can see, and independently check on-chain, the full picture, not just the one that got the `refUID` slot. The strongest evidence wins the `refUID` slot, in this order: a completed **ID check** first, then `IsAHuman`, then `HasClearAML`, then an age attestation, with the freshest attestation breaking ties within the same tier. {% hint style="info" %} **For the strongest possible proof, run an ID check before the document is signed.** An ID check outranks every other kind of evidence here — if your respondent completes one first, it's what gets referenced, and it's the richest, most independently verifiable evidence a signature can carry. {% endhint %} If your respondent has no other Zipwire attestations at signing time, this leaf is simply omitted from the tree — nothing extra to see, and the base signature is exactly as strong as described above. {% content-ref url="/pages/mohdewNdaWrgQQiCYViI" %} [Signer Identity Cross-Referencing](/fundamentals/security/attestations/signer-identity-cross-referencing) {% endcontent-ref %} ## Attestation, not notarisation Zipwire's role here is to provide the cryptographic plumbing, not a legal service. We anchor a fingerprint of the document to the blockchain and, where needed, act as a witness — we don't assess anyone's legal capacity to sign, and an attestation is not a substitute for legal advice or a statutory notarial act. A [notary](https://en.wikipedia.org/wiki/Notary) is a specific, licensed legal officer, appointed under a jurisdiction's own laws to formally witness signatures, verify identity and capacity in person, and certify documents in a way that carries statutory legal weight. It's a defined legal role, not a general description of "someone who witnesses signatures" — which is why what Zipwire does, however similar it may look, isn't notarisation and can't stand in for it. {% hint style="warning" %} **Disclaimer of Notarial Status:** Zipwire is a decentralized technological platform. It provides cryptographic attestation, digital witnessing, and blockchain-based data integrity services. Zipwire is not a notary public, law firm, or legal professional. It does not provide legal advice, subjective capacity assessments, or statutory notarisation services. The automated verification and attestation protocols provided by Zipwire do not constitute a public act of notarisation as defined by global statutory authorities. Users are solely responsible for ensuring that blockchain-backed attestations meet the specific legal and regulatory criteria of their target jurisdiction. {% endhint %} ## Why a Merkle tree? Building a [Merkle tree](/fundamentals/security/understanding-merkle-trees-and-proofs) from the document's paragraphs, rather than just hashing the whole PDF, means a proof can later be generated for the document as a whole while still allowing tamper-evidence down to individual paragraphs. It's the same selective-disclosure approach used elsewhere in Zipwire, such as in [Your Digital Identity on the Blockchain](/zipwire-attest/zipwire-attest), applied here to contracts and agreements instead of identity documents. ## Proving one clause without revealing the rest Because the tree is built one [leaf](/fundamentals/security/understanding-merkle-trees-and-proofs) per paragraph, a [Merkle proof](/fundamentals/security/understanding-merkle-trees-and-proofs) doesn't have to cover the whole document — it can cover just one paragraph. That means someone holding the signed PDF and its Merkle tree can later produce a small proof for a single clause, say, "clause 7 says X", and hand that proof to a verifier along with the paragraph text itself. The verifier checks the proof against the [Merkle root](/fundamentals/security/understanding-merkle-trees-and-proofs) that was attested [on-chain](/fundamentals/security/crypto-and-blockchain-basics) at signing time. If it checks out, they know that exact clause was genuinely part of the document both parties signed, without ever seeing clauses 1–6 or 8–N. This is the same idea as revealing a single fact from a passport in Zipwire Attest, applied to a contract: you share the one term that matters and a proof of its authenticity, not the whole document. It's useful anywhere only one term is in dispute, or only needs verifying, for example proving a specific payment clause or liability cap was agreed, without handing an entire contract to a court, an auditor, or a counterparty's lawyer who only needs that one fact confirmed.
The Proofs tab generating a single-paragraph proof file, selecting only paragraph_1 and the signer metadata

Generating a proof for a single paragraph from the Proofs tab — the downloaded file only covers paragraph_1 and signer metadata, not the rest of the document.

You can do this today: from the **Proofs** tab, pick the specific keys you want to disclose — for example just `context.document.paragraph_1` plus the signer details — and generate a proof file covering only those. Anyone holding that file and the paragraph text can verify it against the on-chain Merkle root without ever seeing the rest of the document. The proof file itself is a [ProofPack](/fundamentals/security/understanding-proofpack) — Zipwire's general-purpose format for exactly this kind of selective-disclosure, blockchain-attested proof. [Blockchain Attestations](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml/blockchain-attestations) For the pitch on why this is worth switching to, see [Sign It Once, Prove It Forever](/zipwire-collect/signable-documents-cryptographic-proof). # Lifecycle of a Collection Here we explain how a collection comes into the world, exists for a while and then gets closed. ## Creating a new collection A collection starts with the person who you're collecting documents from, otherwise known as the **respondent**. * Head to **My docs** and then go to the **Create** tab and stick their email address in. Or, if you have already collected from them... * Go to the **Our people** section and find the person you'd like to collect documents from, hit **Manage** and then hit the **Collect documents** button If the email address is unknown to Zipwire, we'll send an invitation out, otherwise we'll locate their account and take you to the Create tab of their documents section where you can name the collection, pick a template (if you have any saved), and get going. ### Edit, design and configure Once created, you'll see the collection in its editing state. The respondent has not yet been notified, so you're safe to delete it again and they'll be none the wiser. In this mode, you can add and remove documents and packs and get it how you want it. Once you think it's all good, click **Open**. This'll take a few moments and during this time we'll email and send WhatsApp messages to your respondent. ### Open Once open, your respondent can see it in their **Open** tab and they can (and should) send you documents for review. [What the Respondent Sees at Their End](/zipwire-collect/what-the-respondent-sees-at-their-end) You can make some documents optional and you can upload your own files, for example if you find copies somewhere or they send them to you some other way. Other than that, you generally wait. Zipwire Collect will remind your respondent if they stop sending you things. {% hint style="info" %} You can see if someone has logged-in to Zipwire by visiting **Our people** and click **Manage** where you'll see an overview of them. This view captures your workplace's relationship with this person. {% endhint %} ### Close and force close Once everything has arrived and you're happy, you can and should close the collection. We'll let your respondent know and thank them. Your respondent can also hit the **Force close** button on their side. This marks all remaining documents as refused and closes the collection so they won't get nagged again.

The Force close button on the respondent's side

Closed collections pile up under the **Done** tab. At present there is no archive. You can come here to see past collections and access their files and view their forms. # Using Packs This page dives into Zipwire Collect's innovative pack system, explaining how it streamlines onboarding by simplifying document collection, customization, and ensuring compliance. ### Zipwire Collect: Powerful Packs for Streamlined Onboarding Zipwire Collect goes beyond basic document collection with its innovative pack system. Think of them as pre-built folders tailored to specific needs. Common examples include "Proof of Address," "Insurance Certificates," or "Identity Verification." But Zipwire Collect doesn't stop there. **Powerful Customization:** * **Define Completion Rules:** Each pack can have its own completion rules. Need two documents out of five options (e.g., utility bill, driver's license, bank statement)? A pack can handle that! * **Nested Packs:** For complex requirements, nest packs within each other. Imagine collecting a "Foreign Worker Pack" that only activates if a passport from a certain country is submitted. * **Conditional Logic:** Leverage Zipwire Collect's conditional logic to ensure you gather the right documents every time. For example, automatically request a visa if a passport isn't from a pre-approved list. **Effortless and Efficient:** This powerful pack system streamlines onboarding by: * **Saving Time:** Template packs eliminate the need to manually request specific documents each time. **You can save frequently used packs for reuse as templates,** saving even more time when setting up new document collections for different worker types. * **Reducing Errors:** Conditional logic ensures you collect the right documents based on individual worker situations. * **Improving Compliance:** Clearly defined pack requirements help you meet regulatory requirements for onboarding. **Zipwire Collect's pack system makes document collection a breeze, empowering you to onboard workers quickly and efficiently.** ## Examples #### PASS One the most useful ideas behind packs is to allow you to collect one of a number of documents. The UK has a scheme for issuers of identity cards called PASS, Proof of Age Standards Scheme. There are many issuers under this scheme who each have their own kind of card and a person usually only has one of these. A proper PASS card is considered a fairly strong means of identification so you could create a PASS ID Pack which contains all the various kinds of PASS IDs available and a rule that stipulates "any 1 of these". #### Business Insurances You may require any subcontractors you work with to be adequately insured against damages or losses they may cause in the process of delivering their work. It's common for businesses to need to have Professional Indemnity Insurance and/or Professional Liability Insurance and the insurer will furnish the business with a certificate document, often a PDF. Both of these types of certificate are great ideas to put into a Business Insurances Pack where both proofs are required. #### Various Proofs Another fantastic way to use packs is to give options for the ways in which a person might supply a proof. Sometimes a person is in possession of a physical certificate they can photograph, or a PDF file issued by an authority, but increasingly people can generate online proofs such as share-codes and web hyperlinks. A pack with the "any 1 of these" rule can include either way of submitting the proof. This pack can then be included in other packs, such as those in the examples above. # Manual Entry for Streamlined Information Gathering Zipwire Collect isn't just about collecting documents. It empowers you to gather a wider range of information through its versatile manual entry options. This allows you to create comprehensive packs that combine documents with specific details, streamlining your information gathering process. ### **Seamless Integration** Manual entry options seamlessly integrate with document uploads within packs. You can mix and match, ensuring you collect everything you need in a single, organized request. ### **Variety of Entry Types** Zipwire Collect offers a range of manual entry options to suit your specific needs. | Type | Description | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | **URL** | Need to collect links to relevant websites or online profiles? Include a URL entry field in your pack. | | **Confirmation** | Require verification of an action or agreement? A confirmation checkbox ensures clear acknowledgment. | | **Comment** | Offer space for additional information or clarification with a comment field. | | **Code** | Collect access codes, license numbers, or other unique identifiers with a dedicated code entry field. | | **Identifying details** | This item collects a person's name, date and place of birth, nationality, citizenship so as to distinguish them from anyone else. | | **Company details** | Collect a business's registered name, registration number, VAT number, registered address, and year/month of incorporation. | | **Residence details** | Gather a person's primary home address, mailing address (if different), and country of residence. | | **Tax details** | Collect tax domicile and a tax identification number - National Insurance number, UTR, SSN, or equivalent. | | **Residential address history** | Gather past addresses for compliance purposes or background checks. | | **Employment reference history** | Streamline reference checks by collecting contact information and previous employers directly within the platform. | | **Emergency contact** | Collect the name and contact number to use in emergencies | | **Yes or No** | Ask a simple question. Useful when paired with conditional logic. | {% hint style="info" %} **Claimed Identity** When assessing a person's identity, it is important to collect information from the person as to who they claim to be so you can compare this information against the supporting evidence they provide. Use the **Identifying details** item type for this. {% endhint %} ### Example - Employment reference history Here's what the form looks like to your respondent.

The reference history form with checked start and end dates

### **Enhanced Efficiency** * **Reduced Back-and-Forth:** Combining documents and manual entry eliminates the need for separate requests, saving time and effort. * **Centralized Information:** All details are stored in one secure location, improving accessibility and organization. * **Conditional Logic:** Use conditional logic to tailor manual entry fields based on uploaded documents. For example, only request employment history if a reference pack is selected. ### **Example Use Cases** Here's how manual entry can enhance your Zipwire Collect experience: * **Onboarding Contractors:** Collect passport scans along with confirmation of their understanding of company policies through a timestamped confirmation box. * **Gathering Client Information:** Request a website URL alongside a signed contract. * **Reference Checks:** Collect contact details and previous employers for references, along with a space for comments on the candidate's performance. **Zipwire Collect's manual entry options empower you to create comprehensive information requests, streamlining your data collection process and saving valuable time.** # Machine Vision We've already covered how Zipwire Collect simplifies document collection with powerful packs, but here's the real secret weapon: **Machine Learning.** **Effortless Uploads, Smarter Processing:** * **Machine Vision:** Zipwire Collect utilizes cutting-edge Machine Vision technology. When workers upload documents (even via WhatsApp!), Zipwire can analyze them to understand what they are (passport, driver's license, etc.). * **Large Language Models:** We don't stop at just identifying the document. Zipwire's Large Language Models extract key information from the document itself, like names, expiry dates, and ID numbers. * **Bulk Uploads Made Easy:** Need to upload a bunch of documents? No problem! Zipwire can handle bulk uploads from folders, letting us sort through everything at once. * **Pre-Filled Information:** Ever uploaded the same document twice? Zipwire Collect securely stores past documents, allowing us to pre-fill information for future collections. This means faster onboarding for repeat workers and less data entry for everyone.

Machine Vision has pulled out several details from this driving licence and noticed it has expired

**Faster Response Rates, Reduced Friction:** These Machine Learning features combine to create a smoother, faster onboarding experience: * **Reduced Back-and-Forth:** Zipwire figures out what documents are needed and extracts relevant information, minimizing the need for clarification or additional uploads. * **Faster Processing:** Bulk uploads and pre-filled information streamline the collection process, leading to quicker onboarding times. * **Improved Worker Experience:** A faster, more intuitive process creates a positive first impression for your contract staff. **Zipwire Collect leverages Machine Learning to make document collection a breeze, freeing you to focus on building a strong and compliant workforce.** # Failure to Recognise How to handle 'Unknown' documents. Upon upload, the AI will try to detect the kind of document and match it to an open collection. When using either the [Bulk Upload](/zipwire-collect/bulk-upload) feature or when sending via WhatsApp, Zipwire Collect relies on just the AI to determine what a file or photo contains. If it fails to recognise the doc, then it defaults to a type "Unknown" and will not be matched to a collection. ### Give it a hint When using the **Pick file** action for the item within a collection request on the **Open** tab, the AI will be told to expect a document of the type being asked for, like a hint. If it cannot determine it from looking at the image and text, Zipwire assumes the user has, for example, picked a passport file for the passport item. In other words, for tricky files, use the **Pick file** button on the collection itself. [What the Respondent Sees at Their End](/zipwire-collect/what-the-respondent-sees-at-their-end) # Document Types Zipwire Collect supports various documents and information from users for all kinds of purposes. The following are the different types of docs and information that can be collected. ## Files and Forms #### Uploading Files In many cases, documents are physical, especially when it comes to identity cards which must be designed to be hard to fake. Increasingly, documents are downloaded as PDFs, such as bank statements or phone bills. Zipwire Collect can deal with any of these kinds. When a respondent uploads a file, it is run through machine vision and then further AI processing to determine what kind of document it is. Zipwire Collect then looks at all the document types being sought in any open collection request and makes a match. {% hint style="info" %} Digital signatures on PDF files are not checked. This is simply because signed PDFs are still rarely used, unfortunately. Please reach out to our support team if you often check digitally signed PDFs. {% endhint %} #### Manually-entered Information Sometimes you simply need the user to enter information and there is no paper or file to upload. The most obvious example is the person's name and date-of-birth, and where they were born. This information is critical to uniquely identifying people in the world, but also as a record of who exactly the person is claiming to be. See [#form-based-information](#form-based-information "mention") at the bottom. ## File-based Documents The following documents are physical and can be digitised by scanning or photographing, or digital such as a PDF. #### Adoption Order An Adoption Order is a legal document that officially establishes an adoption. **Application Registration Card (ARC)** An Application Registration Card (ARC) is issued by the UK Home Office during the immigration application process. #### Bank Statement A bank statement is a document provided by a bank that shows the transactions and balance in a customer's account over a specific period. #### Birth Certificate A birth certificate is an official document that records a person's birth date, place of birth, and parents' names. #### Boarding Pass A boarding pass is a document, printed or digital, that permits a passenger to board a flight or other form of transport. #### Bridging Visa A Bridging Visa is a temporary visa that allows someone to remain in a country while their application is processed. #### Certificate of Incorporation A certificate of incorporation is a legal document that confirms the creation of a company and its registration with the appropriate government agency. #### Certificate of Name Change A certificate of name change is an official document that confirms a person's legal name change. #### Certificate of Change of Company Name A certificate of change of company name is an official document, issued by a companies registrar, that confirms a company's legal name change — distinct from a personal certificate of name change, above. #### Certificate of Insurance This is an umbrella term for various types of insurance certificates, including: * Certificate of Employer's Liability (EL) Insurance * Certificate of Professional Indemnity (PI) Insurance * Certificate of Public Liability (PL) Insurance #### Professional Certificates These are certifications issued to individuals who have met specific educational and/or professional requirements, such as: * Certificate of Public Accountant (CPA) * Certificate of Project Management Professional (PMP) * Certificate of Information Systems Security Professional (CISSP) * Certificate of Nursing Assistant (CNA) * Certificate of ScrumMaster (CSM) * Certificate of Human Resources Professional (CHRP) * Certificate of Six Sigma Green Belt (SSGB) * Certificate of Salesforce Administrator * Certificate of Ethical Hacker (CEH) * Certificate of Financial Planner (CFP) * Certificate of Professional in Healthcare Quality (CPHQ) * Certificate of Supply Chain Professional (CSCP) * Certificate of Information Systems Auditor (CISA) * Certificate of Medical Assistant (CMA) #### Certificate of ISO 27001 A Certificate of ISO 27001 is an official document confirming an organisation's certification against the ISO/IEC 27001 information security management standard. #### Claim Made Document A Claim Made Document may relate to an insurance claim or legal claim being made. #### Court Order Granting Name Change A court order granting name change is a legal document issued by a court that authorizes a person's name change. #### College/University Diploma A college or university diploma is an academic certificate awarded by an educational institution upon completion of a course or program of study. #### Council Tax Bill A council tax bill is a document that shows the amount of local government tax owed on a property. #### CV/Resume A curriculum vitae (CV) or resume is a document that provides an overview of a person's education, work experience, skills, and other relevant information. #### DBS Check Certificate A Disclosure and Barring Service (DBS) check certificate is a document that details an individual's criminal record history in the UK. #### Deed Poll A deed poll is a legal document that formalizes a person's name change. #### Divorce Decree A divorce decree is a legal document issued by a court that officially terminates a marriage. #### Driving License A driving license is an official document that authorizes an individual to operate a motor vehicle. #### Employment Authorization Document (EAD) An Employment Authorization Document permits non-citizens to work in the United States. #### EEA Biometric Residence Card (BRC) An EEA Biometric Residence Card (BRC) is an identification document issued by the UK Home Office to nationals of European Economic Area (EEA) countries and their family members who reside in the UK. It serves as proof of their right to live and work in the UK. The BRC contains the holder's biometric data (photograph and fingerprints) and other personal information, and is required for certain activities such as accessing benefits and services in the UK. #### Employment Contract An employment contract is a legal agreement between an employer and an employee that outlines the terms and conditions of employment. #### Energy Performance Certificate An energy performance certificate (EPC) rates how energy efficient a building is, and is typically required when a property is sold, let, or built. #### EU Settlement Scheme Certificate of Application This certificate is issued under the EU Settlement Scheme for EU citizens residing in the UK. #### Pre-Settled Status Confirmation A Pre-Settled Status Confirmation is issued under the EU Settlement Scheme, confirming an individual has been granted pre-settled status in the UK. #### Government Benefits Notice A notice or document related to government benefits or assistance programs. #### Immigration Authority Correspondence Correspondence from an immigration authority, such as a letter confirming the status or progress of an immigration application. #### Lease Agreement A lease agreement is a contract that outlines the terms and conditions for renting a property. #### Loan Document A loan document is a legal agreement that specifies the terms and conditions of a loan, such as the amount borrowed, interest rate, and repayment schedule. #### Marriage Certificate A marriage certificate is an official document that confirms the legal union of two individuals. #### Military ID A military ID is an identification card issued to members of the armed forces. #### Mobile Phone Bill A mobile phone bill is a document that details the charges and usage of a mobile phone service. #### National ID Card A national ID card is an official document that identifies a person as a citizen or resident of a particular country. #### National Entitlement Card NEC smart card A National Entitlement Card (NEC) is a smart card issued in the UK. #### Non-Disclosure Agreement (NDA) A non-disclosure agreement is a legal contract that prohibits the disclosure of confidential information. #### Notice of Change of Name A notice of change of name is an official document that informs relevant parties of a person's legal name change. #### Order Changing Name An order changing name is a legal document issued by a court that authorizes a person's name change. #### Passport A passport is an official document issued by a government that certifies the identity and nationality of an individual for the purpose of international travel. #### Payslip A payslip is a document that details an employee's compensation, including gross pay, deductions, and net pay, for a specific pay period. #### Power of Attorney A Power of Attorney is a legal document that authorises one person to act on behalf of another in legal or financial matters. #### Policies * **Information Security Policy:** Outlines rules and guidelines for protecting information assets. * **Information Security Procedure:** Detailed steps and processes for implementing information security measures. * **Data Privacy Policy:** Defines how personal data is collected, used, and protected. * **Data Protection Protocol:** Specific technical controls and processes for securing sensitive data. * **Code of Conduct:** Provides ethical standards and behavioral expectations for employees/partners. * **Ethics Policy:** Defines the organization's principles and values for ethical conduct. * **Anti-Corruption Policy:** Outlines rules and procedures to prevent corrupt practices like bribery. * **Anti-Bribery Policy:** Specific guidelines prohibiting the offering/acceptance of bribes. #### Professional License A professional license is a credential issued by a regulatory body that allows an individual to practice a particular profession or occupation. #### Proof of Citizenship Proof of citizenship is a document or set of documents that establish an individual's citizenship status in a country. #### Reference Letter A reference letter is a document that provides a written assessment of an individual's character, skills, or achievements, typically for employment or academic purposes. #### Rental Agreement A rental agreement is a contract between a landlord and a tenant that outlines the terms and conditions for renting a property. #### Sexual Health Screening Report A sexual health screening report is a document confirming the results of a sexual health screening. #### Social Security Card A social security card is an official document that displays an individual's social security number, which is used for various purposes, such as employment and taxation. #### Rental Tenancy Agreement A rental tenancy agreement is a contract that outlines the terms and conditions for renting a property, similar to a rental agreement. #### Tax Forms These are various forms related to taxation, including: * US 1099 tax form * US I-9 tax form * US W-2 tax form * US W-4 tax form * US W-9 tax form * UK PAYE (Pay As You Earn) form P45 * UK Starter Checklist (P46) #### Tax Notice A tax notice is a document issued by a tax authority that provides information or requests related to an individual's or business's tax obligations. #### Travel Documents * **Travel document:** Often issued to replace a passport that's been lost or stolen. * **Travel ticket:** A ticket for a flight, train, or other journey. * **Travel booking confirmation:** Confirmation of a booked trip, such as a flight or hotel reservation. #### Utility Bills These are bills for various utility services, such as: * Council tax bill * Electricity bill * Gas bill * Landline phone bill * Property tax bill * Water utility bill #### UK PASS Cards * YoungScot PASS accredited ID * CitizenCard PASS accredited ID * MyID PASS accredited ID * Post Office PASS accredited ID * IDGO PASS accredited ID * Totum PASS accredited ID * OneID4U PASS accredited ID #### UK Blue Badge Parking Permit A Blue Badge is a permit that allows holders to park closer to their destination in the UK. #### UK Biometric Residence Permit BRP A biometric residence permit (BRP) is an immigration document issued in the UK containing biometric information. #### VAT Registration Certificate A VAT (Value Added Tax) registration certificate is a document that confirms a business's registration for VAT purposes. #### Visa A visa is an official document that grants an individual permission to enter, stay, or work in a particular country. #### Immigration Status Document An immigration status document is an official document that confirms an individual's immigration status in a country. #### Work Permit A work permit is an official document that authorizes an individual to work in a particular country or jurisdiction. ## Form-based Information #### Identifying Details This type represents an individual's identifying information, such as their full name, date and place of birth. When carrying out formal checks, it is important to expressly collect who exactly the person claims to be. {% hint style="info" %} When your respondent creates an account and authenticates with a passkey or wallet, this form does not automatically pre-populate with any name information. The person must manually enter their identifying details, including their full name, date of birth, and place of birth. {% endhint %} #### Company Details This type represents a business's registered name, registration number, VAT number, registered address, and year/month of incorporation, if incorporated. #### Residence Details This type represents a person's primary home address, mailing address (if different from their home address), and country of residence. #### Tax Details This type represents a person's tax domicile and tax identification number - a National Insurance number, UTR, SSN, or equivalent for their tax domicile. #### Residential Address History This type represents a collection of information about an individual's previous residential addresses. #### Employment Reference History This type represents a collection of information about an individual's previous employment references. #### DBS Check Share Code A DBS (Disclosure and Barring Service) check share code is a code that allows an individual to share the results of their DBS check with a third party. #### URL This type represents a web address or URL. {% hint style="info" %} URLs could point to malicious websites. Zipwire Collect makes no attempt to check the website for malware and you should carefully inspect the URL before opening it. {% endhint %} #### Comment This type represents a text comment or note. #### Code This type represents a code or sequence of characters. These may be codes issued by a central body which can be entered into another system and checked. #### Confirmation This type represents a confirmation or acknowledgment of some kind. These explanations should help users understand the various types of nodes that the application handles. #### Yes or No Ask the respondent a question with either a Yes or No answer. This is especially useful when paired with some conditional logic. The UK Right to Rent built-in collection uses a Yes or No form to activate a pack of options for proving a recent name change. #### Emergency Contact A simple form asking for the name and contact number for a respondent's emergency contact or next of kin. ## Integrations There's only one and it's Yoti. Use this to conduct an ID check using NIST-certified selfie check and ID document validation. #### **Yoti ID check** Yoti is a digital identity platform, so this type represents a Yoti ID check or verification. ## Signable Documents Unlike the file-based documents above, which are simply collected and reviewed, a **Signable document** is a PDF that your respondent must review and cryptographically sign, such as a contract, policy acknowledgement, or agreement. Both parties end up with independent, tamper-proof proof of exactly what was signed. {% content-ref url="/pages/BqZQt9m3vA2DE6ka8j2I" %} [Signable Documents](/zipwire-collect/get-started/signable-documents) {% endcontent-ref %} {% content-ref url="/pages/vUtfq7RAFQoRHCuQ9GJA" %} [Sign It Once, Prove It Forever](/zipwire-collect/signable-documents-cryptographic-proof) {% endcontent-ref %} # Document Inspection This guide outlines how to use document inspections within the Zipwire Collect platform The inspection types allow for various levels of verification, from fully automated to in-person checks, ensuring compliance and security in document collection processes. ### Types of Document Inspections #### 1. **Fully Automated** * **Caption:** "Fully Automated" * **Description:** The system automatically verifies documents without human intervention. Ideal for digital documents where authenticity can be checked through software. * **Note:** This inspection type cannot be selected and is used by Zipwire internally for integrations like Yoti's ID checks service. #### 2. **Remote No Presence** * **Caption:** "Remote check of image or data" * **Respondent Advice:** "The requestor can accept an uploaded image or data." * **Description:** Documents are uploaded by the respondent and reviewed remotely by the requestor. No physical presence or video call is required. #### 3. **Remote Video Presence** * **Caption:** "Remote check of image or data during video call" * **Respondent Advice:** "The requestor can accept an uploaded image or data, and they'll verify your identity via a video call or in person." * **Description:** Similar to Remote No Presence, but includes a video call for identity verification. #### 4. **Physical No Presence** * **Caption:** "Physical check of document" * **Respondent Advice:** "The requestor can accept a physical document only, but you do not need to be present in person." * **Description:** Physical documents are mailed or delivered, but the respondent's presence is not required for verification. #### 5. **Physical Video Presence** * **Caption:** "Physical check of document during video call" * **Respondent Advice:** "The requestor can accept a physical document only, and they'll verify your identity via a video call or in person." * **Description:** Physical documents are checked, with identity verification conducted via video call. #### 6. **Physical Physical Presence** * **Caption:** "Physical check while its owner is present" * **Respondent Advice:** "The requestor can accept a physical document only, and they must verify your identity and presence in person." * **Description:** The most secure option where both the document and the respondent's identity are verified in person. ### Document Freshness Alongside the inspection type, each document item can have a freshness rule: how recent the document needs to be, and whether an expired document is acceptable at all. For example, a proof of address might need to be dated within the last three months, while a passport might be accepted right up to its printed expiry date but rejected afterwards. Machine Vision reads the dates printed on a document and checks them against this rule automatically, flagging the item if it falls short so the requestor can decide whether to accept it anyway. ### Hints for the Requestor Once the collection is open and receiving responses, the requestor will see a hint explaining how the document should be inspected. Here, the document will need to be physically in the hands of the requestor and checked while the document holder, your respondent, is on a video call or present in person. The requestor can then take a photo of it as retained evidence and upload it to the collection. The requestor will not have access to files uploaded by the requestor.

A document item still to do, in an open collection, as seen by the requestor.

### Tips for Effective Use * **Security vs. Convenience:** Balance the need for security with the convenience for both the respondent and the requestor. * **Legal Compliance:** Ensure that the chosen inspection type complies with any legal or regulatory requirements pertinent to document verification. * **User Experience:** Consider the impact on user experience. More stringent checks might deter respondents unless necessary. ### Troubleshooting Common Issues * **Document Rejection:** If documents are frequently rejected, review the clarity of instructions or consider if the inspection type is too stringent for the document type. * **Technical Glitches:** Ensure all systems involved in video calls or document uploads are functioning correctly. ### Conclusion By understanding and properly configuring document inspections in Zipwire Collect, you can streamline your document collection process while maintaining necessary security and compliance standards. This guide should help in setting up an efficient and secure document verification system tailored to your specific needs. # What the Respondent Sees at Their End We recommend you send a collection to a colleague first so you know what to expect. However, here's what the collection experience looks like to them. ## Flat Structure When you're designing your collection, you may have used packs to group documents together or put rules around how many documents are needed, "collect any two of these four types". Your respondent doesn't see this "tree of nested packs" but instead a single list of all the documents and forms they need to send. We try to collect your preferred documents first. **Once you open the collection, it'll flatten out and you'll see it, more or less, as it appears to your respondent.** If a pack is configured to collect a subset of the documents, i.e. "any two of..." then once the respondent has satisfied this requirement, all the other documents (no longer needed) will vanish. If the same document type is collected twice, then they will need to send it twice, once on each item, however it is not possible to collect more than one file per item. For example, you cannot collect the front and back photos of a passport within a single passport item. Instead you'd need to create an item for the front and another for the back. ### Conditionals Since documents and packs can be contingent on information in another document, the respondent may find that submitting a document results in many items suddenly vanishing and no longer being needed. The opposite is true, that the submission of a document may "switch on" the need to send a bunch of other information. ## WhatsApp If the requestor provided the respondent's mobile number when setting up the relationship, the respondent doesn't have to log into Zipwire at all to take part - the whole thing can play out over WhatsApp. They'll get a WhatsApp message when the collection is opened, telling them what's being asked for, and further nudge messages if items are still outstanding. They can reply straight from WhatsApp: sending a photo of a document works just like an upload, and Machine Vision processes it the same way it would a file picked from the **Open** tab. {% hint style="info" %} No mobile number, no WhatsApp. If the requestor didn't supply one, the respondent will only see the collection by logging into Zipwire directly. {% endhint %} ## Screenshots! A picture paints a thousands words, so here are some examples: ### Collections are flattened This image shows the respondent's view of a collection with four packs, Proof of Address, UK Right to Work, Company Formation and Company Insurances. It also collects their residential address history and employment reference history, defined in the "root" collection. When you're configuring your collection, a pack is represented as a single item that you can drill down into, like a folder. But once the collection is open, all relevant items in the collection are shown in one long list.

An open complex onboarding collection as seen by the respondent.

Further down this demo page Zipwire Collect has noticed that the respondent already has a passport in storage, held on file as it were, so it draws attention by offering it up with a **Send** button.

Further down the same collection the Passport item has picked up a passport held in storage.

This helps speed up response rates and is especially useful if your respondent has used Zipwire before. *** ### Pack headings and shading Items within a pack will be preceded by their pack name and description and a block of shading helps visually distinguish the pack.

Taken from the UK Right to Rent built-in template collection, see the shading and pack details

### Requestor's view The following shows the requestor's view of a collection named Proof of Address. In this case a reusable Proof of Address pack was used as a template for the whole collection. {% hint style="info" %} **Requestor Upload** Both the respondent *and the requestor* can pick files to upload. If requestor already has some of the requested files, perhaps in email attachments, they can upload them to keep everything together. When the collection is opened, Zipwire will look in both the respondent's and the requestor's workplace store to see if a suitable document is already present. Note that for some items that need a physical inspection, only the requestor can upload the evidence, since the respondent will be expected to post or take the document to the requestor in person. {% endhint %}

An open Proof of Address collection as by the requestor with Pick file buttons.

### Physically-inspected items When configuring your collection, you can choose how it should be inspected and Zipwire Collect will guide the respondent appropriately.

Evidence that needs physically checking will not have an option to upload.

### Optional items The following is what an optional item looks like to the respondent. They will usually see a **Not applicable** button but sometimes it will be labeled **Skip**.

An optional item with Pick file and Skip buttons

The requestor can make an item optional after the collection has been opened. ### Forms Forms appear slightly different depending on what is being collected - this should give you a feel. The respondent has **Add**, **Remove** and **Send** buttons.

The respondent's view of the address history form

### After sending For the respondent, sent items are removed from the **Open** view and become visible over on the **Done** view. To be clear, the same open collection can be visible on both the Open and Done tabs. The sender's (respondent's) view is pretty boring and simply has a little label on the item to say when it was sent.

Boring little label.

#### Requestors view of received items The requestor will clearly see when an item has been sent to them for review. They'll see a set of controls like this. Lovely.

The requestor's view of an item they've been sent, with controls for accepting and rejecting

### And there you have it We'd love your feedback. If you have a good idea for a form, or if you think the experience falls short somehow or could be improved, please reach out. Thing's we're working on: * There's currently no viewer for the files you've been sent. You need to download them locally onto your machine to see them properly. Some folks must not store sensitive data on their devices and so this could be a problem for those users. * New forms. In particular, links to other websites and services. For example, to have the user go to a website to start background checks. This could be a button to open that website which then tracks that they have clicked it. # UK Right to Rent Template This page explains Zipwire Collect's built-in UK Right to Rent template, designed to streamline landlord compliance with UK rental legislation through automated document collection and conditional l ### Streamlined Compliance for UK Landlords The UK Right to Rent template is a comprehensive, built-in collection designed to help landlords and letting agents comply with UK rental legislation efficiently. This sophisticated template automatically adapts to collect the correct documents based on a tenant's citizenship and circumstances, ensuring you gather all necessary evidence while minimizing friction for your prospective tenants. **Why Use the Right to Rent Template?** * **Legal Compliance:** Ensures you collect all documents required under UK Right to Rent legislation * **Conditional Logic:** Automatically requests relevant documents based on citizenship and previous name status * **Yoti Integration:** Leverages government-approved digital ID verification where possible * **Comprehensive Coverage:** Handles all scenarios from unlimited rights to time-limited permissions * **Reduced Errors:** Eliminates guesswork about which documents to collect from different tenant types ### Understanding Right to Rent Requirements UK landlords are legally required to verify that all tenants aged 18 and over have the right to rent property in the UK. Right to Rent (RTR) rules are actually more complex than Right to Work (RTW) rules because they accommodate a wider range of situations and documentation types. The complexity arises from the need to verify eligibility for a diverse group of people, including: * **UK and Irish citizens** with unlimited RTR, who can use documents like passports or birth certificates * **Citizens from the EU, EEA, or Switzerland** with settled or pre-settled status, who might use share codes or other documents * **Non-EEA nationals** with time-limited RTR, who must provide documents like visas or residence permits **Unlimited Right to Rent:** British and Irish citizens typically have unlimited right to rent and need straightforward identity verification. **Time-Limited Right to Rent:** Non-UK/Irish citizens may have time-limited permissions that require more complex documentation, including visa status and entry stamps. **Name Changes:** Tenants who have changed their name must provide additional evidence of legal name changes. The accommodating nature of RTR rules leads to numerous scenarios and document requirements, making it challenging for landlords to ensure they collect all necessary and correct documents - which is exactly where Zipwire Collect's sophisticated template system excels. ### How the Template Works The Right to Rent template uses Zipwire Collect's powerful conditional logic to create a dynamic collection that adapts to each tenant's specific situation: #### 1. **Identity Collection** Every tenant provides basic identifying information through a secure form, establishing their claimed identity. #### 2. **Name Change Detection** A simple yes/no question determines if any documents will be in a previous name, triggering additional requirements if needed. #### 3. **Citizenship-Based Routing** Based on citizenship information, the template automatically activates the appropriate document collection path: * **UK/Irish citizens:** Streamlined unlimited right to rent verification * **Other nationalities:** Time-limited right to rent documentation #### 4. **Smart Document Collection** The template prioritizes digital verification through Yoti where possible, falling back to manual document upload when needed. #### 5. **Cascading Completions** One of the most elegant features is how pack completions cascade upward. When a tenant completes a document requirement, it can automatically complete the pack it's within, which may complete the pack above it, and so on. This means that for most UK passport holders, the experience is remarkably simple: enter personal details, complete a Yoti ID check, and they're done - despite the underlying complexity of the collection structure. ### Template Structure The following diagram shows the complete structure of the UK Right to Rent template: ``` UK Right To Rent Pack (f2se) ├── 📋 Claimed Identity (z9bt) [REQUIRED] │ └── Form: Personal details for identification │ ├── ❓ Previous Name Documents? (0pb8) [REQUIRED] │ └── Yes/No: Are any documents in previous name? │ ├── 📑 Proof of Legal Name Change (jwlo) [CONDITIONAL: if previous name = yes] │ ├── Certificate of Name Change (5l2x) │ ├── Court Order Granting Name Change (g34p) │ ├── Divorce Decree (an5f) │ ├── Marriage Certificate (vq3w) │ └── Deed Poll (bxzv) │ └── [Constraint: At least 1 required] │ └── 🏠 Right to Rent Evidence Pack (uljh) [REQUIRED] │ ├── 🇬🇧 Unlimited Right to Rent (dawn) [IF citizenship = IE/GB] │ ├── 🤖 Yoti ID Check - Passport (9lxe) [PREFERRED, SKIPPABLE] │ └── 📄 No IE/GB Passport Alternatives (jutl) [IF Yoti rejected/skipped] │ ├── Birth Certificate (6x3k) │ ├── Certificate of Naturalisation (cd8q) │ ├── Emergency Travel Document (0u3w) │ ├── EU Settlement Scheme CoA (dcby) │ ├── UK Visas Share Code (34cq) │ ├── Swiss SPS Visa (s7w2) │ └── Immigration Correspondence (uscz) │ └── [Constraint: At least 1 required] │ └── ⏰ Time-Limited Right to Rent (4hvo) [IF citizenship ≠ IE/GB] │ ├── 🌍 EEA Time-Limited Pack (jt20) [IF citizenship = AU/JP/NZ/SG/SK/US] │ ├── 🤖 Yoti ID Check (xiw7) [PREFERRED, SKIPPABLE] │ └── 📋 EEA Permission Evidence (4hit) [IF Yoti rejected/skipped] │ ├── 📖 Passport/ETD Pack (zfrn) │ │ ├── Stamped Passport Pack (9snw) │ │ │ ├── Passport ID Page (s497) │ │ │ └── Passport Stamp Page (9sm1) │ │ └── Emergency Travel Document (n3ks) │ └── ✈️ EEA Travel Evidence Pack (qkes) │ ├── Boarding Pass (nc8t) │ ├── Travel Ticket (7hc8) │ └── Travel Booking Confirmation (ritl) │ └── [Constraint: At least 1 required] │ └── 🌐 Standard Time-Limited Pack (95us) [IF citizenship ≠ AU/JP/NZ/SG/SK/US] ├── 🤖 Yoti ID Check (z915) [PREFERRED, SKIPPABLE] └── 📋 Standard Permission Evidence (s2wz) ├── 📖 Passport/Travel Doc Pack (dn11) │ ├── Stamped Passport Evidence (89d2) │ │ ├── Passport ID Page (nk12) │ │ └── Passport Stamp Page (pv41) │ └── Emergency Travel Document (bswu) └── 🏛️ Immigration Status Evidence (3sot) ├── UK Visas Share Code (qmri) [PREFERRED] ├── EUSS CoA (uoew) └── Other EUSS Proof (ye23) └── [Constraint: At least 1 required] ``` ### Worked Example: A Tenant Who Has Changed Their Name Here's the template in action, starting with the tenant's (respondent's) view: two forms to complete, one for their claimed identity and one asking whether any of their documents are in a previous name.

The tenant's view of the UK Right To Rent collection, starting with two forms to complete.

The tenant says "Yes", they do have some documents still in their old name.

The tenant chooses Yes

A couple of seconds later, a new pack appears advising the tenant of their options for proving their name change - this is the **Proof of Legal Name Change** pack from the template diagram above, which only triggers when the answer to the previous question is "Yes".

Underneath the Claimed Identity form, the Proof of Legal Name Change pack has appeared.

Depending on why their name changed, the tenant now has a range of documents they can use to evidence the discrepancy. Note that these particular items are set to require manual inspection (see the **Info** panel), which is a setting configured per document, and the tenant is advised accordingly. #### The landlord's view Here's what the landlord (requestor) sees for the same tenant.

The landlord sees the tenant's answer to the question, as well as the pack for collecting evidence of the name change.

Since the landlord will need to inspect and retain copies of any evidence, they're able to pick a file to upload themselves using **Pick file** - useful if the tenant has already emailed over a scan, for example. The **Not applicable** option lets either party skip an item, though it isn't needed here since the pack only requires any one of the listed documents: as soon as one file is uploaded and accepted, the pack is complete and disappears from view. ### Key Benefits for Landlords **Simplified Process:** No need to research what documents each tenant type requires - the template handles the complexity automatically. **Reduced Liability:** Comprehensive documentation collection helps demonstrate due diligence in compliance checks. **Faster Onboarding:** Digital-first approach through Yoti reduces time spent on manual document review. **Better Record Keeping:** All documents are securely stored with timestamps and approval status for audit purposes. **Tenant-Friendly:** Clear instructions and conditional logic mean tenants only see relevant requests, improving completion rates. **Streamlined Experience:** Despite the complex underlying structure, most UK/Irish passport holders will only need to complete identity details and a single Yoti check, thanks to the cascading completion system. ### Getting Started with the Template To use the UK Right to Rent template: 1. **Create a new collection** in Zipwire Collect 2. **Select the UK Right to Rent template** from the available options 3. **Customize if needed** - add additional workplace-specific requirements 4. **Send to your prospective tenant** - they'll receive clear instructions via email and WhatsApp The template will automatically guide your tenant through the appropriate document collection path based on their responses, ensuring you receive everything needed for compliance while providing a smooth experience for all parties. {% hint style="info" %} **Digital Verification First** The template prioritizes Yoti digital ID checks where possible, as these provide the strongest verification while being most convenient for tenants. When Yoti verification isn't available or is declined, the template automatically falls back to traditional document collection. {% endhint %} {% content-ref url="/pages/ttk1fairMQDU8kw8OlJB" %} [Using Packs](/zipwire-collect/using-packs) {% endcontent-ref %} {% content-ref url="/pages/rMDgWHH8xcgbnwYtrI5V" %} [Selfie Checks Powered by Yoti](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml/selfie-checks-powered-by-yoti) {% endcontent-ref %} ### Reviewing Checks with Claude Yoti's checks confirm a document is genuine and that the face matches it—they can't confirm the document belongs to the person who submitted it. If you connect Zipwire's [MCP server](/use-cases/for-agents/zipwire-mcp-server) to Claude Desktop, Claude can read a Right to Rent collection's ID check results alongside the tenant's claimed identity and catch a mismatch between the two, even when every individual Yoti check has passed. {% content-ref url="/pages/brlssJFr9rwV3o49Wbf9" %} [Using Zipwire with Claude](/use-cases/for-agents/using-claude) {% endcontent-ref %} ### Further Reading For a detailed technical breakdown of how the UK Right to Rent template handles complex conditional logic and nested pack structures, see our comprehensive blog post: [Simplifying Right to Rent Checks with Zipwire Collect](https://zipwire.io/blog/articles/2024-07/ukrtr/using-zipwire-collect-uk-right-to-rent-checks). This in-depth article explains the hierarchical document requirements, cascading completions, and how the template transforms complex government guidance into a streamlined user experience. # Bulk Upload Here we explain bulk uploading, which aims to save time and effort for your respondent and hopefully increase the speed in which they fulfil your request. ## Pick many! Respondent can pick a load of files to send and we'll figure out what they are and whether they match something that's being collected. On the **Docs** tab, where all there stored docs can be seen, they can hit **Pick files** to get the typical chooser for their operating system. They can select more than one file to upload. All the files will begin uploading and being processed by our Machine Vision system. This can take a while but it is better than picking and uploading one-by-one on the **Open** tab. In the image below, you can see a passport that has been uploaded and processed and has been found to match the passport being sought in a collection request.
### We'll get you next time! If your respondent keeps all their files uploaded and stored in Zipwire, the next time you send them a document request, we'll automatically inspect these files and find matching documents, so they don't have to keep uploading the same stuff. So if they've ever used Zipwire Collect with you or another business and have their docs already in storage with us, then it'll be quicker for them - and for you! Seasoned freelancers are likely to have most of their documentation readily available. # Creating a Collection with AI We've introduce a new feature to create collections using natural language understanding. This feature is experimental and although it's clever, we'd love to know if you find it genuinely useful. ## Creating and Designing Collections Manually We recommend you play around with making collections manually before using the AI feature. Get used to adding and removing documents, [creating packs](/zipwire-collect/using-packs), renaming packs and saving them as templates you can use again and again. Creating a document collection can be very simple when you only have a few items you need from someone. If you use document collection often, you may have designed some reusable packs of documents, such as the docs you need for Proof of Address. Artificial intelligence is able to understand complex instructions and put together an advanced document collection for you. However, it makes mistakes and these could go unnoticed. Checking each item is configured properly and fixing errors may cost more time than it would to make it yourself, so we're really interested to see if you think this use of AI is a time-saver or overkill. {% hint style="info" %} We **strongly** advise that you check every pack, its name and description, whether its set to collect all or just some of the documents, then check each document item is setup properly. {% endhint %} ## Using AI to Create Collections You simply describe what you want to collect in the large box and hit Create. It will take up to 90 seconds to return its collection. It will not use any of your packs though it will use the name you've supplied, else it'll make up its own one.

The create new collection screen for Jack Frost showing where you describe your collection

### What does a good description look like? The most simple can be something like: * "just a passport" * "their passport and driver's license" * "a UK biometric residence permit" * "Their certificate of Nursing Assistant CNA" * "A link to their profile on the Association of Super Heros and People with Special Powers and a valid driving licence" * "Their passport and if it's foreign, then we'll need to collect their visa" {% hint style="info" %} **Conditions** Items in a collection can be configured so that they are only required depending on some information in another document. At the moment we only support the country of issuance, which means you can require a document (or whole pack) only when they have a passport from a certain country. {% endhint %} ### What does an advanced description look like? The following is an example of a lengthy and complex description for a UK staffing agency. This has been nicely formatted and structured, but you might be surprised by what it can cope with, so if you have some existing process or an email you want to paste in, then go ahead. Copy and paste this whole chunk in and give it a whirl: *** **Company Documents:** * Incorporation Certificate (Ltd company) or Umbrella company documents * Insurance Certificates, PI and PL * VAT Certificate (if applicable) **Right to Work Verification:** * **Non-UK Passport:** The contractor creates a share code using this link: Prove your right to work to an employer - GOV.UK: link to government website to allow us to verify their status online. * **UK Passport:** We use an ID verification service. We'll send you an email where you can upload a selfie and passport photo. We typically receive a confirmation certificate within 1 day. **Additional Verifications (ABC Corp Roles):** * **ABC Check (In-house):** This requires: * Passport copy * 2 proofs of address (recent utility bill, bank statement, council tax bill, driving license) * DBS check (within 3 months) * 5 years address history * 3 years references *** ### Experimental descriptions Because the AI backing this feature is all knowing, it can even be told to collect documents for compliance with a particular jurisdiction. The collections it comes up with may or **may not** be compliant, but it will try its best and can be quite fun to explore. * "I am taking on a contractor in Texas and I need to be compliant with Texas state and federal laws" {% hint style="info" %} **Compliance** To be clear: the language model is very clever and plausible but this does not mean it is creating collections which are actually legally compliant. It is on you to know what documents you need to collect and keep for where you're operating. {% endhint %} # Sign It Once, Prove It Forever Sign a contract, policy acknowledgement, or agreement inside Zipwire Collect and walk away with cryptographic proof that doesn't depend on Zipwire sticking around to back it up. [**Get started with Zipwire Collect →**](https://zipwire.io/collect) Every e-signature tool you've used runs on the same quiet promise: "trust us to remember what happened." Sign a contract in a typical e-sign platform and what you actually get is a certificate of completion — a document that says a signature took place, backed by nothing more than the vendor's servers and their willingness to keep answering queries about it. Most of the time nobody asks. But when a signature actually matters — a dispute, an audit, a court date years later — that's exactly when you don't want your proof to depend on a company's servers still existing, still holding your records, and still willing to answer the phone. **Signable Documents** sidestep that entirely. Attach a PDF to a Zipwire Collect request, have your respondent review and sign it, and both of you end up holding independent cryptographic proof of exactly what was signed — proof that stands on its own, verifiable without ever contacting Zipwire again. ## Sign once each, in order A Signable Document is actually signed twice: 1. **You sign first, as the requestor**, the moment you attach the PDF. This locks in the exact bytes of the file you're sending — before your respondent ever sees it — so there's no question later about which version was in play. 2. **Your respondent signs second**, after reviewing the document in a dedicated viewer. Their signature references yours, chaining the two together. Both signatures are backed by a Merkle tree built from the document's contents and attested on-chain, so the proof isn't a claim Zipwire makes about you — it's something you can hand to anyone and they can check for themselves. ## Nobody needs a crypto wallet to get this Every attestation is made from Zipwire's own wallet — that's true whether or not you have one. What changes is who it's addressed to: if you or your respondent already have a wallet linked, the attestation names that wallet as recipient, at no cost and no extra step for you. If you don't have one, Zipwire addresses the attestation to itself instead, witnessing the signature on your behalf. Either way, the tamper-evidence is identical: the proof that this exact document was signed at this exact time doesn't change. A linked wallet only strengthens the claim about *whose* proof it is — it's never required just to get the benefit. {% hint style="info" %} **Coming soon:** we're working on letting a wallet holder sign the attestation themselves, directly from their own wallet, rather than Zipwire signing on their behalf. That adds a small amount of friction and a tiny gas cost for the signer, in exchange for the strongest possible identity guarantee — a third party can later challenge them to prove they control that wallet. {% endhint %} ## Your signature doesn't stand alone If your respondent has already completed an ID check, `IsAHuman`, or an AML check with Zipwire, their signature doesn't arrive as an isolated claim. It automatically cross-references whatever identity evidence they already hold on-chain, so a verifier doesn't just see "this wallet signed this document" — they see a trail of independently checkable attestations backing up who that wallet belongs to. {% hint style="info" %} **Want the strongest possible proof?** Run an ID check on your respondent *before* they sign. Zipwire ranks a completed ID check above every other kind of evidence when choosing what to cross-reference — it's the single strongest thing you can add to a signature's credibility. {% endhint %} {% content-ref url="/pages/mohdewNdaWrgQQiCYViI" %} [Signer Identity Cross-Referencing](/fundamentals/security/attestations/signer-identity-cross-referencing) {% endcontent-ref %} ## We didn't even need to build our own verifier To prove the proof holds up, we handed a raw Zipwire proof file to Grok — a general-purpose AI with no Zipwire-specific tooling — and asked it to work out what the file meant.
Grok decoding a raw Zipwire ProofPack, correctly identifying the signer, role, timestamp and Merkle root

Grok, with no Zipwire integration whatsoever, cold-reading a signed document proof and getting every detail right.

It correctly identified the signer, their role, the timestamp, and the Merkle root behind the signature — cold, with nothing but the file itself. That's what it means for a proof to be self-describing: it explains itself to something that has never heard of Zipwire. (The file itself is a [ProofPack](/fundamentals/security/understanding-proofpack) — see that page for what's actually inside one.) ## Prove one clause, not the whole document The tree behind your respondent's signature is built one leaf per paragraph, not one hash for the whole file. That matters the moment a dispute is actually about a single clause — a liability cap, a payment term — rather than the entire agreement.
The Proofs tab generating a proof file that only covers paragraph_1 and the signer, not the whole document

A proof generated for a single paragraph, straight from the Proofs tab — not the whole contract.

From the **Proofs** tab, you can already select just the paragraph in question, plus the signer details, and generate a proof file that covers only that. Hand it, and the paragraph text, to whoever's asking — a court, an auditor, a counterparty's lawyer — and they can verify it against the on-chain Merkle root without ever seeing the rest of the document, using [zipwire.io/verify-proof](https://zipwire.io/verify-proof) or their own tooling. ## Why this is worth switching for * **Your proof outlives us.** It isn't stuck inside a Zipwire silo — it survives Zipwire being unavailable, discontinued, or simply not trusted by whoever's asking. * **Lower disclosure risk in disputes.** Share one fact rather than an entire contract. * **No adoption cliff.** A wallet is entirely optional — you get the full integrity guarantee with or without one. * **No one can quietly rewrite history.** Both signatures are cross-copied so each party independently holds both proofs — there's no single admin panel, ours or anyone else's, where the record could be edited. ## Where it fits Anywhere a traditional e-signature flow currently sits: freelancers and agencies signing service agreements, landlords and tenants signing tenancy documents, any two parties who need to agree to a document and might, one day, need to prove it independently of whichever platform hosted the click. {% hint style="warning" %} **Not a substitute for notarisation.** Signable Documents give you strong, independently verifiable evidence that a specific document was reviewed and attested to by a specific party at a specific time. A [notary](https://en.wikipedia.org/wiki/Notary) is a specific, licensed legal officer appointed under a jurisdiction's own laws — not just "someone who witnesses a signature." Zipwire is not a notary, does not assess anyone's legal capacity to sign, and does not provide legal advice. Whether a document needs formal notarisation, witnessing, or legal review depends on its jurisdiction and purpose — that's a question for your own legal counsel. {% endhint %} ## Read more {% content-ref url="/pages/BqZQt9m3vA2DE6ka8j2I" %} [Signable Documents](/zipwire-collect/get-started/signable-documents) {% endcontent-ref %} {% content-ref url="/pages/K4BLwRNETrUKpdJuaJRC" %} [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) {% endcontent-ref %} {% content-ref url="/pages/HR6HCv993tyVfhflqWFi" %} [Data Portability and Proofs](/overview/data-portability-and-proofs) {% endcontent-ref %} # IDSP, IDVT, KYC, KYB and AML If you've ever been involved in hiring people or starting a new business relationship, then you'll be familiar with this array of acronyms. We'll touch on each and how Zipwire Collect can help. ### IDSP - Identity Service Provider (UK) An IDSP is any business who provides ID checking services. In 2022, the UK government mandated that when employing someone, digital ID checks should be performed by an authorised Identity Service Provider and has published [this list](https://www.gov.uk/government/publications/digital-identity-certification-for-right-to-work-right-to-rent-and-criminal-record-checks/digital-identity-certification-for-right-to-work-right-to-rent-and-criminal-record-checks) of providers. Here's the relevant passage from the gov.uk guidelines: > IDSPs can carry out digital identity verification to a range of standards or levels of confidence. The Home Office recommends that employers only accept checks via an IDSP that satisfy a minimum of a Medium Level of Confidence. A list of certified providers is available for you to choose from on GOV.UK: Digital identity certification for right to work, right to rent and criminal record checks. **It is not mandatory for you to use a certified provider**: you may use a provider not featured within this list if you are satisfied that they are able to provide the required checks. Although it is not mandatory, many employers will want the reassurance of using an authorised IDSP which is why Zipwire Collect is integrated with [Yoti](https://www.yoti.com/about/), the first IDSP to be authorised in the UK. That brings us nicely onto our next acronym. ### IDVT - Identity Document Verification Technology This simply means technology that can check a document is legit. You've probably used this sort of thing in an airport recently, but the technology also works on mobile phones. Yoti uses National Institute of Standards and Technology (NIST) certified "selfie" technology and machine learning models to verify photos of ID documents. You use your mobile phone to take a selfie and snap a photo of your ID doc, and this kind of IDVT is why some banks no longer require people to come into a branch to open an account - indeed banks like Monzo are mobile app only. ### KYC - Know Your Customer This is a fairly well-known acronym in business, especially in finance. It embodies the best practices and law around conducting due diligence on who you are doing business with. Zipwire Collect helps with collecting information from people, in addition to performing ID checks, and comes in useful whenever there's a need to collect, check and keep on record evidence of these checks as well as demonstrate having a system in place. KYB standards for Know Your Business and is focused on checking a corporate entity. ### AML - Anti Money Laundering Organised crime generates a lot of money which must be disguised as having come from legitimate commercial endeavour. KYC is a crucial first step in reducing money laundering and key to both preventing money laundering in the first place and keeping a paper-trail of illicit activity for subsequent investigation. As part of tackling crime and avoiding the tough penalties of handling the proceeds of crime, institutions around the world operate information sharing networks. Through its use of Yoti, Zipwire can conduct AML background checks on individuals, looking at sanctions lists, Politically Exposed Persons (PEPs) and adverse media. {% hint style="info" %} We're also interested to see whether *ongoing* checks would be useful for customers, i.e. alerts, and whether deep AML probes are needed. Please get in touch. {% endhint %} *** **Hit this link to get in touch ->** [Contact us](https://zipwire.io/contact-us?trackingCode=docs-feature-request) *** # Selfie Checks Powered by Yoti Introducing our trusted IDSP and technology provider, Yoti. Zipwire has selected Yoti, a leading identity verification provider, to offer secure and accurate "Selfie Checks" as part of our identity verification process. Yoti's industry-leading liveness detection technology helps prevent fraud and ensures you are dealing with a real person during verification.

A young man captures a selfie using his mobile phone.

### Defeating Spoof Attacks with Liveness Detection Liveness detection is a critical component of identity verification to protect against spoofing attacks where someone attempts to bypass checks using a photo, video, mask or other artifact. Yoti's MyFace liveness solution achieves NIST Level 2 certification with 100% attack detection against: * Paper photos * Masks * Screen photos/videos * Deepfake videos * Injection attacks * Bot attacks Yoti's passive liveness approach analyses many cues and subtle traits to validate the presence of a live human without requiring explicit user actions. ### Unbiased and Inclusive Yoti's liveness technology minimizes demographic bias related to age, gender, and skin tone to ensure a fair and accurate verification experience for all users. ### How It Works During a Selfie Check, your respondent is prompted to capture a live selfie video. Yoti will analyze this video using advanced AI to validate liveness and match their selfie to an ID document that is also captured. Optionally, AML checks can be conducted on the respondent. All processing happens seamlessly in the background and a detailed report with recommendations is made available in Zipwire Collect. For more details on Yoti's liveness detection capabilities, refer to [their whitepaper](https://www.yoti.com/blog/yoti-myface-liveness-white-paper/) on liveness detection. By partnering with Yoti, Zipwire can confidently verify a person's identity while preventing fraudulent spoofing attempts - protecting both you and our platform. {% embed url="" %}
# Blockchain Attestations At Zipwire we believe that cryptographic blockchain technology will gradually supplant traditional siloed systems. We're interested in exploring identity, trust, reassurance and blockchain. The financial industry, including money transfer services, identity management, and commerce platforms, are exploring how blockchain and Distributed Ledger Technology (DLT) can address current challenges. These technologies have the potential to upgrade financial infrastructure, improve security and efficiency, and ultimately deliver a better experience for users. ### Rubber Stamp Attestations are a way to imprint information and facts about an entity on the blockchain. You can view an attestation as a kind of rubber stamp – a seal of approval or signing of a document Cryptographic algorithms provide tamper resistance and non-repudiation, i.e. the rubber stamp is not a fake and cannot have been issued by anyone other the controller of the secret key. In our everyday lives, people, products and businesses gain our confidence through networks of credibility. For example, a company has verified the identity of a person (rubber stamp). And that company is an approved IDSP and appears on [a list on a website](https://www.gov.uk/government/publications/digital-identity-certification-for-right-to-work-right-to-rent-and-criminal-record-checks/digital-identity-certification-for-right-to-work-right-to-rent-and-criminal-record-checks) operated by the government (rubber stamp). The website has padlock in the browser and a HTTPS certificate which can be inspected (rubber stamp). To get a certificate, the website owner had to prove its identity to a certificate authority (rubber stamp) and the documents it provided were issued by other authorities, and so on. We rely on various digital signals of varying strengths that combine to engender trust. Blockchain attestations seek to replicate this criss-crossing system of trust using strong cryptographic data. ### An example You may gather information from a person to check their identity and background, their insurances etc. and their company incorporation. You may send information off to other service providers to get further assurances. Once done, you could put a rubber stamp in this person's wallet on a blockchain to say that you're sure they're a real human; you've checked their identity and possess some useful facts about them. This would help them accumulate attestations in their wallet which they can present elsewhere, to demonstrate eligibility. Your own business wallet could accumulate attestations, too, from other businesses, your bank or from credit agencies or even a reciprocating attestation from your workers, all of which would give your business credibility and authority. It would also lend credence to every attestation you make. Over time, a web of attestations would build-up making it much easier to determine good actors on the blockchain and in business generally and our daily lives. ### Privacy An attestation is signed and imprinted on a public blockchain but the data is usually held privately with only a cryptographic proof available for scrutiny. The proof itself is a garble of pseudorandom binary revealing nothing by itself. The original data is either handed back to the end user like a receipt or held securely on file on their behalf. The time of the attestation is incontestable and the facts can be proven to be true by checking the proof against the actual data. Using cryptography it's possible to reveal and prove just one fact, keeping the other data private. For example, a person may prove they're over 18 by presenting their blockchain wallet and a proof issued by Zipwire of their checked passport data, revealing only their date of birth. This complexity would be designed into future products, similar to how your web browser guarantees the certificate of this website and encrypts its data without you having to think about it. In general, such technology would engender strong trust while alleviating the burden on performing checks. ### **Does this sound interesting?** We're excited about attestations and how Distributed Ledger Technology will shape the future. We think attestations will form a critical part of compliance in years to come but recognise that this will take a while to build - the earlier we start, the better for everyone. To bring about a better tomorrow we need to give your business and your customers the right, easy-to-use tools, today. ## Getting Started with Attestations ### For Businesses Use Zipwire Collect to include ID checks in your document collections. When users connect their wallets, they can claim free attestations to their wallets. ### For Individuals {% content-ref url="/pages/kzmdzG6x7y91vzCPFJMX" %} [Your Digital Identity on the Blockchain](/zipwire-attest/zipwire-attest) {% endcontent-ref %} Get your own blockchain attestations through our self-service platform. Register independently, connect your wallet, and complete government-approved ID verification to receive IsAHuman and Private Data attestations. # Your Digital Identity on the Blockchain Zipwire Attest is a self-service platform where individuals can register, connect their Ethereum wallet, and get blockchain attestations for their identity and documents. [**Get started with Zipwire Attest →**](https://zipwire.io/attest) ## Your Digital Identity on the Blockchain Zipwire Attest is a self-service platform that puts you in control of your digital identity. Register, connect your Ethereum wallet, and get blockchain attestations that prove who you are without compromising your privacy. ## What is Zipwire Attest? Zipwire Attest allows individuals to: * **Register independently** - No business account required * **Connect your Ethereum wallet** - Receive attestations directly to your wallet * **Complete ID verification** - Government-approved identity checks * **Get blockchain attestations** - Proof of Personhood and document attestations * **Generate cryptographic proofs** - Share only what you need, when you need it * **Use everywhere** - Your attestations work across the entire Web3 ecosystem ## How it Works ### 1. Register and Connect Visit [Zipwire Attest](https://zipwire.io/attest), create an account, and connect your Ethereum wallet. ### 2. Verify Your Identity Complete a secure ID check using our Yoti integration - the same technology trusted by banks and government services. ### 3. Get Attested Upon successful verification, claim attestations directly to your wallet: * **"IsAHuman"** - Proof that you're a verified human being * **"Private Data"** - Cryptographic attestations of your documents ### 4. Generate Proofs When you need to prove something about yourself, generate a cryptographic proof that reveals only the specific information needed. For a full step-by-step journey to get a JWT ProofPack with a claim like nationality (including attestation, delegation, and the Mint API), see [Getting a ProofPack JWT with a Nationality Claim](/zipwire-attest/getting-a-proofpack-jwt-with-nationality). New to JWT/JWS? See [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws). New to ProofPack itself? See [Understanding ProofPack](/fundamentals/security/understanding-proofpack). ## Types of Attestations ### IsAHuman Attestation A simple boolean attestation that proves you're a verified human. This is useful for: * Bot prevention in dApps * Access to gated communities * Basic trust verification ### Private Data Attestations Cryptographic attestations of your documents using Merkle root hashes. These allow you to: * Prove specific facts (age, nationality) without revealing full documents * Maintain complete privacy while being verifiable * Use selective disclosure for different use cases * Selectively reveal any item from your passport or AML report ## Use Cases ### For Individuals * **Age verification** - Prove you're over 18 without sharing your full passport * **Nationality verification** - Confirm your nationality for international services * **Professional credentials** - Verify qualifications without exposing personal details * **DeFi access** - Meet KYC requirements for financial services * **DAO participation** - Prove humanity for governance participation ### For Platforms * **User verification** - Know you're dealing with real humans * **Compliance** - Meet regulatory requirements while respecting privacy * **Trust building** - Reduce fraud and build confidence in your community * **Efficiency** - No need to run your own identity verification ## Privacy and Security ### Privacy-First Design * Your personal documents never leave your control * Only cryptographic hashes are stored on the blockchain * You choose exactly what information to reveal * No central database of personal information ### Security Features * Government-approved ID verification * Optional AML background checks * Cryptographic proofs ensure data integrity * On-chain verification prevents tampering ## Technical Details ### Blockchain Integration * Attestations made to Base blockchain by Zipwire * Uses EAS (Ethereum Attestation Service) * Compatible with all EAS-supporting platforms * Open standards for developer integration ### Wallet Requirements * Supports EOA (Externally Owned Account) and Smart Wallets (e.g., Coinbase Smart Wallet) * Browser extension wallets supported (MetaMask, Coinbase Wallet, etc.) * WalletConnect supported for mobile wallets and QR code connection ## Getting Started Ready to take control of your digital identity? Follow our step-by-step guide to get started with Zipwire Attest. {% content-ref url="" %} {% endcontent-ref %} ## Learn More * [Connect Your Wallet](/fundamentals/security/wallet-connections) * [ID Verification Process](https://github.com/zipwireapp/gbk-tz-docs/tree/main/zipwire-attest/id-verification-process.md) * [Claiming Attestations](https://github.com/zipwireapp/gbk-tz-docs/tree/main/zipwire-attest/claiming-attestations.md) * [Generating Proofs](https://github.com/zipwireapp/gbk-tz-docs/tree/main/zipwire-attest/generating-proofs.md) * [Pricing](https://zipwire.io/my-account/pricing/attest-identity) ## Support Need help with Zipwire Attest? Our support team is here to help you get the most out of your digital identity. # Get Started The following guide will help you get started quickly with Zipwire Attest. ## Sign-up Zipwire uses passkeys and wallet authentication to sign in securely without passwords. You can create a passkey in your browser, or if you're at work and want to keep it personal, scan a QR code with your phone to sign in. Alternatively, you can connect your Ethereum wallet directly. When you sign in, we'll create a new user account and link it to your authentication method. If you're new to Zipwire and signing up via the Zipwire Attest promo page, you'll be registered as an individual - no workplace or business account is needed for Attest. ## Step 1: Connect your wallet Attestations are claimed to an Ethereum wallet, so before anything else Zipwire needs one connected to your account. {% hint style="info" %} Supported wallets include browser extensions (MetaMask, Coinbase Wallet, and similar) and mobile wallets via WalletConnect, plus Smart Wallets such as Coinbase Smart Wallet. See [Connect Your Wallet](/fundamentals/security/wallet-connections) for the full list. {% endhint %} You only need to do this once. Once connected, any attestation you claim later will be sent to this wallet. ## Step 2: Set your document locale Next, choose your document locale from your account settings. This tells Zipwire which government-issued document types to expect during your ID check (for example, which country's passport or driving licence format), and it's also where your ID documents are held in Zipwire's encrypted store. {% hint style="info" %} You can change this later, but it's worth getting right the first time since it determines what Zipwire asks you to upload during ID verification. {% endhint %} ## Step 3: Start your ID check Head to your dashboard. Once your wallet is connected, you'll see a call to action there to start your ID check. This uses our Yoti integration - the same technology trusted by banks and government services - and normally only takes a few minutes. {% hint style="info" %} If you don't see the ID check card on your dashboard, it may be because your wallet isn't connected yet - go back to Step 1 first. {% endhint %} ## Step 4: Claim your attestations Once your ID check succeeds, you'll be able to claim attestations directly to your connected wallet - starting with "IsAHuman" and any Private Data attestations that apply to your documents. See [Claiming Attestations](https://github.com/zipwireapp/gbk-tz-docs/tree/main/zipwire-attest/claiming-attestations.md) for what happens next. ## What's next For a full step-by-step journey to get a JWT ProofPack with a claim like nationality (including attestation, delegation, and the Mint API), see [Getting a ProofPack JWT with a Nationality Claim](/zipwire-attest/getting-a-proofpack-jwt-with-nationality). That's it. If you have any trouble, please reach out to our support team. # Attestation Schemas Technical details of the attestation schemas used by Zipwire Attest, including IsAHuman and Private Data schemas on the Base blockchain. ## Overview Zipwire Attest uses eight attestation schemas on the Base blockchain through the Ethereum Attestation Service (EAS). These schemas provide different levels of verification and privacy protection for users, including basic proof of personhood, age verification, compliance verification, and selective data disclosure. ## Schema Types ### Core Schemas #### IsAHuman Schema The "IsAHuman" schema provides basic Proof of Personhood verification. #### Schema Details * **Schema Name**: IsAHuman * **Schema Type**: Boolean * **Data Structure**: Simple true/false value * **Privacy Level**: Basic - no personal data included * **Transferability**: Not transferable * **Revocability**: Revocable by Zipwire #### Use Cases * Bot prevention in any wallet-connectable application * Access to gated communities * Basic trust verification * DAO participation requirements #### Limitations * No identity linkage to specific person * No selective disclosure capabilities * Can only be claimed against wallets connected *before* ID check * Revocable if verification is compromised #### Private Data Schema The "Private Data" schema provides cryptographic attestations of documents using Merkle root hashes. #### Schema Details * **Schema Name**: Private Data * **Schema Type**: Merkle Root Hash * **Data Structure**: Cryptographic hash of document data * **Privacy Level**: High - enables selective disclosure #### Merkle Tree Structure Each Private Data attestation contains a Merkle root hash that represents: * **Passport data** - All fields from verified passport document * **AML report data** - All fields from background check report (if completed) #### Leaf Structure Each leaf in the Merkle tree includes: * **data**: Hex-encoded content of the field * **salt**: Random bytes to prevent preimage attacks * **hash**: Hash of data + salt * **contentType**: MIME type of the data #### Selective Disclosure Users can selectively reveal any field from their documents by generating Merkle proofs: * **Age verification**: Reveal only date of birth * **Nationality verification**: Reveal only nationality * **AML status**: Reveal only specific compliance fields * **Any document field**: Reveal any individual field as needed ### Age-Based Schemas Zipwire provides five age-based attestation schemas for different age verification requirements. All age attestations follow the same pattern but with different age thresholds. #### IsThirteen Schema * **Purpose**: Confirms user is at least 13 years old * **Use Cases**: COPPA compliance, social media platforms, educational services * **Privacy**: Only confirms age threshold, not exact age #### IsFourteen Schema * **Purpose**: Confirms user is at least 14 years old * **Use Cases**: Platform age requirements, content filtering, service eligibility * **Privacy**: Only confirms age threshold, not exact age #### IsSixteen Schema * **Purpose**: Confirms user is at least 16 years old * **Use Cases**: Employment verification, driving services, financial services * **Privacy**: Only confirms age threshold, not exact age #### IsEighteen Schema * **Purpose**: Confirms user is at least 18 years old * **Use Cases**: Adult services, legal contracts, financial services, employment verification * **Privacy**: Only confirms age threshold, not exact age #### IsTwentyOne Schema * **Purpose**: Confirms user is at least 21 years old * **Use Cases**: Alcohol sales, gambling platforms, adult content, financial services * **Privacy**: Only confirms age threshold, not exact age #### Age Schema Common Features * **Verification Process**: All use Yoti ID check to verify date of birth * **Age Calculation**: Zipwire calculates age from verified date of birth * **Transferability**: Attestations transfer with wallet ownership * **Permanence**: Once issued, attestations are permanent on blockchain * **Privacy**: Only reveal minimum age threshold, not exact age or date of birth ### Compliance Schemas Zipwire provides compliance attestation schemas for regulatory and financial verification requirements. #### HasClearAML Schema * **Purpose**: Confirms user has clear Anti-Money Laundering (AML) status * **Use Cases**: Financial services, high-value transactions, regulatory compliance, DeFi protocols * **Privacy**: Only confirms clear AML status, not specific compliance details #### Compliance Schema Common Features * **Verification Process**: All use specialized compliance verification processes * **Regulatory Focus**: Designed to meet specific regulatory requirements * **Transferability**: Attestations transfer with wallet ownership * **Permanence**: Once issued, attestations are permanent on blockchain * **Privacy**: Only reveal compliance status, not detailed verification information ## Technical Implementation ### Blockchain Integration * **Network**: Base blockchain * **Service**: Ethereum Attestation Service (EAS) * **Attester**: Zipwire's master attester address * **Verification**: On-chain attestation records ### Attestation Process 1. **Wallet Connection**: User connects their Ethereum wallet (must be done before ID check) 2. **ID Verification**: User completes self-check on phone/PC camera + passport photo 3. **Document Processing**: Zipwire automatically processes and verifies documents 4. **Merkle Tree Creation**: Zipwire automatically creates Merkle tree from document data 5. **Root Hash Generation**: Zipwire automatically generates cryptographic hash of the entire dataset 6. **User Claim**: User claims attestation to their connected wallet 7. **Blockchain Attestation**: Zipwire automatically attests root hash on Base via EAS ### Proof Generation When users need to prove specific information (coming soon): 1. **Select Fields**: Choose which data fields to reveal via UI 2. **Generate Proof**: Create Merkle proof for selected fields 3. **Create ProofPack**: Package proof in ProofPack format (see [Understanding ProofPack](/fundamentals/security/understanding-proofpack)) 4. **Share**: Send ProofPack to recipient **Note**: OAuth integration allowing other sites/apps to view proofs is on the longer-term roadmap. ## Schema Specifications ### IsAHuman Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` ### Private Data Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x1316fc0f...", // ABI encoded bytes (Merkle root hash) "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` ### Age-Based Schemas All age-based schemas follow the same JSON structure with boolean true values: #### IsThirteen Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` #### IsFourteen Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` #### IsSixteen Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` #### IsEighteen Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` #### IsTwentyOne Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` #### HasClearAML Schema ```json { "uid": "attestation_uid", "schema": "schema_uid", "attester": "0x2651e...", "recipient": "user_wallet_address", "data": "0x0000000000000000000000000000000000000000000000000000000000000001", // ABI encoded boolean true "timestamp": "2024-01-01T00:00:00Z", "revoked": false } ``` ## Verification Process ### On-Chain Verification 1. **EAS Scan**: Check attestation on Base blockchain 2. **Attester Verification**: Confirm attestation from Zipwire's address 3. **Schema Validation**: Verify correct schema type 4. **Revocation Check**: Ensure attestation is not revoked 5. **Timestamp Check**: Ensure attestation is current ### Proof Verification 1. **Merkle Proof**: Verify leaf hashes against root 2. **Data Integrity**: Confirm revealed data matches proof 3. **Salt Validation**: Check salt prevents preimage attacks 4. **Content Type**: Validate MIME types **Note**: ProofPack SDK is now available on NPM for easy verification. ## Security Considerations ### Privacy Protection * **No Personal Data**: Only cryptographic hashes stored on-chain * **Selective Disclosure**: Users control exactly what to reveal * **Salt Protection**: Prevents preimage attacks on hashes * **Self-Sovereign**: Users own and control their proofs * **Localized Storage**: Original data stored in double-encrypted localized storage * **Technical Redaction**: Advanced users can download full reveal proofs, delete `data` and `salt`, and create custom redacted proofs (unsigned but chain-validatable) ### Integrity Assurance * **Cryptographic Proofs**: Merkle trees ensure data integrity * **Blockchain Verification**: On-chain attestations prevent tampering * **Signature Validation**: JWS envelopes provide tamper-proofing * **Timestamp Protection**: Prevents replay attacks ## Developer Integration ### EAS Integration ```javascript // Example: Verify attestation on Base const attestation = await eas.getAttestation(attestationUid); const isValid = attestation.attester === "0x2651e..."; // check official Zipwire attester address const isNotRevoked = !attestation.revoked; ``` See our [official Zipwire attester address on our GitHub.com](https://github.com/zipwireapp/zipwireapp/blob/master/PUBLICKEYS.md) ### ProofPack Verification ```javascript // Using the ProofPack SDK (recommended) import { AttestedMerkleExchangeReader } from '@zipwire/proofpack'; import { EasAttestationVerifierFactory, ES256KVerifier } from '@zipwire/proofpack-ethereum'; // Configure networks and create verifier const networks = { 'base': { rpcUrl: `https://api.developer.coinbase.com/rpc/v1/base/${apiKey}`, easContractAddress: '0x4200000000000000000000000000000000000021' } }; const attestationVerifierFactory = EasAttestationVerifierFactory.fromConfig(networks); const reader = new AttestedMerkleExchangeReader(); // Verify complete document with attestation const result = await reader.readAsync(jwsEnvelopeJson, verificationContext); if (result.isValid) { console.log("Verified data:", result.document); console.log("Merkle Root:", result.document.merkleTree.root); console.log("Attestation Network:", result.document.attestation.eas.network); } ``` **Note**: ProofPack SDK is now available on NPM for easy verification. See [GitHub repository](https://github.com/zipwireapp/ProofPack) for documentation and examples. ## Related Resources ### Core Attestations * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) * [The "IsAHuman" Attestation](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) * [The "Private Data" Attestation](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) * [Verifying Zipwire's Merkle Root Attestations](/fundamentals/security/wallet-verification-guide/verifying-zipwires-merkle-root-attestations-for-developers) ### Age-Based Attestations * [The "IsThirteen" Attestation](/fundamentals/security/attestations/the-isthirteen-attestation-purpose-and-limitations) * [The "IsFourteen" Attestation](/fundamentals/security/attestations/the-isfourteen-attestation-purpose-and-limitations) * [The "IsSixteen" Attestation](/fundamentals/security/attestations/the-issixteen-attestation-purpose-and-limitations) * [The "IsEighteen" Attestation](/fundamentals/security/attestations/the-iseighteen-attestation-purpose-and-limitations) * [The "IsTwentyOne" Attestation](/fundamentals/security/attestations/the-istwentyone-attestation-purpose-and-limitations) ### Compliance Attestations * [The "HasClearAML" Attestation](/fundamentals/security/attestations/the-hasclearaml-attestation-purpose-and-limitations) ### External Resources * [EAS Explorer on Base](https://base.easscan.org/) * [ProofPack SDK on GitHub](https://github.com/zipwireapp/ProofPack) ## Schema UIDs Zipwire uses the following EAS schema UIDs for its attestations: ### Core Schemas #### IsAHuman Schema * **Schema UID**: `0x8af15e65888f2e3b487e536a4922e277dcfe85b4b18187b0cf9afdb802ba6bb6` * **Purpose**: Proof of personhood verification * **Type**: Simple boolean attestation * **Use Cases**: Bot prevention in any wallet-connectable application #### Private Data Schema * **Schema UID**: `0x20351f973fdec1478924c89dfa533d8f872defa108d9c3c6512267d7e7e5dbc2` * **Purpose**: Selective disclosure of document information * **Type**: Merkle root attestation with selective disclosure * **Use Cases**: Age verification, nationality verification, credential verification ### Age-Based Schemas The following age-based schemas are available: #### IsThirteen Schema * **Schema UID**: `0x8a236ef2aa0b65165326fc1d6f8fa29dfd139e391432c59ab6ea7605ed578425` * **Purpose**: Confirms user is at least 13 years old * **Type**: Simple boolean attestation * **Use Cases**: COPPA compliance, social media platforms, educational services #### IsFourteen Schema * **Schema UID**: `0x175f46f002f3c955b85654294bb7ba489a20170b92affc31384e4c99ffa891e7` * **Purpose**: Confirms user is at least 14 years old * **Type**: Simple boolean attestation * **Use Cases**: Platform age requirements, content filtering, service eligibility #### IsSixteen Schema * **Schema UID**: `0xbf0313ff4991a4f628ba7e0ead6a5bcd633e2049ea78ca906fe65e126942530b` * **Purpose**: Confirms user is at least 16 years old * **Type**: Simple boolean attestation * **Use Cases**: Employment verification, driving services, financial services #### IsEighteen Schema * **Schema UID**: `0xba73ff8acaee0bf6c4a8d294dcdc27b1a60489f5338a13058d129fc7e640212f` * **Purpose**: Confirms user is at least 18 years old * **Type**: Simple boolean attestation * **Use Cases**: Adult services, legal contracts, financial services, employment verification #### IsTwentyOne Schema * **Schema UID**: `0x1681ac077844d5f53b9a59a1495bde1bd62af45e646de7feda722f68164a1465` * **Purpose**: Confirms user is at least 21 years old * **Type**: Simple boolean attestation * **Use Cases**: Alcohol sales, gambling platforms, adult content, financial services #### HasClearAML Schema * **Schema UID**: `0xdc1cb4d85858a3c6fe90fcce9779c3ffad0376d5dd3583cf684056fd98359f9c` * **Purpose**: Confirms user has clear Anti-Money Laundering (AML) status * **Type**: Simple boolean attestation * **Use Cases**: Financial services, high-value transactions, regulatory compliance, DeFi protocols ## Attester Information All Zipwire attestations are issued by our master attester wallet. For verification purposes, you can find the official public key and Ethereum wallet address at: [Zipwire Public Keys on GitHub](https://github.com/zipwireapp/zipwireapp/blob/master/PUBLICKEYS.md) This is the authoritative source for verifying that attestations were issued by Zipwire. # Proof Verification How to verify ProofPacks and attestations from Zipwire Attest users, including technical verification steps and developer integration. ## Overview When someone shares a ProofPack with you, you can verify its authenticity and integrity without needing access to the original documents. This page explains how to verify ProofPacks and understand what information has been shared. New to ProofPack? See [Understanding ProofPack](/fundamentals/security/understanding-proofpack) for what's actually inside one. {% hint style="success" %} **Just want to check a proof right now?** Drop a ProofPack JSON file into [zipwire.io/verify-proof](https://zipwire.io/verify-proof) and it'll run the JWS, Merkle tree, and blockchain attestation checks below for you - no code required. {% endhint %} **Note**: This page covers technical verification of ProofPack data structures. For general wallet verification and trust assessment, see [Verifying Attested Wallets](/fundamentals/security/wallet-verification-guide/verifying-attested-wallets). ## Understanding Proof vs. Wallet Verification There are two complementary levels of verification: ### Wallet Verification (General) * **Purpose**: Determine if a wallet owner is trustworthy * **Focus**: Who owns the wallet, when it was attested, transaction patterns * **When to use**: Before accepting any data from a wallet owner * **Tools**: EAS Scan, block explorers, transaction history ### Proof Verification (Technical - This Page) * **Purpose**: Verify the authenticity and integrity of shared data * **Focus**: Cryptographic verification of ProofPack structures and attestations * **When to use**: After establishing wallet trust, to verify specific shared data * **Tools**: Code libraries, cryptographic verification, blockchain APIs **Workflow**: First verify the wallet is trustworthy, then verify the specific data they share. ## What is a ProofPack? A ProofPack is a layered, privacy-preserving data exchange format that contains: * **Merkle Exchange Document** - The actual data with selective disclosure * **Attested Merkle Exchange Document** - Blockchain attestation metadata * **JWS Envelope** - Cryptographic signatures for tamper-proofing For complete technical details, see the [ProofPack specification on GitHub](https://github.com/zipwireapp/ProofPack). ## AI and LLM Integration ProofPack's structured JSON format is ideal for AI-driven automation and verification. Large Language Models (LLMs) can already: ### Current LLM Capabilities * **Decode ProofPack JSON** - Parse and understand the structure automatically * **Extract leaf data** - Decode hex-encoded content from leaves * **Write verification scripts** - Generate code to verify Merkle proofs * **Execute verification logic** - Run scripts to check data integrity * **Analyze proof content** - Understand what data has been revealed ### Example: LLM Verification LLMs like Google Gemini (June 2025) have demonstrated the ability to: 1. **Parse ProofPack JSON** structure 2. **Decode hex-encoded leaf data** 3. **Write Python scripts** to verify leaf hashes against the root hash 4. **Execute verification** without human intervention ### Blockchain Connectivity Limitation The only current limitation for LLMs is **blockchain connectivity**: * **EAS verification** - Checking attestations on Base blockchain * **Chain connectivity** - Accessing on-chain attestation data * **MCP requirement** - Need Model Context Protocol (MCP) server for Base connection ### Future Potential With MCP servers providing blockchain connectivity, LLMs could: * **Fully automated verification** - Complete end-to-end proof verification * **Real-time attestation checking** - Verify on-chain attestation status * **Trust chain validation** - Follow complete verification chains * **Intelligent proof analysis** - Understand context and validity This represents a significant step toward **AI-driven, secure verification** without human intervention. ### Simple Future Workflow In the future, users will be able to simply **drop a ProofPack JSON into an AI** and it will automatically: * **Parse the structure** and understand what type of proof it is * **Decode the data** and extract the relevant information * **Write verification scripts** to check the proof's integrity * **Connect to blockchain** (via MCP) to verify attestations * **Provide results** with confidence levels and explanations No technical knowledge required - just paste and verify. ## Verification Process ### 1. Verify JWS Envelope (Outermost Layer) The JWS envelope provides cryptographic signatures to ensure the document hasn't been tampered with. New to JWS/JWT? See [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws). #### What to Check: * **Signature Validity**: Verify at least one valid signature (RS256, ES256K) * **Tamper Detection**: Ensure the signature covers both header and payload * **No Blockchain Required**: JWS verification can be done offline #### Example Verification: ```javascript // NOTE: This is conceptual code - no JavaScript SDK is currently available // Manual verification (alternative to SDK) const isValidSignature = await verifyJWS(proofPack, publicKey); if (!isValidSignature) { throw new Error("ProofPack signature is invalid"); } ``` ### 2. Verify Merkle Tree (Innermost Layer) The Merkle tree ensures data integrity and enables selective disclosure. #### What to Check: * **Minimum Leaves**: Confirm at least two leaves exist * **Metadata Leaf**: First leaf must contain valid metadata * **Content Types**: Validate MIME types of revealed data * **Hash Verification**: Recompute leaf hashes and verify against root #### Example Verification: ```javascript // NOTE: This is conceptual code - no JavaScript SDK is currently available // Manual verification (alternative to SDK) // Verify Merkle tree structure const leaves = proofPack.merkleTree.leaves; if (leaves.length < 2) { throw new Error("ProofPack must have at least 2 leaves"); } // Verify first leaf is metadata const metadataLeaf = leaves[0]; if (metadataLeaf.contentType !== "application/json") { throw new Error("First leaf must contain metadata"); } // Verify revealed data hashes for (const leaf of leaves) { if (leaf.data && leaf.salt) { const computedHash = hash(leaf.data + leaf.salt); if (computedHash !== leaf.hash) { throw new Error("Leaf hash verification failed"); } } } ``` ### 3. Verify Blockchain Attestation (Middle Layer) The blockchain attestation links the data to verifiable on-chain trust records. #### What to Check: * **EAS Attestation**: Verify attestation exists on Base blockchain * **Attester Validation**: Confirm attestation from Zipwire's address * **Schema Validation**: Ensure correct schema type (IsAHuman or Private Data) * **Revocation Check**: Verify attestation is not revoked * **Timestamp Validation**: Check attestation is current #### Example Verification: ```javascript // NOTE: This is conceptual code - no JavaScript SDK is currently available // Manual verification (alternative to SDK) // Verify on-chain attestation const attestation = await eas.getAttestation(proofPack.attestation.eas.attestationUid); // Check attester const isValidAttester = attestation.attester === "0x2651e..."; // Zipwire's address if (!isValidAttester) { throw new Error("Invalid attester"); } // Check revocation if (attestation.revoked) { throw new Error("Attestation has been revoked"); } // Check schema const isValidSchema = attestation.schema === expectedSchemaUid; if (!isValidSchema) { throw new Error("Invalid schema"); } ``` ## Trust Chain Verification ProofPack enables verifiable trust chains through blockchain attestations. ### Example Trust Chain: **Date of Birth ← Passport ← Zipwire ← Yoti ← iBeta ← NIST** ### Verification Steps: 1. **Verify NIST attestation** to iBeta's testing capabilities 2. **Verify iBeta attestation** to Yoti's MyFace technology 3. **Verify Yoti attestation** to Zipwire's implementation 4. **Verify Zipwire attestation** to passport verification 5. **Verify passport authority** to the date of birth ## Real-World Verification Examples **Note**: The following examples show simplified data for clarity. In practice, leaf data is normally hex-encoded JSON key-value pairs, but can conceivably be any data including images or audio. ### Age Verification ```json { "merkleTree": { "leaves": [ { "contentType": "application/json", "data": "{\"documentType\":\"passport\",\"verificationDate\":\"2024-01-01\"}" }, { "contentType": "text/plain", "data": "1990-05-15", "salt": "random_salt_bytes", "hash": "computed_hash" } ], "root": "0x1316fc0f..." }, "attestation": { "eas": { "network": "base", "attestationUid": "...", "schema": "PrivateData" } } } ``` **Actual Implementation**: Leaf data would be hex-encoded JSON like: ```json { "contentType": "application/json", "data": "0x7b22646f63756d656e7454797065223a2270617373706f7274222c22766572696669636174696f6e44617465223a22323032342d30312d3031227d", "salt": "0x1234567890abcdef...", "hash": "0xabcdef1234567890..." } ``` ### Nationality Verification ```json { "merkleTree": { "leaves": [ { "contentType": "application/json", "data": "{\"documentType\":\"passport\"}" }, { "contentType": "text/plain", "data": "United Kingdom", "salt": "random_salt_bytes", "hash": "computed_hash" } ], "root": "0x1316fc0f..." } } ``` **Actual Implementation**: Leaf data would be hex-encoded like: ```json { "contentType": "text/plain", "data": "0x556e69746564204b696e67646f6d", "salt": "0xfedcba0987654321...", "hash": "0x9876543210fedcba..." } ``` ## Developer Integration ### ProofPack SDK Verification (Recommended) **Important**: The ProofPack SDK is now available on NPM for easy verification. ```javascript // Install the SDK: npm install @zipwire/proofpack @zipwire/proofpack-ethereum import { AttestedMerkleExchangeReader, JwsSignatureRequirement, createVerificationContextWithAttestationVerifierFactory } from '@zipwire/proofpack'; import { EasAttestationVerifierFactory, ES256KVerifier } from '@zipwire/proofpack-ethereum'; async function verifyProofPackDocument(jwsEnvelopeJson, coinbaseApiKey) { // 1. Configure blockchain networks for EAS attestation verification const networks = { 'base-sepolia': { rpcUrl: `https://api.developer.coinbase.com/rpc/v1/base-sepolia/${coinbaseApiKey}`, easContractAddress: '0x4200000000000000000000000000000000000021' }, 'base': { rpcUrl: `https://api.developer.coinbase.com/rpc/v1/base/${coinbaseApiKey}`, easContractAddress: '0x4200000000000000000000000000000000000021' } }; // 2. Create EAS attestation verifier const attestationVerifierFactory = EasAttestationVerifierFactory.fromConfig(networks); // 3. Create JWS verifier resolver that uses attester addresses from attestation const resolveJwsVerifier = (algorithm, signerAddresses) => { if (algorithm === 'ES256K') { // signerAddresses contains the attester address from attestation verification // We trust the attestation to tell us who should have signed // No need to pass expected signer addresses as parameters - the blockchain attestation is the source of truth! for (const signerAddress of signerAddresses) { return new ES256KVerifier(signerAddress); } } return null; }; // 4. Define verification rules const maxAge = 24 * 60 * 60 * 1000; // 24 hours const hasValidNonce = async (nonce) => { // Validate nonce format (32-character hex) return /^[0-9a-fA-F]{32}$/.test(nonce); }; // 5. Create comprehensive verification context const verificationContext = createVerificationContextWithAttestationVerifierFactory( maxAge, // Maximum document age resolveJwsVerifier, // JWS verifier resolver function JwsSignatureRequirement.AtLeastOne, // Require at least one valid signature hasValidNonce, // Nonce validation function attestationVerifierFactory // EAS attestation verifier factory ); // 6. Verify the complete document const reader = new AttestedMerkleExchangeReader(); const result = await reader.readAsync(jwsEnvelopeJson, verificationContext); // 7. Handle results if (result.isValid) { console.log('✅ Document verified successfully!'); console.log('Message:', result.message); // Access verified data const document = result.document; console.log('Merkle Root:', document.merkleTree.root); console.log('Attestation Network:', document.attestation.eas.network); console.log('Timestamp:', document.timestamp); // 8. Verify recipient matches expected wallet const expectedRecipient = '0x1234567890123456789012345678901234567890'; // User's wallet const attestedRecipient = result.document.attestation.eas.to; if (attestedRecipient && attestedRecipient.toLowerCase() !== expectedRecipient.toLowerCase()) { return { success: false, error: `Wrong recipient. Expected: ${expectedRecipient}, Got: ${attestedRecipient}` }; } return { success: true, document: document, recipientAddress: attestedRecipient }; } else { console.error('❌ Verification failed:', result.message); return { success: false, error: result.message }; } } // Usage const jwsDocument = `{ "payload": "eyJtZXJrbGVUcmVlIjp7ImxlYXZlcyI6W3siZGF0YSI6IjB4N2I3MDcyNmY3NDY...", "signatures": [{"protected": "eyJhbGciOiJFUzI1NksiLCJ0eXAiOiJKV1MifQ", "signature": "..."}] }`; const apiKey = process.env.COINBASE_API_KEY; try { const result = await verifyProofPackDocument(jwsDocument, apiKey); if (result.success) { console.log('Document verified successfully!'); } else { console.error('Verification failed:', result.error); } } catch (error) { console.error('Error during verification:', error.message); } ``` ### Verification Options * [**zipwire.io/verify-proof**](https://zipwire.io/verify-proof) - Paste or upload a ProofPack and verify it in the browser, no installation needed * **ProofPack SDK** (recommended for integrating verification into your own app) - Easy to use, handles all verification steps * Install: `npm install @zipwire/proofpack @zipwire/proofpack-ethereum` * Repository: * Supports ES256K (Ethereum) and RS256 signature algorithms * Provides flexible parsing and verification methods ## Security Considerations ### Privacy Protection * **Selective Disclosure**: Only requested data is revealed * **Salt Protection**: Prevents preimage attacks on hashes * **No Original Data**: Original documents are never shared ### Integrity Assurance * **Cryptographic Proofs**: Merkle trees ensure data integrity * **Blockchain Verification**: On-chain attestations prevent tampering * **Signature Validation**: JWS envelopes provide tamper-proofing ### Trust Verification * **Attester Validation**: Confirm trusted source (Zipwire) * **Revocation Checking**: Ensure attestation is still valid * **Timestamp Validation**: Verify attestation is current ## Common Verification Scenarios ### For Age-Restricted Services 1. User shares ProofPack revealing only date of birth 2. Service verifies ProofPack integrity 3. Service checks attestation is from Zipwire 4. Service calculates age from date of birth 5. Service grants access if age requirement met ### For Compliance Requirements 1. User shares ProofPack revealing specific compliance fields 2. Platform verifies ProofPack and attestation 3. Platform checks attestation is not revoked 4. Platform uses verified data for compliance reporting ### For Identity Verification 1. User shares ProofPack revealing nationality 2. Service verifies ProofPack authenticity 3. Service confirms attestation from trusted source 4. Service grants access based on nationality ## Troubleshooting ### Common Issues * **Invalid Signature**: Check JWS envelope and public keys * **Merkle Tree Error**: Verify leaf structure and hash computations * **Attestation Not Found**: Check EAS Scan for attestation existence * **Revoked Attestation**: Attestation may have been revoked by Zipwire * **Expired Attestation**: Check timestamp and validity period ### Verification Tools * **EAS Scan**: * **JWS Verification**: Use standard JWS libraries * **Merkle Tree Tools**: Implement hash verification functions * **ProofPack Specification**: Manual verification using the official specification ## Related Resources * [zipwire.io/verify-proof](https://zipwire.io/verify-proof) - Verify a proof in the browser * [Verifying Attested Wallets](/fundamentals/security/wallet-verification-guide/verifying-attested-wallets) - General wallet trust assessment * [Attestation Schemas](/zipwire-attest/attestation-schemas) * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) * [Verifying Zipwire's Merkle Root Attestations](/fundamentals/security/wallet-verification-guide/verifying-zipwires-merkle-root-attestations-for-developers) * [EAS Explorer on Base](https://base.easscan.org/) # Getting a ProofPack JWT with a Nationality Claim End-to-end user journey to get a JWT ProofPack with IsDelegate → human and a nationality claim This page walks through the **full user journey** to obtain a JWT that: * Contains a **ProofPack** (selective-disclosure proof) * Is tied to an attestation chain where an **IsDelegate** points to a verified **human** * Reveals a **nationality** claim (and only what you choose) Use this when you want to understand every step from "I'm a human with an attested identity" to "I have a JWT my agent (or I) can present to services that proves delegation and nationality." New to JWT/JWS? See [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws). New to ProofPack itself? See [Understanding ProofPack](/fundamentals/security/understanding-proofpack). *** ## What You End Up With At the end of this journey you have a **JWT** (compact token) that: 1. **Attestation chain** — The proof inside points to an IsDelegate attestation that points to your human attestation (e.g. IsAHuman). Services can verify this chain on-chain. 2. **ProofPack** — The JWT is a ProofPack: it uses Merkle proofs and selective disclosure. 3. **Nationality claim** — The proof reveals only the claim you requested (e.g. nationality), not your full identity. That JWT can be given to an agent to send in `Authorization: Bearer ` to services that verify ProofPacks and read the nationality claim. *** ## The Five Steps ### Step 1: Get your identity attested (human root) You need a verified human identity and identity data (including nationality) that Zipwire can use to build proofs. **What to do:** * Use [Zipwire Attest](https://zipwire.io/attest) to verify your identity. * Complete a **Yoti ID check** (liveness + government ID). * Connect and use an **Ethereum wallet** that will hold your attestations. **What you get:** * An **IsAHuman** (or equivalent) attestation tied to **your wallet** — the "human" wallet. * Your identity data (including nationality) stored in a **Merkle tree** and committed on-chain (e.g. via that attestation / Merkle root). That human wallet + IsAHuman is the **root of trust** for all later steps. {% content-ref url="/pages/kzmdzG6x7y91vzCPFJMX" %} [Your Digital Identity on the Blockchain](/zipwire-attest/zipwire-attest) {% endcontent-ref %} *** ### Step 2: Create an IsDelegate from you (human) to the agent You authorize an agent wallet to act on your behalf by creating an IsDelegate attestation. **What to do:** * On [EAS Base](https://base.easscan.org), create an attestation using the **IsDelegate** schema. * Set: * **Attester** = your **human wallet** (the one with IsAHuman). * **Recipient** = the **agent wallet** that will use the JWT (e.g. your bot’s or app’s wallet). * **refUID** = the UID of your **IsAHuman** attestation (so the chain is human → IsDelegate → agent). * Sign and submit the attestation. **What you get:** * The agent wallet is **delegated to you**: its IsDelegate points to your human attestation. Services (and the ProofPack Mint API) can follow this chain to confirm the agent acts for a verified human. {% content-ref url="/pages/9pYWdNTnWIKazoNLt567" %} [IsDelegate: Agent Delegation & Authorization](/fundamentals/security/attestations/isdelegate-agent-delegation) {% endcontent-ref %} *** ### Step 3: Get an API key for your Zipwire account The ProofPack Mint API is called with **your** (the human’s) API key. The API mints a proof on your behalf for a delegated agent. **What to do:** * Obtain an **API key** for the Zipwire account that owns the human wallet and attested identity (e.g. from your Zipwire account or developer settings). **What you get:** * The ability to call the ProofPack Mint API to generate JWTs (ProofPacks) for agents delegated to you. *** ### Step 4: Mint a ProofPack JWT that reveals nationality This is the step where you **get the JWT**. **What to do:** * Call the **ProofPack Mint API** with your API key: * **agentWallet** = the **agent** wallet you delegated in Step 2. * **selectedFields** = `["nationality"]` (optional; not required—omit to mint a proof with no identity fields revealed; for this journey we include it to get the nationality claim). * **format** = `"JWT"`. **What the API does:** * Resolves your API key to your account and your attested identity (and its Merkle tree, which includes nationality). * Verifies that the agent wallet has an **IsDelegate** that points to **you** (the same human). * Builds a ProofPack that reveals only the **nationality** field and returns it as a **JWT**. **What you get:** * The response body contains the JWT in the **proofPack** field. That JWT **is** the ProofPack: it includes the nationality claim and is tied to the attestation chain (IsDelegate → human). {% content-ref url="/pages/gY1sW2rVpDHKKy5RRCDi" %} [ProofPack Mint API](/api/zipwire-attest/proofpack-mint-api) {% endcontent-ref %} *** ### Step 5: Use the JWT **What to do:** * Use the JWT you received from the Mint API. * Typically: give it to the **agent** (e.g. store it or pass it in a header). The agent sends it to services as `Authorization: Bearer `. * Services verify the JWT with the ProofPack library: they see the attestation chain (IsDelegate → human) and the revealed **nationality** claim. {% content-ref url="/pages/yTRncn59sC3kqKG8cFaH" %} [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation) {% endcontent-ref %} {% content-ref url="/pages/vHjbCV4bV7welWu86ldI" %} [Path 2: JWS with claims (JavaScript)](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript) {% endcontent-ref %} *** ## Summary Table | Step | What you do | What you get | | ----- | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | **1** | Attest as human (Yoti + Zipwire Attest) | Human wallet with IsAHuman + Merkle tree (includes nationality). | | **2** | Create IsDelegate on EAS: human → agent wallet | Agent wallet delegated to you. | | **3** | Get Zipwire API key for your account | Ability to call ProofPack Mint. | | **4** | POST to ProofPack Mint with `agentWallet`, `selectedFields: ["nationality"]`, `format: "JWT"` | **JWT (ProofPack)** with nationality claim and attestation chain (IsDelegate → human). | | **5** | Pass JWT to agent or use it yourself | Agent (or you) can present it to services. | {% hint style="info" %} **Other claims**\ `selectedFields` is optional (not required). Omit it to mint a proof with no identity fields revealed. To reveal claims, use `selectedFields` with any keys from your identity data (e.g. `nationality`, `date_of_birth`, `given_names`). See the [ProofPack Mint API](/api/zipwire-attest/proofpack-mint-api) for the list of typical fields. {% endhint %} *** ## Related documentation * [Proof Verification](/zipwire-attest/proof-verification) — How services verify ProofPacks * [IsDelegate REST API](/fundamentals/security/attestations/is-delegate-rest-api) — Public check that a wallet has a valid IsDelegate chain * [ProofPack Examples](/tools-and-integrations/proofpack-agent-delegation/proofpack-examples) — Code samples for verification and integration # Privacy and Security Privacy and security guarantees for Zipwire Attest, including data handling, user control, and security measures. ## Overview Zipwire Attest is built with privacy and security as core principles. This page explains how we protect your data, maintain your privacy, and ensure the security of your digital identity. ## Privacy-First Design ### Your Data, Your Control Zipwire Attest follows a **self-sovereign identity** model where you maintain complete control over your personal information: * **Centralized but Encrypted**: Your personal documents are stored in centralized, double-encrypted storage * **Country Selection**: You choose which country to store your data in * **Selective Disclosure**: You choose exactly what information to reveal and to whom * **Self-Sovereign**: You own and control your proofs and attestations ### What We Store vs. What We Don't #### What We Store (Securely) * **Double-encrypted PII** in centralized storage (we cannot read the encrypted data) * **Cryptographic hashes** on the blockchain (Merkle roots) * **Attestation records** on the Base blockchain * **Verification metadata** (timestamps, attestation IDs) #### What We Don't Store * **Unencrypted personal documents** in our systems * **Your private keys** or wallet credentials * **Your browsing history** or usage patterns * **Personal information** in plain text ## Security Measures ### Document Security #### Double Encryption Your documents are protected by multiple layers of encryption: 1. **Application-level encryption** by Zipwire 2. **Cloud provider encryption** by our storage partner 3. **Transport encryption** (TLS) for all data transmission #### Localized Storage * **Regional compliance**: Data stored in your chosen region * **Sovereign data**: Your customers choose where to store documents * **No cross-border transfer**: Data stays within your selected jurisdiction ### Blockchain Security #### On-Chain Protection * **Cryptographic hashes only**: Only Merkle root hashes are stored on-chain * **No personal data**: Your actual documents never appear on the blockchain * **Immutable records**: Attestations cannot be altered once recorded * **Verifiable integrity**: Cryptographic proofs ensure data hasn't been tampered with #### Attestation Security * **Revocable attestations**: Zipwire can revoke attestations if needed * **Timestamp validation**: Attestations include verification timestamps * **Attester verification**: All attestations come from Zipwire's verified address ### Wallet Security #### Connection Requirements * **EOA & Smart Wallets**: Supports traditional Externally Owned Accounts and modern Smart Wallets (e.g., Coinbase Smart Wallet). * **Flexible Connection**: Supports browser extensions (MetaMask, Coinbase Wallet, etc.) and mobile wallets via **WalletConnect**. * **Signature Standards**: Fully compatible with EIP-1271 and ERC-6492 for smart wallet signatures. * **Connection timing**: Wallet must be connected before ID verification #### Private Key Protection * **Never stored**: We never see or store your private keys * **SIWE only**: Only Sign-in with Ethereum (SIWE) is used, no transactions to sign * **No access**: We cannot access your wallet or funds ## Data Handling ### Document Processing #### Verification Process 1. **Temporary processing**: Documents processed temporarily for verification 2. **Immediate encryption**: Data encrypted as soon as it's received 3. **Secure deletion**: Temporary processing data deleted after verification 4. **No retention**: We don't retain unencrypted document data #### Merkle Tree Creation * **Local processing**: Merkle trees created in secure, isolated environments * **Salt generation**: Random salts prevent preimage attacks * **Hash computation**: Cryptographic hashes computed securely * **No data leakage**: Original data never leaves the secure environment ### Data Retention #### Attestation Data * **Permanent on-chain**: Attestation records are permanent on the blockchain * **User-controlled**: Users can delete their local document data * **Verifiable forever**: Attestations remain verifiable even after local data deletion #### Document Storage * **User-controlled retention**: You control how long documents are stored * **Download and delete**: You can download your data and delete it at any time * **GDPR compliance**: Data will be deleted if you abandon your account * **No backup copies**: We don't create backup copies of your documents ## User Control and Rights ### Selective Disclosure #### Complete Control * **Choose what to reveal**: Select exactly which fields to share * **Context-specific**: Different proofs for different use cases * **No over-sharing**: Never reveal more than necessary * **Revocable sharing**: Stop sharing proofs at any time #### Proof Management * **Download proofs**: Save ProofPacks locally for offline use * **Edit proofs**: Advanced users can create custom redacted proofs * **Share selectively**: Choose who receives your proofs * **Track usage**: Monitor where your proofs are used ### Data Deletion #### Right to Delete * **Immediate deletion**: Delete your documents at any time * **Complete removal**: All local data removed from our systems * **Attestation preservation**: Blockchain attestations remain for verification * **No recovery**: Deleted data cannot be recovered #### Technical Deletion * **Secure deletion**: Data overwritten multiple times before deletion * **Verification**: Confirmation that data has been completely removed * **Audit trail**: Record of deletion for compliance purposes ## Compliance and Standards ### Regulatory Compliance #### GDPR Compliance * **Right to be forgotten**: Complete data deletion capability * **Data portability**: Export your data in standard formats * **Consent management**: Clear consent for data processing * **Privacy by design**: Privacy built into every feature #### Regional Compliance * **Local data storage**: Choose your data storage region * **Regional regulations**: Comply with local privacy laws * **Cross-border restrictions**: Respect data sovereignty requirements ### Security Standards #### Industry Standards * **SOC 2 compliance**: Security and availability controls * **ISO 27001**: Information security management * **Encryption standards**: AES-256 encryption for data at rest * **Transport security**: TLS 1.3 for data in transit #### Blockchain Standards * **EAS compliance**: Ethereum Attestation Service standards * **Base network**: Secure Layer 2 blockchain * **Cryptographic standards**: Industry-standard hash functions * **Signature verification**: ECDSA and other standard algorithms ## Threat Protection ### Attack Prevention #### Preimage Attack Protection * **Random salts**: Each data field has unique random salt * **Hash protection**: Salts prevent reverse-engineering of data * **Cryptographic strength**: Industry-standard hash functions #### Tampering Prevention * **Merkle tree integrity**: Cryptographic proofs prevent data tampering * **Blockchain immutability**: On-chain records cannot be altered * **Signature verification**: JWS envelopes prevent document tampering ## Transparency ### Open Standards * **ProofPack specification**: Open standard for data exchange * **EAS integration**: Open blockchain attestation service * **Verifiable code**: Open source verification libraries * **Public attestations**: All attestations visible on blockchain ## Best Practices for Users ### Security Recommendations * **Secure wallet**: Use a hardware wallet for maximum security * **Regular updates**: Keep your wallet software updated * **Backup proofs**: Store ProofPacks securely for offline use * **Monitor attestations**: Regularly check your attestation status ### Privacy Recommendations * **Minimal disclosure**: Only share what's absolutely necessary * **Context awareness**: Use different proofs for different contexts * **Regular cleanup**: Delete old documents and proofs regularly * **Stay informed**: Keep up with privacy and security updates ## Related Resources * [Attestation Schemas](/zipwire-attest/attestation-schemas) * [Proof Verification](/zipwire-attest/proof-verification) * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) * [Data Ownership in Zipwire](/overview/data-ownership-in-zipwire) # Tools & Integrations Command-line tools and integrations for Zipwire This section covers command-line tools and integrations that enable deeper, programmatic access to Zipwire's functionality. ## Choose Your Integration ### MCP Server Integrate Zipwire with any **MCP (Model Context Protocol)** client—Claude Desktop, custom agents, or other tools that support the MCP standard. Manage timesheets, activities, workflows, invoicing, and more programmatically. **Best for:** Developers, AI agents, any MCP-compatible tool [Get Started with MCP →](/use-cases/for-agents/zipwire-mcp-server) *** ## Zipwire CLI (zw) The Zipwire command-line interface is designed for **technical contractors and developers** who want to manage their time tracking, timesheets, and invoicing directly from the terminal. Think of it like **Git for work** – instead of committing code changes, you're committing your time entries to your private journal, which automatically generates timesheets, handles approvals, and creates invoices. ### Why Use the CLI? * **Automation**: Script your entire contractor workflow (track time → create timesheet → send for approval) * **Integration**: Use it in CI/CD pipelines, cron jobs, or with coding agents * **Flexibility**: Track time from anywhere, integrate with your existing tools * **Machine-readable**: Structured output formats (JSON-style) for programmatic access * **Agent-friendly**: Perfect for LLMs and coding agents to automate your workflow Technical contractors and engineers often track their contract time by combining the CLI with their git history: ask a coding agent to track from a given start (e.g. "from 10:15 today") and it checks the time, runs `git log --since="today 10:15"` to see your commits, then uses `zw journal track` with those commit messages so your journal stays in sync with your actual work.
Technical contractors track contract time with the Zw CLI and git logs

How technical contractors and engineers track contract time: an AI assistant uses date, git log --since="today 10:15" to get your commits, then zw journal track with the commit messages and duration so your journal reflects your development work.

### Core Capabilities * **Time Tracking**: Log work entries to your private journal with descriptions and activity metadata * **Activity Management**: Create, search, and organize activities (Company > Project > Task) * **Timesheet Generation**: Automatically generate timesheets from journal entries * **Workflow Management**: Create approval workflows and link activities * **Configuration**: Manage settings, API tokens, and output preferences ### Get Started Ready to automate your contractor workflow? Start with the [Getting Started guide](/tools-and-integrations/getting-started). *** **Note**: This is a growing section. For detailed command documentation, use the built-in help system in the CLI itself: `zw --help`, `zw journal --help`, etc. # Why the Zipwire CLI is a Big Deal Understanding the Zipwire CLI and the power of command-line automation The Zipwire CLI transforms how technical freelancers and contractors manage their workflow. Instead of context-switching between UI dashboards, it lets you do everything from the command line – just like you do with Git. ## Git for Work You already know this workflow: ```bash git add . git commit -m "Fixed authentication bug" git push origin main ``` With Zipwire, your workflow is: ```bash zw journal track "Fixed authentication bug" -d 2h --activity "Company > Project > Bug Fix" zw timesheet create --from 2024-01-01 --to 2024-01-31 zw timesheet send --id ``` Same mental model. Same simplicity. Different domain. ## The Real Power: Automation & Agents Here's what makes this genuinely powerful: ### 1. **Script Your Entire Contractor Workflow** Automate time tracking, timesheet generation, and submission via shell scripts or Python: ```bash #!/bin/bash # Daily automated workflow zw journal track "$(git log --oneline -1)" -d 8h --activity "Client > Development" # ... later in the day ... zw journal track "Code review and testing" -d 1h --activity "Client > QA" ``` ### 2. **AI Agents & Coding Tools Can Automate Everything** This is the real game-changer. Coding agents like **Claude Code**, **Cursor**, and other AI-powered tools can: * Analyze your git commits and automatically create journal entries * Check your payment status and notify you when you're due to be paid * Set up workflows and link activities * Query your timesheet status and flag issues before submission Here's a real example of Claude Code analyzing your git history and creating journal entries:
Zipwire CLI tracking development time from git logs

A coding agent analyzes your git commits and automatically creates journal entries, reducing manual data entry to zero.

The agents can do much more than just track time. They can: ```bash # Check if you've been paid for submitted timesheets zw timesheet list --status approved # Set up a new workflow for a client zw workflow create --approve-name "Manager" --approve-email "mgr@company.com" # Link your activities to billing workflows zw workflow link --activity "Company > Development > Features" --workflow client-workflow # Check pending timesheets before they expire zw timesheet list --status pending ``` ### 3. **Machine-Readable Output for Programmatic Access** Unlike a web UI, the CLI outputs structured data that agents and programs can parse: ```bash # Agents can query and analyze your data zw journal list --format structured | jq '.entries[] | select(.duration > 480)' zw timesheet list --format structured | jq '.timesheets[] | select(.status == "pending")' ``` This means agents can: * Query your complete time tracking history * Check timesheet and payment status automatically * Validate data before submission * Flag issues and suggest corrections ## Why This Matters for Technical Contractors **You're already comfortable with CLIs.** You use Git, Docker, curl, and command-line tools every day. Why should you have to open a web browser to track your time? **You understand automation.** Most of your frustration with traditional timesheet systems is that they're manual. The CLI lets you automate away the boring parts. **You value integration.** The CLI plays well with other tools – your shell scripts, your agents, your CI/CD pipelines. It's not an island. **You need accuracy.** By tracking time close to when you do the work (via CLI), and letting agents help automate the capture, your timesheets are more accurate than manual entry ever was. ## The Vision Imagine this workflow: 1. **You write code and commit** 2. **A coding agent notices** (via git hooks or webhooks) 3. **The agent asks Zipwire** "What activity is this?" (via API/CLI) 4. **You press enter** (or set it up once) 5. **Time is tracked automatically** 6. **At timesheet deadline, everything is ready to send** No manual data entry. No forgotten hours. No invoice rework. That's not science fiction. That's what the Zipwire CLI makes possible. *** **Ready to try it?** Start with [Getting Started](/tools-and-integrations/getting-started) to set up your first commands. # Getting Started with the CLI Quick start guide for the Zipwire CLI Get up and running with the Zipwire CLI in just a few minutes. {% hint style="info" %} **Prefer MCP clients?** If you'd rather use an MCP-compatible tool instead of the command line, check out [Zipwire's MCP Server](/use-cases/for-agents/zipwire-mcp-server). Connect Claude Desktop, custom agents, or any MCP client to manage timesheets, activities, workflows, and more—no CLI commands needed. {% endhint %} ## Installation The Zipwire CLI is published on [npm](https://www.npmjs.com/package/@zipwire/zw) as **`@zipwire/zw`**. You can install it globally with npm, run it once with npx, or build from source. ### Via NPM (Recommended) Install the CLI globally so the `zw` command is available everywhere: ```bash npm install -g @zipwire/zw ``` You need [Node.js](https://nodejs.org/) and npm installed first. The `-g` flag installs the binary globally and adds it to your PATH. After installation, verify it works: ```bash zw --version ``` To upgrade to the latest version later: ```bash npm update -g @zipwire/zw ``` ### Via npx (No Installation) If you prefer not to install globally, you can run the CLI with **npx**. Each run downloads the package if needed: ```bash npx @zipwire/zw --help npx @zipwire/zw activity list npx @zipwire/zw journal track "Quick entry" -d 1h --activity "Company > Project" ``` Useful for trying the CLI or running it in CI without a global install. ### From Source If you have [Go](https://go.dev/) installed and want to build from source: ```bash git clone https://github.com/zipwireapp/zwcli.git cd zwcli go build -o zw ./cmd/zw sudo mv zw /usr/local/bin/ ``` Or install directly with `go install`: ```bash go install github.com/lukepuplett/zwcli/cmd/zw@latest ``` Ensure your Go bin directory (e.g. `~/go/bin`) is on your PATH so the `zw` command is found. See the [CLI repository](https://github.com/zipwireapp/zwcli) for more details. ## Step 1: Authenticate Before you can use the CLI, you need to authenticate with Zipwire. Choose the option that best fits your situation: ### Option A: Sign Up for a New Account (Recommended for New Users) If you don't have a Zipwire account yet, you can sign up directly from the CLI via WhatsApp: ```bash zw auth signup --name "Your Full Name" --whatsapp "+1234567890" ``` Replace the phone number with your WhatsApp number in E.164 format (e.g., +1 for US, +44 for UK). **What happens automatically:** 1. Your API token is stored and ready to use immediately 2. A WhatsApp message from Zipwire's bot arrives with onboarding instructions 3. Follow the bot's prompts in WhatsApp to complete your account activation Once you receive the bot's welcome confirmation in WhatsApp, return to the CLI and start using it—nothing else to do. Your token is already set up and working. 💡 **Tip**: Check your WhatsApp spam folder if you don't see the bot's message immediately. ### Option B: Browser Login (For Existing Users) If you already have a Zipwire account, log in via your browser: ```bash zw auth login ``` This will open your browser automatically, where you can sign in with your passkey or wallet. When complete, your authentication token is saved to `~/.config/zw/config.yaml`. ### Option C: Manual Token If you have an API token, you can set it manually: ```bash zw auth set-token your-api-token ``` ### Check Authentication Status ```bash zw auth status ``` You should see something like: ``` ↓ Authentication status Authenticated Token: zw_... ``` ## Step 2: Your First Command Let's verify everything is working and list your activities: ```bash zw activity list ``` This shows all the activities you've created in Zipwire. Activities follow the structure: `Company > Project > Activity` If you don't have any activities yet, create one: ```bash zw activity create "My Company > First Project > Development" ``` ## Step 3: Track Your First Time Entry Log some time to your journal: ```bash zw journal track "Initial setup and exploration" -d 30m --activity "My Company > First Project > Development" ``` This creates a journal entry with: * Description: "Initial setup and exploration" * Duration: 30 minutes * Activity: "My Company > First Project > Development" View your recent entries: ```bash zw journal list --today ``` ## Accessing Zipwire on the Web Once authenticated, you can generate a magic link to access Zipwire's website without needing to log in again: ```bash zw auth login-link ``` This creates a temporary magic link that you can use in your browser for direct website access. ## What's Next? You now have the basics working! Here's what you can explore: * [**Authentication & Security**](/tools-and-integrations/authentication) – Learn about tokens, config files, and security best practices * [**Configuration**](/tools-and-integrations/configuration) – Customize your CLI settings * [**Common Workflows**](/tools-and-integrations/workflows) – See practical examples (create timesheet, submit for approval, track time, etc.) ## Need Help? The CLI has built-in help for every command: ```bash zw --help # General help zw journal --help # Help for journal commands zw journal track --help # Help for specific command ``` Or explore the [CLI repository](https://github.com/zipwireapp/zwcli) for source code and additional documentation. *** **Pro Tip**: Use `zw --help` frequently. The CLI is self-documenting and often the most up-to-date reference. # Authentication & Security Authentication and token management for the Zipwire CLI The Zipwire CLI uses API tokens for authentication. This guide covers how to authenticate, manage tokens securely, and troubleshoot auth issues. ## Authentication Methods ### Sign Up for a New Account (Recommended for New Users) If you don't have a Zipwire account yet, create one directly from the CLI: ```bash zw auth signup --name "Your Full Name" --whatsapp "+1234567890" ``` Replace the phone number with your WhatsApp number in [E.164 format](https://en.wikipedia.org/wiki/E.164) (e.g., +1 for US, +44 for UK). **What happens:** 1. Your API token is automatically generated and saved to `~/.config/zw/config.yaml` 2. A WhatsApp message from Zipwire's bot arrives with onboarding instructions 3. Follow the bot's prompts to complete your account activation Once you receive the bot's welcome confirmation in WhatsApp, you're all set. Return to the CLI and start using it immediately—your token is already in place and ready to go. No additional setup needed. ### Browser-Based Login (For Existing Users) If you already have a Zipwire account, login via your browser: ```bash zw auth login ``` This will: 1. Open your default browser automatically 2. Redirect you to Zipwire's login page 3. Ask you to sign in with your passkey or wallet 4. Generate an API token 5. Save it automatically to `~/.config/zw/config.yaml` ### Manual Token Entry If you already have an API token, set it directly: ```bash zw auth set-token your-api-token ``` To get an API token: 1. Log into Zipwire web app 2. Go to Account Settings 3. Find the API Tokens section 4. Generate or copy your token ## Checking Your Authentication Status ```bash zw auth status ``` If authenticated, you'll see: ``` ↓ Authentication status Authenticated Token: zw_... ``` If not authenticated: ``` ↓ Authentication status Not authenticated Recommended if you don't have an account yet: zw auth signup --name "Your Name" --whatsapp "+1234567890" Only if you already have an account: zw auth login ``` ## Accessing Zipwire on the Web Generate a magic login link to access Zipwire's website without needing to log in again: ```bash zw auth login-link ``` This creates a temporary magic link that you can use in your browser for direct website access. No need to re-authenticate. ## Logging Out Clear your stored token: ```bash zw auth logout ``` This removes the token from your config file. You'll need to authenticate again before using the CLI. ## Token Management ### Where Your Token is Stored Your token is stored in: ``` ~/.config/zw/config.yaml ``` **Important**: This file contains sensitive information. Protect it like you would a password or private key. ### Security Best Practices 1. **Never commit tokens to version control** ```bash # Add to .gitignore echo "~/.config/zw/" >> ~/.gitignore ``` 2. **Use environment variables in scripts** ```bash export ZW_API_TOKEN="your-token" zw auth login --token $ZW_API_TOKEN ``` 3. **Rotate tokens regularly** * Generate a new token * Update your config * Delete the old token from the web app 4. **Use different tokens for different contexts** * One token for your local development * A different token for CI/CD pipelines * Separate tokens for different machines if needed ### Using Tokens in CI/CD For automated workflows (GitHub Actions, GitLab CI, etc.), use environment variables: ```yaml # GitHub Actions example jobs: track-time: runs-on: ubuntu-latest steps: - run: zw auth login --token ${{ secrets.ZW_API_TOKEN }} - run: zw journal track "CI/CD job" -d 1h ``` ## Troubleshooting Authentication ### "Invalid API Key" Error Verify your token: 1. Check the token in your config: `cat ~/.config/zw/config.yaml` 2. Ensure it hasn't expired 3. Generate a new token in the web app if needed 4. Update with: `zw auth login --token ` ### "Not Authenticated" Error You need to authenticate first: ```bash zw auth login ``` ### Token Accidentally Leaked If you accidentally expose your token (e.g., in a commit): 1. Delete the token immediately from your config 2. Revoke it in the web app (Account Settings > API Tokens) 3. Generate a new token 4. Update your config with the new token ### Multiple Machines Each machine needs its own authentication. Authenticate on each machine separately: ```bash # On machine 1 zw auth login # On machine 2 zw auth login ``` You can use the same API token on multiple machines, or create separate tokens for isolation. ## Config File Format The CLI stores configuration in YAML format: ```yaml # ~/.config/zw/config.yaml api-base-url: https://api.zipwire.io api-token: zw_your_token_here_... output-format: human no-color: false ``` You can edit this file directly if needed, but it's safer to use `zw auth login` or `zw config` commands. *** For more configuration options, see the [Configuration guide](/tools-and-integrations/configuration). # Configuration Configuring the Zipwire CLI for your workflow The Zipwire CLI stores configuration in a YAML file. This guide covers the available settings and how to customize them for your workflow. ## Config File Location Your configuration is stored at: ```bash ~/.config/zw/config.yaml ``` To view your current configuration: ```bash zw config show ``` ## Configuration Options ### API Settings #### `api-base-url` The API endpoint the CLI connects to. ```yaml api-base-url: https://api.zipwire.io ``` Usually you don't need to change this, but it's useful if you're running a local Zipwire instance. #### `api-token` Your authentication token. Set via `zw auth login`. ```yaml api-token: zw_your_token_... ``` **Never commit this to version control.** Use environment variables in CI/CD instead. ### Output Settings #### `output-format` Controls the output format for all commands. ```yaml output-format: human ``` Options: * `human` – Pretty-printed, hierarchical output with colors (default) * `structured` – Machine-readable key-value format Override per-command: ```bash zw activity list --format structured ``` #### `no-color` Disable colored output. ```yaml no-color: false ``` Options: * `false` – Colors enabled (default) * `true` – Disable all colors Override per-command: ```bash zw activity list --no-color ``` The CLI automatically detects if output is being piped and disables colors when appropriate. ## Customizing Configuration ### Via Command Line Use the `zw config` command to update settings: ```bash zw config set output-format structured zw config show ``` ### Manual Editing Edit `~/.config/zw/config.yaml` directly: ```yaml api-base-url: https://api.zipwire.io api-token: zw_... output-format: human no-color: false ``` ## Using Environment Variables Override config settings with environment variables: ```bash # Override token export ZW_API_TOKEN="zw_..." # Override output format export ZW_OUTPUT_FORMAT="structured" # Override base URL export ZW_API_BASE_URL="https://local.zipwire.io" ``` This is useful for CI/CD pipelines and scripts: ```bash #!/bin/bash export ZW_API_TOKEN="$GITHUB_TOKEN" export ZW_OUTPUT_FORMAT="structured" zw journal list | jq '.entries[] | select(.duration > 480)' ``` ## Per-Command Overrides Most commands accept flags to override config settings: ```bash # Override output format for this command zw activity list --format structured # Disable colors for this command zw journal list --no-color # Specify a config file zw activity list --config ~/.config/zw/custom-config.yaml ``` Use `--help` to see all available flags for a command: ```bash zw journal track --help ``` ## Multiple Configurations If you need different configurations for different contexts (work vs. personal, different clients, etc.), create multiple config files: ```bash # Create alternate config cp ~/.config/zw/config.yaml ~/.config/zw/work-config.yaml # Edit as needed vim ~/.config/zw/work-config.yaml # Use it zw activity list --config ~/.config/zw/work-config.yaml ``` ## Smart Parsing The CLI has smart parsing for common values: ### Activity Names Activities use the hierarchy format: ``` "Company > Project > Activity Name" ``` Must be quoted if they contain spaces or special characters: ```bash # ❌ Wrong zw journal track Work on bug > Development # ✅ Right zw journal track "Work on bug" --activity "Company > Development" ``` ### Dates Dates are parsed intelligently: ```bash zw journal list --from today zw journal list --from yesterday zw journal list --from Monday zw journal list --from "2024-01-01" zw journal list --from "2025-W10" # ISO week format ``` ### Durations Durations are flexible: ```bash zw journal track "Work" -d 45m # 45 minutes zw journal track "Work" -d 2h # 2 hours zw journal track "Work" -d 1.5h # 1 hour 30 minutes zw journal track "Work" -d 2h30m # 2 hours 30 minutes zw journal track "Work" -d 1d # 1 day (8 hours) ``` ## Troubleshooting ### Config File Not Found If the CLI can't find your config file: ```bash mkdir -p ~/.config/zw zw auth login ``` ### Settings Not Applied Make sure you: 1. Saved the file correctly 2. Using the right file path 3. Not overriding with command-line flags Check your active config: ```bash zw config show ``` ### Reset to Defaults Remove the config file and re-authenticate: ```bash rm ~/.config/zw/config.yaml zw auth login ``` *** For more help, use the built-in help system: ```bash zw config --help zw --help ``` # Common Workflows Common workflows and examples for the Zipwire CLI These examples show how to use the Zipwire CLI for typical contractor workflows. ## Workflow 1: Daily Time Tracking Track your work throughout the day and view what you've logged. ```bash # Morning: Log your first task zw journal track "Fixed authentication bug in login flow" -d 2h --activity "Client A > Development > Bug Fixes" # Midday: Log another task zw journal track "Code review for pull requests" -d 1h --activity "Client A > Development > Code Review" # Afternoon: Log your final task zw journal track "Documentation updates" -d 1.5h --activity "Client A > Documentation" # End of day: Review what you tracked zw journal list --today # View summary of hours per activity zw journal status ``` ## Workflow 2: Create and Submit a Timesheet Once you have entries in your journal, create a timesheet and send it for approval. ```bash # Create a timesheet for the past week zw timesheet create --from last-Monday --to today # View the timesheet you just created zw timesheet list --recent # Verify the details zw timesheet show --id # Send it for approval (requires workflow to be configured) zw timesheet send --id # Check status zw timesheet list --status pending ``` ## Workflow 3: Manage Activities Create and organize your project activities. ```bash # Create a new client/project activity structure zw activity create "Client A > Development > Features" zw activity create "Client A > Development > Bug Fixes" zw activity create "Client A > QA > Testing" # Search for activities zw activity search "Bug Fixes" # View all activities in hierarchical format zw activity list --style hierarchical # View as flat list zw activity list --style flat # See recently used activities zw activity recent ``` ## Workflow 4: Automated Daily Tracking (Script) Automate time tracking in a shell script. Useful for scheduled jobs or integrations. ```bash #!/bin/bash # daily_tracking.sh - Log time from git commits API_TOKEN="zw_your_token" # Get today's git commits and log them git log --all --oneline --since="24 hours ago" | while read commit; do # Extract commit message msg=$(echo "$commit" | cut -d' ' -f2-) # Log to Zipwire (assumes 1 hour per commit) zw journal track "$msg" -d 1h --activity "My Company > Development > Coding" done echo "Daily time entries logged from git commits" ``` Run this daily: ```bash # Make executable chmod +x daily_tracking.sh # Run manually ./daily_tracking.sh # Or schedule with cron (runs daily at 5 PM) # Add to crontab: 17 * * * * /path/to/daily_tracking.sh ``` ## Workflow 5: Structured Output for Integration Use structured output to integrate with other tools or scripts. ```bash # Get recent entries as structured data zw journal list --format structured --recent # Parse with jq to get total hours zw journal list --format structured --recent | \ grep "DURATION" | \ awk '{sum += $2} END {print "Total hours: " sum/60}' # Export to CSV-like format zw journal list --format structured | \ grep -E "ACTIVITY|DESCRIPTION|DURATION" | \ paste - - - | \ sed 's/ACTIVITY: //;s/DESCRIPTION: //;s/DURATION: //' ``` ## Workflow 6: Multiple Client Setup Working for multiple clients? Create separate activity trees and track time accordingly. ```bash # Create activities for each client zw activity create "Client A > Development > Features" zw activity create "Client A > Development > Support" zw activity create "Client B > Design > UI/UX" zw activity create "Client B > Development > Backend" # Track time per client zw journal track "Built new feature XYZ" -d 4h --activity "Client A > Development > Features" zw journal track "Fixed production bug" -d 2h --activity "Client A > Development > Support" zw journal track "Designed login flow" -d 3h --activity "Client B > Design > UI/UX" # View hours per client zw journal list --format structured | grep -E "ACTIVITY|DURATION" ``` ## Workflow 7: Git Integration Automatically log time when you push code or analyze your git history. The CLI can parse your git commits and create time entries automatically: ```bash #!/bin/bash # daily_tracking.sh - Analyze git history and create journal entries git log --all --oneline --since="24 hours ago" | while read commit; do msg=$(echo "$commit" | cut -d' ' -f2-) zw journal track "$msg" -d 1h --activity "My Company > Development > Coding" done ``` Here's a real-world example of this in action:
Zipwire CLI tracking from git logs

The CLI automatically creates journal entries from your git history, turning your development work into tracked time entries without manual data entry.

You can also hook into git events to automatically log time: ```bash #!/bin/bash # .git/hooks/post-push - Log time on git push # This runs after you push to git # Log a "code commit" entry zw journal track "Pushed code changes to repository" \ -d 30m \ --activity "My Company > Development > Git Operations" echo "Time logged for code push" ``` To set this up: ```bash # Create hooks directory mkdir -p .git/hooks # Create and make executable cat > .git/hooks/post-receive << 'EOF' #!/bin/bash zw journal track "Code pushed" -d 30m --activity "My Company > Development > Git Operations" EOF chmod +x .git/hooks/post-receive ``` ## Workflow 8: Querying Your Data Use structured output to query and analyze your time entries. ```bash # List all entries and parse with jq zw journal list --format structured | jq -r '.entries' # Find all entries for a specific activity zw journal list --format structured | \ jq '.entries[] | select(.activity | contains("Bug Fixes"))' # Calculate total time spent per activity zw journal list --format structured | \ jq -r '[.entries[] | {activity, duration}] | group_by(.activity) | map({activity: .[0].activity, total: (map(.duration) | add)})' ``` ## Tips for Automation 1. **Store tokens securely**: Use environment variables, not hardcoded values 2. **Handle errors**: Check exit codes in scripts 3. **Use structured output**: Makes parsing and integration much easier 4. **Test first**: Run commands manually before automating them 5. **Log activities**: Keep records of what automation is doing 6. **Use cron carefully**: Schedule during off-hours if possible ## Next Steps * Explore the full command reference with `zw --help` * Set up a [Configuration](/tools-and-integrations/configuration) that works for your workflow * Integrate the CLI with your existing tools and CI/CD pipelines * Consider how AI agents or coding assistants could help automate your time tracking *** For detailed command documentation, use the built-in help: ```bash zw journal --help zw timesheet --help zw activity --help ``` # Managing & Consolidating Activities Manage, organize, and consolidate your activities over time As you use the Zipwire CLI, you'll accumulate activities. Over time, these can become sprawling, inconsistent, or redundant. This guide covers how to organize and consolidate them. ## Why Activity Management Matters After months of tracking time, you might have: * **Duplicates**: "Frontend Development" and "Frontend > Development" * **Typos**: "Meeetings" instead of "Meetings" * **Inconsistent naming**: "Bug Fixes", "Bug Fixing", "Bug Fix" * **Too many activities**: Staffing agencies often prefer fewer, broader categories * **Historical cruft**: Old client names or abandoned projects The good news: the CLI lets you consolidate and rename activities **without losing any data**. All your journal entries automatically update. ## Finding Activities ### List All Activities ```bash # View all activities zw activity list # View in hierarchical format zw activity list --style hierarchical # View as flat list (default) zw activity list --style flat ``` ### Search for Activities ```bash # Search by name zw activity search "meeting" # Search by project zw activity search "ABC Corp" # Search by activity zw activity search "bug" ``` ### See Recently Used ```bash # Most recently used activities zw activity recent # Last 2 weeks zw activity recent --period 2w # Last 30 days zw activity recent --period 30d ``` ## Consolidating Activities ### Basic Rename Rename a single activity: ```bash zw activity rename --from "Old Activity Name" --to "New Activity Name" ``` Example: ```bash zw activity rename --from "Meeetings" --to "Meetings" ``` ### Merging Multiple Activities Merge several activities into one. This is useful when you have duplicates or variations: ```bash zw activity rename \ --from "Frontend Development" \ --from "Frontend > Development" \ --from "FE Dev" \ --to "Client A > Frontend > Development" ``` This command: 1. Takes all entries from the three source activities 2. Moves them to the target activity 3. Removes the old activities 4. Updates all journal entries automatically ### Using Activity Keys For programmatic use (scripts, agents), you can use activity keys instead of names: ```bash # Get activity keys from list zw activity list --format structured # Merge using keys zw activity rename \ --from "abe_jnla_ac71x94j8smyi0fu" \ --from "abe_jnla_bc82y05k9t" \ --to "abe_jnla_cd93z16l0u" ``` ### Important: Quoting Activity Names Activity names with spaces or the `>` character **must be quoted**: ```bash # ❌ Wrong - shell will interpret the > zw activity rename --from Client > Development --to Client > Dev # ✅ Correct - quoted names zw activity rename --from "Client > Development" --to "Client > Dev" ``` ## What Happens During Consolidation When you merge activities, the CLI: 1. **Consolidates** all journal entries from source activities to the target 2. **Updates** every affected journal entry automatically 3. **Removes** the old activities once merged 4. **Reports** what was changed: * Number of entries updated * Activities removed * Breakdown per source activity Example output: ``` ↓ Activity consolidation complete ▦ Target Activity • Client A > Development > Features ▦ Merged Activities • 45 entries from "Client A > Dev > Features" • 12 entries from "Frontend Features" ✓ 57 total entries updated ✓ 2 activities removed ``` ## Common Consolidation Scenarios ### Scenario 1: Fixing Typos You've been tracking time with a typo in an activity name: ```bash zw activity rename --from "Meetigns" --to "Meetings" ``` All 23 entries under "Meetigns" are automatically updated to "Meetings". ### Scenario 2: Handling Agency Constraints Your staffing agency prefers fewer, broader categories. Instead of: ``` Client A > Development > Features Client A > Development > Bug Fixes Client A > Development > Code Review Client A > QA > Testing Client A > QA > Automation ``` Consolidate to: ```bash zw activity rename \ --from "Client A > Development > Features" \ --from "Client A > Development > Bug Fixes" \ --from "Client A > Development > Code Review" \ --to "Client A > Development" zw activity rename \ --from "Client A > QA > Testing" \ --from "Client A > QA > Automation" \ --to "Client A > QA" ``` Now all entries are organized under just two high-level activities. ### Scenario 3: Consolidating Duplicates You've been inconsistent with naming. Fix it: ```bash zw activity rename \ --from "Frontend Development" \ --from "Frontend > Development" \ --from "FE Dev" \ --from "Frontend Dev Work" \ --to "Client A > Frontend > Development" ``` All 127 entries across four variations are merged into one activity. ### Scenario 4: Cleaning Up Old Clients You finished a project and want to consolidate historical entries: ```bash zw activity rename \ --from "Old Client > Project Alpha > Development" \ --from "Old Client > Project Alpha > QA" \ --from "Old Client > Project Alpha > Meetings" \ --to "Archive > Old Client > Project Alpha" ``` All historical entries are grouped under an "Archive" company for easy reference. ## Before & After: A Real Example **Before consolidation** (scattered activities): ```bash $ zw activity list • ABC Corp > Development > Features • ABC Corp > Dev > Bug Fixes • ABC Corp > Frontend Development • ABC Corp > Frontend > Features • ABC Corp > Meetings • ABC Corp > Meeting Notes • Personal > General > General • Personal > Admin > Admin Work • Personal > Admin > General ``` **Consolidation commands:** ```bash # Fix ABC Corp inconsistencies zw activity rename \ --from "ABC Corp > Dev > Bug Fixes" \ --to "ABC Corp > Development > Bug Fixes" zw activity rename \ --from "ABC Corp > Frontend Development" \ --from "ABC Corp > Frontend > Features" \ --to "ABC Corp > Frontend > Development" zw activity rename \ --from "ABC Corp > Meeting Notes" \ --to "ABC Corp > Meetings" # Consolidate Personal admin zw activity rename \ --from "Personal > Admin > Admin Work" \ --from "Personal > Admin > General" \ --to "Personal > Admin" ``` **After consolidation** (clean and organized): ```bash $ zw activity list • ABC Corp > Development > Features • ABC Corp > Development > Bug Fixes • ABC Corp > Frontend > Development • ABC Corp > Meetings • Personal > General > General • Personal > Admin ``` Much cleaner! ## Tips & Best Practices ### Plan Before Consolidating Think about your structure before renaming: ```bash # Decide on a consistent format first # Option A: Company > Project > Activity # Option B: Company > Activity > Subactivity # Option C: Client > Billable Category ``` ### Check Entry Counts First See how many entries are affected: ```bash zw activity search "old-name" # Shows all entries so you know the impact ``` ### Consolidate in Batches If you have many activities, do a few at a time and verify: ```bash # Consolidate one client first zw activity rename --from "Client A Old Name" --to "Client A > Development" # Verify it worked zw activity search "Client A" # Then move to the next batch zw activity rename --from "Client B Old Name" --to "Client B > Development" ``` ### Keep Hierarchies Consistent Use consistent separators and levels: ```bash # ✅ Consistent "Company > Project > Task Type" "Company > Project > Task Type" # ❌ Inconsistent "Company > Project > Task Type" "Company - Project - Task Type" "Company/Project/Task" ``` ### Use Codes for Broad Categories If you work for multiple agencies or have many clients, consider using codes: ```bash zw activity rename \ --from "Old Agency Name > Development" \ --to "AGENCY_CODE > Development" # E.g., "A001 > Development", "A002 > Development" ``` ## Troubleshooting ### "Activity Not Found" The activity name doesn't exist exactly as written. Check: ```bash # Search for it zw activity search "part-of-name" # List all activities zw activity list ``` ### Forgot to Quote the Name ```bash # ❌ This won't work zw activity rename --from Client > Development --to New Name # ✅ Always quote names with > or spaces zw activity rename --from "Client > Development" --to "New Name" ``` ### Want to Undo a Merge The merge is permanent, but you can: 1. Create a new activity with the old name 2. Move entries back using a rename ```bash # Create the old activity again zw activity create "Old Activity Name" # Move entries that need it (you'll need to do this via the API or web app) ``` *** For more on tracking time and working with activities, see: * [Getting Started](/tools-and-integrations/getting-started) * [Common Workflows](/tools-and-integrations/workflows) * [Configuration](/tools-and-integrations/configuration) Use the built-in help anytime: ```bash zw activity --help zw activity rename --help ``` # ProofPack & Agent Delegation ProofPack and agent delegation for developers and service providers ProofPack is a library and format that enables services to verify that agents are authorized by real humans, and to accept selective identity claims without seeing full personal data. If you're building a service that accepts requests from agents, or if you're building an agent that needs to prove authorization, this guide is for you. ## The Problem: Distinguishing Bots from Authorized Agents Every day, services face a dilemma: * **Requests from agents**: Could be legitimate (human-authorized) or malicious (bot) * **Traditional authentication**: Requires the human to log in repeatedly (bad UX for agents) * **API tokens**: Easy to steal, don't prove human authorization * **OAuth to social providers**: Requires centralized identity providers, slow, privacy-invasive **ProofPack solves this:** Agents carry cryptographic proof that a verified human authorized them. Services verify locally, with zero latency and full privacy. ## What is ProofPack? ProofPack is a **JSON format + library** for: 1. **Selective Disclosure**: Share only specific identity claims (age, nationality, AML status) without full ID 2. **Cryptographic Verification**: Merkle trees prove data hasn't been tampered with 3. **Delegation Proof**: IsDelegate attestations prove human → agent authorization 4. **On-Chain Trust**: All attestations anchor to blockchain (EAS on Base) for immutable verification For the full structure of a ProofPack (Merkle tree, attestation reference, JWS envelope), see [Understanding ProofPack](/fundamentals/security/understanding-proofpack). ## The Two Verification Paths ### Path 1: Quick Check (Wallet Only) **Question:** "Is this wallet acting for a verified human?" Use the agent's wallet address and `verifyByWallet()`. No JWS required. {% content-ref url="/pages/WV1z2z2wEXngjQrNAb9N" %} [Path 1: Wallet-only (JavaScript)](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) {% endcontent-ref %} **Use cases:** MCP servers, connection handshakes, rate limiting, quick bot detection. **Alternative: Simple REST API** — If you prefer not to use the library, see [IsDelegate REST API](/fundamentals/security/attestations/is-delegate-rest-api). It requires trusting Zipwire's validation; for independent verification use ProofPack. ### Path 2: Full Proof (With Claims) **Question:** "Is this agent authorized by a human, and does that human meet these criteria (age, nationality, AML)?" The agent sends a proof in the request header. **ProofPack supports both JWS and JWT** (see [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws) if those terms are new to you); use the standard `Authorization: Bearer ` pattern—any client or gateway that handles Bearer tokens works. The token contains specific identity claims, Merkle proofs, and the delegation chain. Your service verifies it and reads the revealed claims. {% content-ref url="/pages/vHjbCV4bV7welWu86ldI" %} [Path 2: JWS with claims (JavaScript)](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript) {% endcontent-ref %} **Use cases:** Payments, regulated services (KYC, compliance), premium features, any service that needs specific identity attributes. ## Installation See [ProofPack Examples → Installation](/tools-and-integrations/proofpack-agent-delegation/installation) for npm, dotnet, and Rust. ## Setting Up Verification Configure trusted roots and create the verifier/reader: [Quick setup: verification context](/tools-and-integrations/proofpack-agent-delegation/quick-setup-verification-context). ## Integration Examples * **Express.js** — Middleware for `x-agent-wallet` or `Authorization: Bearer ` (JWS or JWT): [Express.js middleware](/tools-and-integrations/proofpack-agent-delegation/express-middleware) * **ASP.NET Core** — Controller with wallet and JWS/JWT verification: [ASP.NET Core agent verification](/tools-and-integrations/proofpack-agent-delegation/aspnet-core-agent-verification) ## Common Use Cases Time tracking, payment verification, compliance (KYC/AML), and MCP server integration: [Common use cases](/tools-and-integrations/proofpack-agent-delegation/common-use-cases). ## Troubleshooting ### "Agent not authorized by human" **Causes:** * Agent's wallet has no IsDelegate attestations * IsDelegate was revoked * IsDelegate points to an untrusted root * IsDelegate is expired or invalid **Fix:** * Verify the human created the IsDelegate on [EAS](https://base.easscan.org) * Check the refUID points to a valid IsAHuman attestation * Check the Zipwire attester address matches your trusted roots ### "Invalid JWS signature" **Causes:** * JWS is tampered with * Agent didn't sign it with their key * JWS format is wrong **Fix:** * Verify the JWS comes directly from the agent * Check the agent signed with their private key * Verify JWS format: header.payload.signature ### "Merkle root mismatch" **Causes:** * Claims in the proof don't match on-chain attestation * Proof was redacted incorrectly * Attestation and proof were created separately **Fix:** * Verify the agent created the proof using the correct Mint API * Check the Merkle root in the proof matches the on-chain attestation * Ensure the agent is using the latest ProofPack library ## Security Best Practices 1. **Validate early**: Check agent authorization at the API entry point 2. **Trust roots carefully**: Only trust attesters you control or deeply trust 3. **Check revocation**: Revoked delegations should fail validation 4. **Use HTTPS**: Always transport proof tokens (JWS or JWT) over secure connections 5. **Log verifications**: Keep audit logs of what agents did 6. **Rate limit by verification**: Humans (verified) can request more than unverified agents ## Performance & Latency * **Wallet-only check**: <100ms (no RPC calls needed with EAS GraphQL caching) * **Full proof verification**: <200ms (local Merkle proof validation) * **No IdP calls**: Zero latency waiting for external identity providers ProofPack verification is **fast enough for request-path authentication**. ## The Future: Chained Agents As agents become more sophisticated, sub-delegation becomes important: ``` Human (IsAHuman) ↓ IsDelegate Primary Agent ↓ IsDelegate Task-Specific Sub-Agent ↓ IsDelegate Analysis Sub-Agent ``` ProofPack validates the entire chain, so services can trust requests from deep sub-agents. *** ## Related Documentation * [ProofPack Examples](/tools-and-integrations/proofpack-agent-delegation/proofpack-examples) — copy-paste code for Path 1, Path 2, Express, ASP.NET Core, setup, use cases * [IsDelegate Attestations](/fundamentals/security/attestations/isdelegate-agent-delegation) * [For AI Agents](/use-cases/for-agents) * [ProofPack GitHub](https://github.com/zipwireapp/ProofPack) * [Zipwire Attest](https://zipwire.io/attest) *** **Get Started:** 1. Install ProofPack library 2. Configure trusted roots 3. Add verification middleware to your API 4. Start accepting authorized agents! **Questions?** Check the [ProofPack docs](https://github.com/zipwireapp/ProofPack) or contact Zipwire support. # ProofPack Examples Canonical code examples for ProofPack and agent verification Central place for copy-paste examples. The main guide links here instead of inlining code. | Example | Description | | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | | [Installation](/tools-and-integrations/proofpack-agent-delegation/installation) | npm, dotnet, Rust install commands | | [Quick setup: verification context](/tools-and-integrations/proofpack-agent-delegation/quick-setup-verification-context) | Configure trusted roots and create verifier/reader (JS + C#) | | [Path 1: Wallet-only (JavaScript)](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) | `verifyByWallet()` — no JWS | | [Path 2: JWS with claims (JavaScript)](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript) | Verify JWS or JWT and read claims | | [Express.js middleware](/tools-and-integrations/proofpack-agent-delegation/express-middleware) | Middleware for `x-agent-wallet` or `Authorization: Bearer ` | | [ASP.NET Core](/tools-and-integrations/proofpack-agent-delegation/aspnet-core-agent-verification) | Controller with wallet and JWS/JWT verification | | [Common use cases](/tools-and-integrations/proofpack-agent-delegation/common-use-cases) | Time tracking, payment, compliance, MCP patterns | Main guide: [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). New to JWS/JWT? See [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws). New to ProofPack itself? See [Understanding ProofPack](/fundamentals/security/understanding-proofpack). # Path 1: Wallet-only (JavaScript) ProofPack Path 1 — wallet-only verification in JavaScript **Question:** "Is this wallet acting for a verified human?" Use this when you only need a yes/no (e.g. MCP servers, connection handshakes, rate limiting). No JWS or JWT required. The ProofPack library uses `IsDelegateAttestationVerifier` and a config object (`delegationSchemaUid`, `acceptedRoots`, `preferredSubjectSchemas`, `schemaPayloadValidators`, `maxDepth`). For the full config shape and schema UIDs, see the [ProofPack repo](https://github.com/zipwireapp/ProofPack) — [JavaScript Ethereum: GraphQL lookup and verifyByWallet](https://github.com/zipwireapp/ProofPack/blob/main/javascript/packages/ethereum/README.md#graphql-lookup-and-verifybywallet-no-rpc). ```javascript import { IsDelegateAttestationVerifier } from '@zipwire/proofpack-ethereum'; import { PrivateDataPayloadValidator } from '@zipwire/proofpack-ethereum'; // Full config (delegationSchemaUid, acceptedRoots, preferredSubjectSchemas, schemaPayloadValidators) — see ProofPack repo const config = { delegationSchemaUid: '0x...', // IsDelegate schema UID acceptedRoots: [{ schemaUid: '0x...', attesters: ['0xZipwireAttester...'] }], preferredSubjectSchemas: [{ schemaUid: '0x...', attesters: ['0xZipwire...'] }], schemaPayloadValidators: new Map([['0x...', new PrivateDataPayloadValidator()]]), maxDepth: 32 }; const verifier = new IsDelegateAttestationVerifier({ chains: ['base-sepolia', 'base'] }, config); const result = await verifier.verifyByWallet('0xAgentWallet...'); if (result.isValid) { console.log('Agent is human-authorized'); } else { console.log('Agent is not in a valid delegation chain:', result.message); } ``` `verifyByWallet` returns an **AttestationResult** (with `isValid`, `message`, `reasonCode`), not a plain boolean. For the REST API alternative, see [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation) and [IsDelegate REST API](/fundamentals/security/attestations/is-delegate-rest-api). # Path 2: JWS with claims (JavaScript) ProofPack Path 2 — verifying JWS or JWT with claims in JavaScript **Question:** "Is this agent authorized by a human, and does that human meet these criteria (age, nationality, AML)?" The agent sends a ProofPack proof as **JWS or JWT** (see [Understanding JWT and JWS](/fundamentals/security/understanding-jwt-and-jws) for the difference) in the standard `Authorization: Bearer ` header. Your service verifies it and reads the revealed claims. ```javascript import { AttestedMerkleExchangeReader } from '@zipwire/proofpack'; const reader = new AttestedMerkleExchangeReader(); const result = await reader.readAsync( jws, // From Authorization: Bearer verificationContext ); if (result.isValid) { const claims = result.document.merkleTree.leaves; // Use verified claims if (claims.nationality === 'UK' && claims.age >= 18) { // Process the request const agent = { wallet: result.agentWallet, human: result.humanWallet, authorizedAt: result.delegationDate, claims: claims }; await processRequest(agent); } } ``` You must configure `verificationContext` (trusted roots, schemas). See [Quick setup: verification context](/tools-and-integrations/proofpack-agent-delegation/quick-setup-verification-context) and [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). # Express.js middleware Express.js middleware for agent authorization (wallet or JWS/JWT) Middleware that accepts either `x-agent-wallet` (Path 1) or `Authorization: Bearer ` (Path 2). ProofPack supports both JWS and JWT; standard Bearer token handling applies. **Implementation note:** The wallet-only path uses ProofPack’s `IsDelegateAttestationVerifier` from `@zipwire/proofpack-ethereum`; the full-proof path uses `AttestedMerkleExchangeReader` and a verification context from `@zipwire/proofpack`. For the exact verifier config and context setup, see the [Path 1 example](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) and the [ProofPack repo](https://github.com/zipwireapp/ProofPack). ```javascript import express from 'express'; import { IsDelegateAttestationVerifier } from '@zipwire/proofpack-ethereum'; import { AttestedMerkleExchangeReader } from '@zipwire/proofpack'; const app = express(); // Verifier: use full config (delegationSchemaUid, acceptedRoots, etc.) — see Path 1 and ProofPack repo const verifier = new IsDelegateAttestationVerifier({ chains: ['base-sepolia', 'base'] }, config); const reader = new AttestedMerkleExchangeReader(); // Middleware: Verify agent authorization app.use(async (req, res, next) => { const agentWallet = req.headers['x-agent-wallet']; const authHeader = req.headers['authorization']; if (!agentWallet && !authHeader) { return res.status(400).json({ error: 'Agent wallet or JWS/JWT required' }); } try { if (authHeader?.startsWith('Bearer ')) { // Full proof path const token = authHeader.slice(7); const result = await reader.readAsync(token, verificationContext); if (!result.isValid) { return res.status(403).json({ error: 'Invalid authorization proof' }); } req.agent = { wallet: result.agentWallet, claims: result.document.merkleTree.leaves, verified: true }; } else if (agentWallet) { // Wallet-only check (returns AttestationResult with .isValid) const result = await verifier.verifyByWallet(agentWallet); if (!result.isValid) { return res.status(403).json({ error: 'Agent not authorized by human' }); } req.agent = { wallet: agentWallet, verified: true }; } next(); } catch (err) { res.status(500).json({ error: 'Verification failed', details: err.message }); } }); // Your API endpoints now have req.agent with verified authorization app.post('/api/time-tracking/log', (req, res) => { console.log(`Agent ${req.agent.wallet} logging time`); // Process request }); app.get('/api/payments/status', (req, res) => { if (!req.agent.claims?.verifiedHuman) { return res.status(403).json({ error: 'Payment queries require human verification' }); } // Return payment status }); ``` Configure `config` (verifier) and `verificationContext` (reader) per the [ProofPack repo](https://github.com/zipwireapp/ProofPack) and [Path 1](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) / [Quick setup](/tools-and-integrations/proofpack-agent-delegation/quick-setup-verification-context). Full guide: [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). # ASP.NET Core agent verification ASP.NET Core controller for agent authorization (wallet and JWS/JWT) Example controller that verifies agents by wallet (Path 1) or by JWS/JWT (Path 2). The real API uses `IsDelegateAttestationVerifier` (with `IsDelegateVerifierConfig` and `IsDelegateVerifierOptions`) and `AttestedMerkleExchangeReader` with a verification context. See the [ProofPack .NET README](https://github.com/zipwireapp/ProofPack/blob/main/dotnet/README.md) and [EXAMPLES.md](https://github.com/zipwireapp/ProofPack/blob/main/dotnet/EXAMPLES.md) for config and setup. ```csharp using Microsoft.AspNetCore.Mvc; using Zipwire.ProofPack; using Zipwire.ProofPack.Ethereum; [ApiController] [Route("api")] public class AgentController : ControllerBase { private readonly IsDelegateAttestationVerifier _delegateVerifier; private readonly AttestedMerkleExchangeReader _reader; public AgentController(IsDelegateAttestationVerifier delegateVerifier, AttestedMerkleExchangeReader reader) { _delegateVerifier = delegateVerifier; _reader = reader; } [HttpPost("time-tracking/log")] public async Task LogTime([FromHeader] string xAgentWallet) { // Verify agent is authorized var isAuthorized = await _delegateVerifier.VerifyByWalletAsync(xAgentWallet); if (!isAuthorized) { return Forbid("Agent not authorized by verified human"); } // Process time entry return Ok(new { message = "Time logged successfully" }); } [HttpPost("payments/claim")] public async Task ClaimPayment([FromHeader] string authorization) { if (!authorization?.StartsWith("Bearer ") == true) { return BadRequest("JWS or JWT required for payment claims"); } var jws = authorization.Substring(7); var result = await _reader.ReadAsync(jws, verificationContext); if (!result.IsValid) { return Forbid("Invalid authorization proof"); } var claims = result.Document.MerkleTree.Leaves; // Verify claims meet payment requirements if (!claims.ContainsKey("verifiedHuman") || !bool.TryParse(claims["verifiedHuman"], out var isHuman) || !isHuman) { return Forbid("Payment requires human verification"); } // Process payment claim return Ok(new { message = "Payment processed", agentWallet = result.AgentWallet }); } } ``` Full guide: [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). # Quick setup: verification context Configuring verification context and verifiers for ProofPack (JS and C#) ProofPack uses different setup for (1) **wallet-only verification** (IsDelegate) and (2) **full proof verification** (AttestedMerkleExchangeReader with attestation verifier factory and routing). The exact APIs and config shapes are in the ProofPack repo. * **JavaScript:** [Path 1](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) shows the real `IsDelegateAttestationVerifier` config (`delegationSchemaUid`, `acceptedRoots`, `preferredSubjectSchemas`, `schemaPayloadValidators`). For full-document verification, the repo uses `createVerificationContextWithAttestationVerifierFactory` with an `AttestationVerifierFactory` and routing config — see [ProofPack JavaScript README](https://github.com/zipwireapp/ProofPack/tree/main/javascript#readme) and [Ethereum package: Using with Verification Context](https://github.com/zipwireapp/ProofPack/blob/main/javascript/packages/ethereum/README.md#using-with-verification-context). * **C# / .NET:** Verifier uses `IsDelegateVerifierConfig` (AcceptedRoots, DelegationSchemaUid, etc.) and `IsDelegateVerifierOptions` (Chains or Lookup). Reader uses `AttestedMerkleExchangeVerificationContext.WithAttestationVerifierFactory` with routing. See [ProofPack .NET README](https://github.com/zipwireapp/ProofPack/blob/main/dotnet/README.md) and [EXAMPLES.md](https://github.com/zipwireapp/ProofPack/blob/main/dotnet/EXAMPLES.md). Conceptually you configure trusted roots and schemas, then create a verifier (for wallet checks) and a reader + verification context (for JWS/JWT). Copy-paste config from the repo rather than from this page. See [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation) and [ProofPack on GitHub](https://github.com/zipwireapp/ProofPack). # Common use cases ProofPack use cases — MCP, payments, age, residency, compliance (AML, KYC) Short patterns for agent verification. Agents prove things about their owner (nationality, clear AML, age or DoB, and that a real human authorized them) so services can gate commerce, finance, and access without holding full ID. Full code: [Path 1](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript), [Path 2](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript), [Express](/tools-and-integrations/proofpack-agent-delegation/express-middleware), [ASP.NET Core](/tools-and-integrations/proofpack-agent-delegation/aspnet-core-agent-verification). ## 1. MCP Server Integration **Goal:** Only let human-authorized agents use tools or resources. * Agent connects with its wallet (e.g. in handshake or header). * Server calls `verifier.verifyByWallet(agentWallet)` and grants or restricts access. ```javascript const result = await verifier.verifyByWallet(agentWallet); if (result.isValid) { // Grant agent full MCP access } else { // Restrict access or reject agent } ``` Use [Path 1 (wallet-only)](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript). No claims needed—just “is there a human behind this wallet?” ## 2. Payment and Payout Verification **Goal:** Let an agent check payment status or receive payouts on behalf of a human, without the service storing KYC. * Agent sends request with wallet (e.g. `GET /api/payments/status` with `x-agent-wallet` or query param). * Service verifies: wallet is authorized by a human and not revoked, then returns status or allows payout. Use [Path 1 (wallet-only)](/tools-and-integrations/proofpack-agent-delegation/path1-wallet-only-javascript) or [Express middleware](/tools-and-integrations/proofpack-agent-delegation/express-middleware). For payouts that require “clear AML” or residency, use Path 2 with those claims (see Compliance below). ## 3. Age-Restricted Commerce **Goal:** Sell age-restricted goods (alcohol, tobacco, certain OTC, games, content) without storing the buyer’s DoB. * Agent places order or confirms eligibility with `Authorization: Bearer ` (JWS or JWT). * Proof reveals only what’s needed: e.g. “over 18” or age band; service never sees full DoB. * Service verifies token, checks age claim, then fulfils order. Use [Path 2 (JWS/JWT with claims)](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript) or [Express](/tools-and-integrations/proofpack-agent-delegation/express-middleware). Same pattern for digital content, streaming age gates, or in-person handover checks. ## 4. Residency or Nationality-Gated Access **Goal:** Restrict offers, pricing, or product access by region or nationality without seeing full ID. * Agent requests content, subscription, or product with a proof (JWS/JWT) that reveals e.g. nationality or residency. * Service verifies proof and reads only the disclosed claim (e.g. “UK national”, “EU resident”), then applies policy. Use [Path 2](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript). Enables regional pricing, cross-border eligibility, right-to-rent style checks, and compliant geo-gating. ## 5. Compliance (KYC/AML) and Regulated Transactions **Goal:** Let an agent execute financial actions (payments, withdrawals, gambling, lending) where the service must know the human is verified and compliant. * Agent sends request with `Authorization: Bearer ` (JWS/JWT) that includes the needed claims: e.g. clear AML, nationality, age. * Service verifies proof and checks claims (e.g. “clear AML”, “over 18”, “allowed jurisdiction”), then processes the transaction. Use [Path 2 (JWS + claims)](/tools-and-integrations/proofpack-agent-delegation/path2-jws-claims-javascript) or the [ASP.NET Core](/tools-and-integrations/proofpack-agent-delegation/aspnet-core-agent-verification) pattern. Covers payouts, crypto/DeFi access, gambling, insurance, and any flow that today would re-ask for KYC or full ID. *** **Summary:** Path 1 = “Is this wallet acting for a verified human?” (wallet-only). Path 2 = “Is this wallet acting for a human who meets these criteria?” (JWS/JWT with selective claims: age, nationality, AML, etc.). Full guide: [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). # Installation Installing ProofPack (JavaScript, C#, Rust) Install the ProofPack libraries for your stack. Then see [Quick setup: verification context](/tools-and-integrations/proofpack-agent-delegation/quick-setup-verification-context) and the [example pages](/tools-and-integrations/proofpack-agent-delegation/proofpack-examples) for verification code. ## JavaScript / Node.js ```bash npm install @zipwire/proofpack @zipwire/proofpack-ethereum ``` ## C# / .NET ```bash dotnet add package Zipwire.ProofPack ``` ## Rust Add to `Cargo.toml`: ```toml [dependencies] proofpack = "1.3.0" ``` Full guide: [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation). SDKs and latest versions: [ProofPack on GitHub](https://github.com/zipwireapp/ProofPack). # Security # Authenticator mobile apps This page describes what an authenticator app is and what TOTP means. ### **How to set up an authenticator app for 2FA** Two-factor authentication (2FA) adds an extra layer of security to your online accounts. When you use 2FA, you need to enter both your password and a code from an authenticator app to log in. Authenticator apps generate codes using a time-based one-time password (TOTP) algorithm. This means that the code changes every few seconds, so it is very difficult for someone to guess or intercept. To set up an authenticator app, you will need to download an app from the app store on your phone or tablet. Once you have downloaded the app, you will need to scan a QR code or enter a code from the service you want to use 2FA with. Two examples of TOTP authentication apps are * Google Authenticator * Microsoft Authenticator * Authy * Bitwarden The app will then generate a six-digit code every few seconds. When you log in to the service, you will need to enter this code along with your password. Using an authenticator app is a great way to protect your online accounts. It is more secure than using 2FA with text messages, because the identity of the mobile phone on the cellular network can be stolen or spoofed so that your private messages are routed to the baddies. ### **Here's some basic information on TOTP:** * TOTP is a cryptographic algorithm that generates one-time passwords (OTPs) that are valid for a short period of time. * OTPs generated by TOTP are typically 6 digits long and can be used to authenticate users to online services. * TOTP is a secure method of authentication because it is difficult to guess or intercept OTPs. * Authenticator apps that use TOTP are a convenient way to generate and use OTPs. # Two factor in Zipwire Restricted access areas are protected by your two factor code.

The Zipwire two factor challenge

It's called a challenge, technically speaking. Any time you're stopped and asked to prove who you are, that's a challenge, like how a security guard might stop and challenge you trying to walk into um, The Cannes Film Festival. Zipwire's not quite as salubrious but nevertheless, once you've setup two factor authentication, we'll stop you now and again to make sure it's still actually you.

In your account settings you'll see the two factor setup UI.

You set it up by scanning the QR code in your account settings using your favourite authenticator app. The app will ping or buzz when it's read the QR code and begin showing a 6-digit code for 30 seconds, before generating another code. You must enter the code on display so we know you know that we know it's all working. The UI will change to let you disable it, in case you lose your phone or something. You cannot disable it unless you're logged-in and have access to your email. {% hint style="info" %} You will not need your two factor code to simply login and move around, but certain parts of the app and some actions are beyond the red rope, as it were. {% endhint %} # WhatsApp PIN Protection and SIM Swap Attacks Protect your WhatsApp account with a PIN to prevent SIM swap attacks on your verification codes. When you provide a phone number during sign-up, Zipwire sends verification codes via WhatsApp. WhatsApp is more secure than SMS, but **only if you have enabled a PIN or second factor on your WhatsApp account**—which we strongly advise. ## What is a SIM Swap Attack? A SIM swap attack happens when someone contacts your mobile carrier (often by phone or in person) and convinces them to transfer your phone number to a SIM card the attacker controls. They might claim to have lost their phone, need a replacement SIM, or use social engineering to bypass security questions. Once the attacker has your phone number on their SIM card, they can: * Receive all SMS messages sent to your number, including verification codes * Access accounts that rely on SMS for two-factor authentication * Intercept calls and messages intended for you ## How SIM Swap Affects WhatsApp If an attacker successfully performs a SIM swap on your number, they can set up WhatsApp on their device using your phone number. Without a PIN enabled, they will be able to: * Receive all future WhatsApp messages sent to your number, including your Zipwire verification codes * Potentially gain unauthorized access to your Zipwire account However, if you have enabled WhatsApp PIN protection, the attacker would need **both** the SIM swap **and** your PIN to access your WhatsApp messages. This adds a crucial second layer of defense. ## How to Enable WhatsApp PIN Protection Enabling a PIN on your WhatsApp account is simple and takes just a minute: 1. Open WhatsApp on your phone 2. Go to **Settings** → **Account** → **Two-step verification** 3. Tap **Enable** 4. Enter a 6-digit PIN (you'll be asked to confirm it) 5. Optionally add an email address for PIN recovery The PIN is just a memorable 6-digit number that you choose—think of it like a simple password you can easily remember. WhatsApp will only ask for it occasionally, such as when setting up WhatsApp on a new device, so it won't interrupt your daily use. Once enabled, this PIN prevents someone who has your phone number from accessing your WhatsApp account, even if they perform a SIM swap. ## Why This Matters for Zipwire If someone performs a SIM swap on your number and you don't have WhatsApp PIN protection enabled, they can set up WhatsApp on their device and receive all future messages sent to your number—including your Zipwire verification codes. This could allow them to gain unauthorized access to your account. By enabling WhatsApp PIN protection, you ensure that even if someone gains control of your phone number through a SIM swap, they still cannot access your WhatsApp messages or your Zipwire verification codes without also knowing your PIN. ## Best Practices * **Enable WhatsApp PIN protection** as soon as possible after setting up your Zipwire account * **Use a strong, unique PIN** that you don't use elsewhere * **Add a recovery email** to your WhatsApp account in case you forget your PIN * **Be cautious** if your mobile carrier contacts you about account changes you didn't request * **Monitor your accounts** for any suspicious activity {% hint style="warning" %} If you suspect your phone number has been compromised, contact your mobile carrier immediately and update your WhatsApp PIN. You should also review your Zipwire account for any unauthorized access. {% endhint %} # Passkeys Sign in securely without passwords using your device's built-in security Passkeys are a secure, passwordless way to sign in to Zipwire. Instead of remembering a password, you use your device's built-in security features like your fingerprint, face recognition, or a PIN—the same way you unlock your phone or laptop. They're faster, more secure, and you never have to worry about forgetting a complex password again. ## How Passkeys Beat Passwords Passkeys are fundamentally different from passwords in ways that matter for your security. With a traditional password, hackers can guess it, steal it in a data breach, or trick you into giving it away through phishing. With passkeys, none of that is possible. Here's why: your passkey uses advanced cryptography that ties it to your specific device and Zipwire. Even if someone somehow got your passkey data, they couldn't use it on their own computer or phone—it only works on your device. The part of your passkey that actually proves who you are (your private key) never leaves your device, so it can't be stolen in a breach. And since passkeys are unique to each service, you can't accidentally reuse the same credential across multiple sites. You also never need to change a passkey or worry about whether it's "strong enough"—your device handles all of that automatically. ## How Passkeys Work When you create a passkey, your device generates a unique pair of cryptographic keys: a public key and a private key. The public key is stored with Zipwire (similar to a lock), while the private key stays only on your device (the key that opens it). When you sign in, Zipwire challenges your device to prove it has the private key, and your device responds with proof—but it never shares the actual key itself. Think of it like proving you own a house by unlocking the front door; you're not handing over your house key to the landlord, just showing you have it. ## Where Your Passkey Lives Your passkey is stored securely by your operating system and browser, not by Zipwire. Here's what happens on different devices: **On your iPhone or iPad**, your passkey is stored in the Secure Enclave, which is a specially protected part of your device's chip designed just for this. It's kept isolated from the main operating system, so even if your device is compromised, the private key can't be extracted. If you have iCloud Keychain enabled (which is the default), your passkeys are automatically backed up and synced across all your Apple devices. When you get a new iPhone or iPad and sign in with your Apple ID, your passkeys will automatically restore. **On an Android phone**, your passkey is stored in the Android Keystore, a similar protected system that keeps encryption keys secure and separate from the rest of the operating system. If you're signed in to your Google Account, your passkeys are automatically backed up and synced. When you get a new Android phone and sign in with the same Google Account, your passkeys will automatically restore. **On Windows**, your passkey is stored in the Windows Credential Manager, which uses your device's encryption to protect it. If you enable Windows Hello (fingerprint, face, or PIN), your passkey is even further protected. If you use Microsoft Edge and are signed in to your Microsoft Account, your passkeys can sync across your Windows devices. **On Mac**, your passkey is stored in the Keychain and synced securely across your other Apple devices through iCloud Keychain. This means you can use the same passkey on your Mac, iPhone, and iPad automatically. **In your browser**, most modern browsers (Chrome, Firefox, Safari, Edge) keep your passkeys in sync with your operating system or your account. For example, if you use Chrome, your passkeys sync to your Google account and are available across your devices. The important thing to know is that your device—not any website or company—controls and protects your passkey. You're always in charge. ## Setting Up a Passkey Setting up a passkey takes just a few minutes. Here's what to expect: **Step 1: Enter Your Details** Start by providing your name and email address. We strongly recommend also adding a phone number. This isn't required, but it's your safety net—if something goes wrong and you lose access to your device, your email, or both, you'll need one of these recovery methods to get back into your account. More on that below. **Step 2: Create the Passkey** Your browser or device will prompt you to create a passkey, usually by asking you to use your fingerprint, face recognition, or device PIN. This is your device confirming that it's really you creating this passkey. The process takes seconds. **Step 3: Verify Your Contact Details** We'll send verification codes to your email and phone (if you provided one). Check your email and/or text messages, then enter those codes to complete setup. This verification makes sure your account recovery options actually work—so you won't be locked out later if you need them. Once this is done, you're ready to sign in from that device. ## Signing In with a Passkey To sign in to Zipwire, just choose the passkey option. Your device will prompt you to authenticate with your fingerprint, face, or PIN—no typing required. On most devices, this is just one tap or click. The entire process is usually faster than typing a password. ### Signing In on a Desktop or Laptop with Your Phone Here's a convenience feature many people don't know about: even if your passkey is on your phone, you can often use it to sign in on a desktop or laptop without having to add another passkey to the desktop. When you try to sign in on your computer, instead of being prompted for a passkey on that computer, you might see a QR code. Pull out your phone, scan the QR code with your phone's camera or authenticator app, and approve the sign-in on your phone with your fingerprint or PIN. Your computer will log you in instantly. This is especially useful if you're signing in on a work computer, a shared device, or a computer that doesn't have a passkey set up yet. Your phone does all the work, and the computer never stores any of your credentials. ## Adding Passkeys to Multiple Devices You can (and should) set up passkeys on multiple devices. Each device gets its own passkey, so you can sign in to Zipwire from your phone, tablet, laptop, or desktop—whichever you're using. You're not limited to one device. Just remember: each passkey is only on that specific device. If you set up a passkey on your home laptop, that passkey won't appear on your work computer. That's actually a security feature—it means if one device is compromised, your other passkeys are unaffected. To add a passkey to an existing account on a new device, use the account recovery flow. This allows you to verify your identity using your email or phone number, then create a new passkey on that device that's linked to your existing account. ## Important: Using Passkeys on Work Devices If you're setting up a passkey on a work-provided device (laptop, phone, tablet), talk to your IT department or security team first. Organizations often have policies about what can be stored on work devices, and they may manage credentials centrally for security and compliance reasons. Your IT team might: * Have specific guidance on whether passkeys are allowed * Prefer that you use the QR code sign-in method on work devices instead of storing a passkey on the device * Require you to remove the passkey if you leave the company or the device is wiped It's worth checking before you set one up, so you don't run into surprises later. ## Account Recovery: Keep Your Second Factors Updated Most modern devices automatically back up and sync your passkeys. If you have iCloud Keychain enabled on Apple devices, or you're signed in to your Google Account on Android, or using Microsoft Edge with a Microsoft Account on Windows, your passkeys will automatically restore when you sign in to a new device with the same account. This means if your phone breaks and you get a new one, your passkeys will typically be there waiting for you once you sign in. However, there are situations where you'll need to use account recovery to add a new passkey: * You're switching from one ecosystem to another (e.g., iPhone to Android, or Windows to Mac) * You're signing in on a new work computer that doesn't have your personal account * You've disabled cloud sync or backup on your device * You're using a device or browser that doesn't support passkey sync * You accidentally reset your device and lost all your data before it could sync In these cases, you'll need your email and phone number to verify your identity and add a new passkey. This is why it's critical to keep your recovery information updated. **If you lose access to both your device and your recovery methods (email and phone), you won't be able to access your account.** So keep your email address and phone number current. If your phone number changes, update it in your account settings. If you're about to do a major device reset or wipe, make sure you have access to your email or phone first. Think of it this way: your device holds your passkey, but your email and phone hold the keys to recovering everything. ## Troubleshooting **The passkey prompt doesn't appear when I try to sign in** Make sure you're using a supported modern browser (Chrome, Firefox, Safari, or Edge). Older browser versions sometimes don't support passkeys yet. Try updating your browser to the latest version. **I can't sign in on a new device** This is normal—your passkey only exists on the device where you created it. To sign in on a new device, use the account recovery option. Verify your email or phone number, and then create a new passkey on the new device. Alternatively, if your original device is nearby, you can scan a QR code on the new device with your phone to sign in without storing a passkey on that device. **I lost access to my device** If you're getting a replacement device in the same ecosystem (e.g., a new iPhone to replace your old iPhone), your passkeys should automatically restore when you sign in with your Apple ID, Google Account, or Microsoft Account. If they don't appear, or if you're switching to a different ecosystem, use the account recovery option to add a new passkey. You'll need to verify your email address or phone number to confirm your identity. Once you verify, you can set up a new passkey on your new device and access your account again. The old passkey on your lost device won't work anyway—your device's unlock method (fingerprint, PIN, or face) protects it. **My browser is asking where to save my passkey** Your browser is just asking where you want to store it—on your device directly, or synced to your account (if available). For personal devices, syncing to your account (like iCloud Keychain or Google Account) is usually the most convenient, because your passkey then works across all your devices. For work devices, check your IT policies first. **I'm having browser compatibility issues** Try updating your browser to the latest version, or try signing in with a different browser. If you're on an older operating system, you might need to upgrade to get passkey support. If you continue to have problems, contact our support team. ## Security Tips **Keep Your Device Secure** Your passkey is only as secure as your device. Lock your phone and laptop when you're not using them, and use a strong PIN or biometric authentication (fingerprint or face) on your device itself. If someone unlocks your device, they could theoretically use your passkey to sign in to Zipwire, so device security is your first line of defense. **Update Your Recovery Information** Check your account settings periodically to make sure your email and phone number are current. A valid recovery method is your safety net. **Review Your Devices** If you've added passkeys to multiple devices and you no longer use one of them, consider removing that passkey from your account (if the system allows it). This reduces the number of places your credential is stored. **If You Suspect Your Device Is Compromised** Use account recovery to add a new passkey on a secure device, then remove the old passkey from the compromised device if possible. This ensures no one else can sign in as you from that device. The beauty of passkeys is that you get strong security without the burden of managing complex passwords. Your device does the heavy lifting, and you just authenticate the way you already do every day—with your fingerprint, face, or PIN. # Wallet Connections This page helps you understand Wallets and touches on Attestations ## What is a Wallet? In the world of blockchain and cryptocurrencies like Ethereum, a wallet is essentially a tool that allows you to interact with blockchains. It's not just a place to store your digital assets; it's more like a keyring for your cryptographic keys, which control access to your tokens and other digital assets. Wallets manage these keys, enabling you to send, receive, and manage your cryptocurrency. ## Types of Wallets ### 1. Browser Wallets (Software Wallets) * Examples: MetaMask, Trust Wallet * Features: These wallets are browser extensions or standalone applications that allow you to interact with decentralized applications (dApps) directly from your web browser. They are convenient for daily use because they're easily accessible but rely on the security of the device they're installed on. ### 2. Hardware Wallets * Examples: Ledger, Trezor * Features: These are physical devices designed specifically for the secure storage of private keys. They keep your keys offline, which significantly reduces the risk of online hacks. Users connect these devices to their computers when they need to sign transactions. ### 3. Smart Wallets * Examples: Wallets using WebAuthn technology (e.g., Coinbase Smart Wallet), Account Abstraction wallets * Features: Smart Wallets represent a newer category where authentication can be handled through mechanisms like WebAuthn, which supports biometric or PIN-based authentication. These wallets use keys stored in your device (browser or OS) and can be linked to services like Google or Apple for recovery. Unlike traditional wallets, Smart Wallets can automate certain actions, such as: * Account Abstraction: Allowing users to pay gas fees in tokens other than ETH or even have another party pay for transactions. * Multi-signature: Transactions can require multiple approvals, enhancing security. * Social Recovery: If you lose access, trusted contacts can help you recover your wallet. **Important Note on Smart Wallets**: While smart wallets offer convenient features, it's crucial to understand that you still have a private key to manage - it's just hidden behind layers of abstraction. This key might be stored in your browser, operating system, or cloud services, and may or may not be properly backed up or synchronized across devices. The convenience comes with potential risks if you don't understand where your keys are stored or how they're protected. ## Wallets as Keyrings A wallet, in essence, is a keyring because it holds the private keys that allow you to access and control your digital assets. Just like a physical keyring where keys unlock different doors, in blockchain, these "keys" sign transactions or interact with smart contracts. ## Zipwire and Wallet Support Zipwire is designed to connect to a variety of wallets, from traditional Externally Owned Accounts (EOAs) to modern Smart Wallets. * **EOAs**: Accounts controlled by private keys, where you manually sign each transaction. The most common example is wallets like MetaMask, which you can install as a browser extension or use as a mobile app. * **Smart Wallets**: Modern wallets (like Coinbase Smart Wallet) that use biometrics and passkeys for authentication. Zipwire is fully compatible with these. **EOA Upgrades**: It's worth noting that EOAs can be upgraded to smart wallets using a series of Ethereum improvements (including EIP-5805 AUTHCALL and related EIPs). This means your traditional EOA wallet can gain smart wallet capabilities while maintaining compatibility with Zipwire. #### Notes * **Compatibility**: Zipwire supports connection via browser extensions (like MetaMask), mobile wallets (via WalletConnect), and modern smart wallets. * **Attestations**: With Zipwire, once you connect your wallet, you can issue attestations which are like digital certifications or claims about your identity, achievements, or any verifiable information on the blockchain. #### Wallet Connection Tips Connecting your wallet can sometimes be a bit tricky. Here are some helpful tips: * **Make sure your wallet is unlocked**: If you're using a browser extension like MetaMask, ensure the wallet is unlocked in your browser before trying to connect to Zipwire. * **Disconnect and reconnect**: If you're having trouble connecting, try disconnecting your wallet from the browser extension and then reconnecting it. This often resolves connection issues. * **Browser compatibility**: WalletConnect supports many wallets across multiple blockchains. If one approach isn't working, try refreshing the page and attempting the connection again. * **Multiple wallet support**: If you have multiple wallets or browser extensions active, this can sometimes cause conflicts. Try disabling other wallet extensions temporarily while connecting to Zipwire. {% content-ref url="/pages/57KGScK77PabLlQ8mlpF" %} [Connecting with WalletConnect](/fundamentals/security/connecting-with-walletconnect) {% endcontent-ref %} ## Conclusion Understanding the type of wallet you use is crucial for how you manage your digital identity and assets. While Smart Wallets offer advanced features and convenience, they still require careful key management behind the scenes. Zipwire currently integrates with both classic EOA wallets and modern smart wallets to provide a secure and straightforward way to issue attestations, with clear visibility into your key management responsibilities. As wallet technology evolves, Zipwire aims to adapt and expand its compatibility to enhance user experience and security. ## Best Practices for Wallet Privacy ### Wallet Separation Strategy Consider using separate wallets for different purposes to minimize privacy risks: * **Login Wallet**: A dedicated wallet just for signing into dApps and services. Keep minimal funds here. * **Financial Wallet**: Your main wallet for significant holdings and DeFi operations. Never use this for random dApp logins. * **Shopping Wallet**: A separate wallet for NFT purchases, gaming, and other consumer activities. Fund it only when needed. This separation means that even if one wallet gets doxed, your financial privacy isn't completely compromised. {% hint style="info" %} **Learn More**: For comprehensive guidance on wallet privacy and industry challenges, see our [Wallet Address Privacy](/fundamentals/security/wallet-address-privacy) page and our detailed blog post on [Wallet Address Privacy: Why Doxing Is the Real Blockchain Threat](https://zipwire.io/blog/articles/2025-07/waldox/wallet-address-privacy-doxing-blockchain-threat). {% endhint %} ### Getting Attestations You can obtain blockchain attestations through Zipwire in two ways: **Self-Service**: Use [Zipwire Attest](/zipwire-attest/zipwire-attest) to register independently and get attestations directly to your wallet. **Business Integration**: Use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/blob/main/zipwire-collect/README.md) when businesses include ID checks in their document collections - you can claim free attestations to your wallet. If you encounter issues or have questions about connecting your wallet or using Zipwire for attestations, please reach out to our support team. # Connecting with WalletConnect Learn how to connect your wallet using WalletConnect and AppKit. Zipwire uses **Reown AppKit** (formerly Web3Modal) to provide a seamless wallet connection experience. This allows you to connect not just via browser extensions, but also via mobile wallets and smart wallets. ## What is WalletConnect? WalletConnect is an open protocol that allows your wallet to communicate with decentralized applications (dApps). Unlike browser extensions that are "injected" into your browser, WalletConnect establishes a secure, encrypted connection between the Zipwire web app and your wallet app, regardless of whether they are on the same device. ## How to Connect When you click **Connect Wallet** in Zipwire, you will see the AppKit connection modal. You have several options: ### 1. Browser Extensions (Installed) If you have a wallet extension like MetaMask, Coinbase Wallet, or Rabby installed, it will appear at the top of the list. Simply click it to connect. ### 2. Mobile Wallets (QR Code) If you want to use a wallet on your phone (like Trust Wallet, Rainbow, or MetaMask Mobile): 1. Select the **WalletConnect** option in the modal. 2. A QR code will appear on your screen. 3. Open your wallet app on your phone and look for the "Scan" or "WalletConnect" icon. 4. Scan the QR code. 5. Confirm the connection request in your mobile app. ### 3. Search for Your Wallet If your wallet isn't listed in the featured section, you can use the search bar to find it among the hundreds of supported wallets. ## Supported Wallet Types ### Externally Owned Accounts (EOAs) Traditional wallets like MetaMask where you manage a 12 or 24-word seed phrase. ### Smart Wallets Zipwire supports modern smart wallets, including the **Coinbase Smart Wallet**. These wallets often use biometrics (FaceID/TouchID) via Passkeys and don't require you to manage a traditional seed phrase. Zipwire's backend is fully compatible with EIP-1271 and ERC-6492 signature standards used by these wallets. ## Benefits of AppKit * **No Extension Required**: You can use Zipwire even if you don't want to install browser extensions. * **Multi-Device Support**: Use Zipwire on your desktop while your keys stay securely on your phone. * **Universal Compatibility**: Support for over 100+ different wallet apps. * **Network Switching**: AppKit will automatically prompt you to switch to the correct network (e.g., Base) if your wallet is on the wrong one. ## Troubleshooting * **Connection Dropped**: If your connection remains idle for a long time, it may time out. Simply refresh the page and reconnect. * **Wrong Account**: Ensure the account selected in your wallet app matches the one you intend to use with Zipwire. * **Mobile App Closing**: Some mobile operating systems may put your wallet app to sleep. Ensure your wallet app stays open until the connection is confirmed. {% hint style="info" %} **Privacy Tip**: Using WalletConnect doesn't give Zipwire access to your funds. It only allows Zipwire to see your public address and request your signature for specific actions like logging in or claiming attestations. {% endhint %} # Wallet Address Privacy Understanding why wallet addresses need special privacy protection and how Zipwire handles them differently for login vs attestations Your blockchain wallet address is more than just a way to receive cryptocurrency—it's a unique identifier that can reveal your real identity if it gets linked to your personal information. This page explains why Zipwire treats wallet addresses with special care and why you might need to connect your wallet again even if you've used it before. New to wallet addresses and keys? See [Crypto & Blockchain Basics](/fundamentals/security/crypto-and-blockchain-basics). ## Why Wallet Addresses Are Sensitive ### The Doxing Risk Your wallet address is like a digital fingerprint. If someone can link your wallet address to your real identity, they can: * **Track your financial activity** - See all your transactions, token holdings, and DeFi interactions * **Monitor your behavior** - Understand your spending patterns, investment choices, and online activities * **Build a profile** - Combine blockchain data with other information to create a comprehensive picture of who you are * **Target you** - Use this information for phishing, social engineering, or other malicious purposes {% hint style="warning" %} **Real Example**: If your wallet address gets linked to your social media accounts, someone could trace your entire financial history and use it to impersonate you or target you with scams. {% endhint %} ### The Privacy Paradox While blockchain transactions are public by design, your wallet address doesn't have to be linked to your real identity. The privacy comes from keeping this link secret. Once that link is broken, your financial privacy is compromised. ## How Zipwire Protects Your Wallet Address ### For Login: Address Hashing When you use "Sign in with Blockchain" to log into Zipwire, we treat your wallet address like a password: * **Hashed storage**: Your wallet address is hashed (converted to a secure, unreadable format) before being stored * **Login verification**: We can verify you own the address without storing the actual address * **Privacy preserved**: Even if our database was compromised, your wallet address would remain protected {% hint style="info" %} **Technical Detail**: We use cryptographic hashing to convert your wallet address into a secure hash. This allows us to verify your login without storing your actual address. {% endhint %} ### For Attestations: Secure Storage Required However, for attestations, we need to know your actual wallet address because: * **Blockchain recording**: Attestations must be recorded on the blockchain under your specific wallet address * **Verification**: Others need to be able to verify that the attestation belongs to your wallet * **Portability**: You need to be able to use your attestations across different platforms This creates a security challenge: we need to store your actual wallet address securely. ## The Solution: User-Controlled Encrypted Storage ### Your Data, Your Choice For attestations, Zipwire uses a different approach: * **Encrypted storage**: Your wallet address is stored in encrypted form * **User-controlled location**: You choose where in the world this encrypted data is stored * **Application access**: Our application code can decrypt the address when needed to create attestations * **Storage protection**: Even if our engineers or hackers gain access to the underlying storage system, they cannot read your wallet address * **Data deletion flexibility**: You can delete source data while keeping attestation eligibility * **Compliance**: This approach meets data protection regulations while enabling attestations ### How the Encryption Works The encryption system is designed with multiple layers of protection: 1. **Application-level encryption**: Your wallet address is encrypted using strong cryptographic methods 2. **Storage isolation**: The encrypted data is stored separately from the encryption keys 3. **Runtime decryption**: Only the running application can decrypt the data when needed for attestations 4. **Storage access protection**: Direct access to the storage system (by engineers or hackers) only reveals encrypted data that cannot be decrypted without the application's encryption keys {% hint style="info" %} **Technical Detail**: The encryption keys are split into pieces and managed by the application runtime, and are not stored in the same location as your encrypted wallet address. This means that even if someone gains access to the storage system, they would only see encrypted data that they cannot decrypt, and the split key pieces make it even harder to reconstruct the full encryption key. {% endhint %} ### Why You Need to Connect Again Even if you've previously connected your wallet for login, you'll need to connect it again for attestations because: 1. **Different security models**: Login uses hashing, attestations use encrypted storage 2. **Separate permissions**: Each connection serves a different purpose 3. **User consent**: You explicitly choose to share your wallet address for attestations 4. **Data location choice**: You decide where your encrypted data is stored {% hint style="info" %} **Privacy First**: This two-step process ensures you're always in control of when and how your wallet address is used. {% endhint %} ## Understanding the Two Connection Types ### Login Connection (Sign in with Blockchain) **Purpose**: Authenticate you to access Zipwire services **What happens**: Your wallet address is hashed and stored securely **Privacy level**: Maximum - we can't see your actual address **Use case**: Accessing your account, managing settings, etc. ### Attestation Connection **Purpose**: Enable blockchain attestations to your wallet **What happens**: Your wallet address is encrypted and stored in your chosen location **Privacy level**: High - encrypted but our application can decrypt it when needed for attestations **Use case**: Receiving IsAHuman and Private Data attestations ## Best Practices for Wallet Privacy ### General Privacy Tips * **Use separate wallets**: Consider using different wallets for different purposes * **Avoid linking**: Don't publicly link your wallet address to your real identity * **Regular rotation**: Consider creating new wallets periodically for sensitive activities * **Be cautious**: Think twice before sharing your wallet address publicly ### With Zipwire * **Understand the difference**: Know when you're connecting for login vs attestations * **Choose storage location**: Select a data storage location that meets your privacy requirements * **Review permissions**: Always check what you're authorizing when connecting your wallet * **Contact support**: If you have privacy concerns, reach out to our team ## Frequently Asked Questions ### Why can't you just use the same connection for both? The different security requirements make this impossible. Login needs to verify ownership without storing the address, while attestations need to store the actual address securely. ### Is my wallet address safe with Zipwire? Yes. For login, it's hashed and unreadable. For attestations, it's encrypted and stored in your chosen location. While our application code can decrypt it when needed to create attestations, even our engineers or hackers with access to the underlying storage system cannot read your wallet address. ### Can I revoke access later? Yes. You can disconnect your wallet at any time. However, the encrypted wallet address data remains stored until you delete your account. This enables an important privacy feature: you can delete your source data (like passport information) while still being able to claim attestations later. ### What happens when I delete my source data? When you delete your source data (like passport or ID documents), the encrypted wallet address remains. This means: * **Attestations still claimable**: You can still claim attestations that don't depend on the source data * **Cryptographic proofs**: Attestations use Merkle tree proofs, not the original documents * **Privacy enhanced**: You can remove sensitive documents while keeping your attestation eligibility {% hint style="info" %} **Example**: If you're under 21 and can't claim an "IsOverTwentyOne" attestation yet, you can delete your stored passport data for privacy. Later, when you turn 21, you can still claim the attestation because it's based on cryptographic proofs, not the original passport data. {% endhint %} ### What if I don't want to share my wallet address for attestations? That's completely fine! You can use Zipwire for login and other services without ever connecting your wallet for attestations. Attestations are optional. ### How do I know where my data is stored? When you connect your wallet for attestations, you'll be prompted to choose a data storage location. This choice is clearly presented and you can change it later. ### Does this work with all blockchains? Currently, Zipwire supports Ethereum and related networks. We're working on expanding support to other blockchains like Solana in the future. ## Getting Help If you have questions about wallet privacy or need help understanding how Zipwire protects your data, please contact our support team. We're committed to transparency about our privacy practices and are here to help you make informed decisions about your digital identity. ## Learn More For a deeper dive into wallet address privacy and the broader industry challenges, read our comprehensive blog post: [Wallet Address Privacy: Why Doxing Is the Real Blockchain Threat](https://zipwire.io/blog/articles/2025-07/waldox/wallet-address-privacy-doxing-blockchain-threat). {% content-ref url="/pages/Phc9nifOmbHMqHe4pyeY" %} [Wallet Connections](/fundamentals/security/wallet-connections) {% endcontent-ref %} {% content-ref url="/pages/qoTLIAT6Ma2rx9Ig1IwT" %} [Sign-in with Ethereum](/fundamentals/security/sign-in-with-ethereum) {% endcontent-ref %} {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} # Attestations & Privacy: Timing Your Claims & Data Deletion Understanding how to maintain privacy when claiming attestations across multiple wallet addresses and managing your data deletion Blockchain attestations are powerful tools for establishing trust and verification, but they also require careful consideration of privacy implications. This page explains how to strategically manage your attestations across multiple wallet addresses while maintaining your privacy and controlling your data. ## The Nature of Attestations and Identity ### Wallet Address as Pseudonymous ID Your wallet address is a public, pseudonymous identifier on the blockchain. Unlike traditional identity systems, it doesn't inherently reveal your real-world identity—that privacy comes from keeping the link between your wallet address and your personal information secret. ### Crucial Distinction: No Single Human ID **It is important to understand that Zipwire does not create a single, immutable ID for a unique human being.** **Why this matters**: In systems that rely on a single underlying identity, accidental disclosure or coercion could potentially link all of your private blockchain interactions. This creates a single point of failure for your privacy. **Zipwire's Approach**: Instead, with Zipwire, you can claim any attestation you desire against multiple, distinct wallet addresses. Think of your wallets as separate identities. **User Behavior**: Many individuals consciously operate numerous wallet addresses, each dedicated to different purposes, and meticulously work to prevent them from being inadvertently linked. ### Attestations as Permanent Facts Attestations are immutable, permanent facts issued against a wallet address on the blockchain. Once issued, they cannot be removed or altered. This permanence makes them valuable for trust and verification, but also means they become part of your wallet's permanent public record. ## Types of Attestations & Privacy Impact ### Human/Age Attestations These attestations reveal "true identity" information such as: * **IsAHuman**: Confirms the wallet belongs to a real person * **Age-based attestations**: Prove specific age thresholds (e.g., IsOverEighteen, IsOverTwentyOne) These attestations are more privacy-sensitive because they directly link to your real identity. ### Private Data Attestations These attestations contain random numbers that reveal nothing directly. They're designed for selective disclosure proofs—allowing you to prove possession of specific data without revealing the actual data. * **Document attestations**: Based on cryptographic hashes of identity documents * **Selective disclosure**: You can prove specific facts (like age) without revealing other information ## The Privacy Risk: Linking Wallet Addresses ### Problem Statement The core privacy concern is that claiming attestations against multiple wallet addresses can inadvertently link them together, potentially revealing that they belong to the same person. ### Mechanism of Linking Similar actions occurring at similar times can act as a "fingerprint" or "on-chain heuristic" that allows observers to infer connections between seemingly separate wallet addresses. **Analogy**: If two people are seen entering the same building at the same time, observers might infer they're connected, even if they're actually strangers. Similarly, if two wallet addresses claim the same type of attestation within a short timeframe, blockchain analytics tools might cluster them together. ## Best Practice: Strategic Timing for Privacy Protection ### Core Recommendation **If you are claiming attestations against more than one wallet address, we strongly recommend you wait as long as possible between claims.** ### Why Strategic Timing Matters **Mitigates association**: Spacing out your claims helps prevent wallet addresses from becoming associated with each other. **Breaks correlation**: Spreading out the claims makes it much harder for on-chain analysis tools to correlate the activity across different addresses. **Reduces clustering**: Blockchain analytics often "cluster" addresses based on shared behaviors. Strategic timing helps avoid this clustering. ### Practical Timing Advice * **Significant gaps**: Consider waiting hours, days, or even weeks/months between claims, depending on your privacy sensitivity * **Avoid single sessions**: Don't claim multiple attestations for different wallets in a single session * **Vary patterns**: Don't establish predictable patterns in your claiming behavior * **Identity attestations**: This strategy is particularly important for "human" or "identity-revealing" attestations, but it's good practice for all attestations {% hint style="warning" %} **Privacy Tip**: The more time you can wait between claims, the better. Even small delays of hours or days can significantly reduce the risk of address linking. {% endhint %} ## Controlling Your Data: Deletion & Retention ### User Recommendation **We strongly recommend deleting your data once you have finished using Zipwire for your attestation and proof-making needs.** ### Automatic Deletion Policy In accordance with GDPR, Zipwire automatically deletes data if a user stops actively using the service for a specified period. This ensures your data doesn't remain stored indefinitely. ### How to Manually Delete Your Data You have direct control over your stored data through multiple methods: #### Delete Specific Document Data To delete specific data associated with your attestations: 1. Navigate to 'My Docs' within the Zipwire interface 2. Locate the relevant Merkle trees 3. Delete the specific document data you no longer need #### Remove Stored Wallet Addresses You can also remove a stored wallet address by simply disconnecting it: 1. Go to your wallet connection settings 2. Look for wallet addresses marked with 'Stored' status 3. Disconnect the wallet to remove its stored data {% hint style="info" %} **UI Indicator**: The interface will clearly indicate 'Stored' next to any wallet addresses that are currently retained by the service. {% endhint %} ### Commitment to Full Deletion **Please note that Zipwire performs a full and permanent deletion of your data. This is not merely 'marking data as gone' or hiding it from view, as is the practice with many other services. When you delete, your data is truly removed.** This ensures that: * Your data cannot be recovered once deleted * No traces remain in our systems * Your privacy is fully protected ## Privacy Best Practices Summary ### For Multiple Wallet Addresses 1. **Space out attestation claims** - Wait as long as possible between claims 2. **Vary your patterns** - Don't establish predictable claiming behavior 3. **Consider timing carefully** - Think about when and how you claim attestations 4. **Monitor for clustering** - Be aware of how your actions might link addresses ### For Data Management 1. **Delete after use** - Remove data once you're done with attestations 2. **Regular cleanup** - Periodically review and delete unnecessary data 3. **Monitor stored status** - Check which wallet addresses are marked as 'Stored' 4. **Understand permanence** - Remember that attestations are permanent on the blockchain ### For Overall Privacy 1. **Separate purposes** - Use different wallets for different activities 2. **Minimize linking** - Avoid actions that could connect your wallets 3. **Stay informed** - Keep up with privacy best practices 4. **Be proactive** - Take control of your data and privacy ## Conclusion: Balancing Utility and Privacy Blockchain attestations provide powerful verification capabilities while maintaining the pseudonymous nature of blockchain interactions. By understanding the privacy implications and implementing thoughtful timing strategies, you can enjoy the benefits of attestations while preserving your privacy. **Key Takeaways**: * **Strategic timing** of attestation claims helps maintain wallet separation * **Proactive data management** ensures you remain in control of your information * **Conscious privacy practices** are essential in the pseudonymous blockchain environment Thoughtful timing of attestations and proactive data management are simple yet powerful techniques to maintain the separation and pseudonymity of multiple wallet identities and ensure control over personal information. {% content-ref url="/pages/rLvMqDEvz2ZjdqfT8eVU" %} [Wallet Address Privacy](/fundamentals/security/wallet-address-privacy) {% endcontent-ref %} {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} {% content-ref url="/pages/K4BLwRNETrUKpdJuaJRC" %} [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) {% endcontent-ref %} # Sign-in with Ethereum Understanding "Sign in with Ethereum" Sign in with Ethereum (SIWE) is a method that allows you to log into various applications using your Ethereum wallet, enhancing both security and privacy. It leverages your existing wallet to authenticate your identity without needing to create new usernames or passwords for each service you use. {% content-ref url="/pages/Phc9nifOmbHMqHe4pyeY" %} [Wallet Connections](/fundamentals/security/wallet-connections) {% endcontent-ref %} ## How Does It Work? 1. Wallet Connection: You connect your Ethereum wallet (like MetaMask or a mobile wallet via WalletConnect) to Zipwire or any other service supporting SIWE. 2. Authentication Message: The application sends a message to your wallet, which includes details about what you're logging into. 3. Signature: You sign this message with your wallet. This signature acts as your authentication, proving you own the wallet without revealing your private key. 4. Access Granted: Upon verifying the signature, the application grants you access, often without needing to enter any personal details other than your public wallet address. ## Benefits of SIWE * Security: Your private key never leaves your device; only a signature of a message does. * Privacy: You control what personal information is shared. Often, just your wallet address is used, which is pseudonymous. * Decentralization: It promotes a decentralized identity model where you, not the services, control your identity. {% hint style="warning" %} **Industry Problem**: Most dApps store wallet addresses directly in their databases for both authentication and blockchain interactions. This creates a single point of failure - if their database is compromised, your wallet address gets exposed and linked to your real identity, potentially revealing your entire blockchain transaction history. {% endhint %} ## Relation to Wallets SIWE is closely tied to how wallets function. Zipwire supports both traditional and modern wallet architectures: * **Externally Owned Accounts (EOAs)**: Traditional wallets (like MetaMask) where you manually sign each transaction using a private key. * **Smart Wallets**: Modern wallets (like Coinbase Smart Wallet) that use biometrics and passkeys. Zipwire is fully compatible with these via industry standards like EIP-1271 and ERC-6492. Learn more about these in our [Wallet Connections](/fundamentals/security/wallet-connections) guide. ## Using SIWE with Zipwire * Connect Your Wallet: On the Zipwire login page, select the option to "Sign in with Ethereum." This will prompt you to connect your wallet via a browser extension (like MetaMask) or a mobile wallet (via WalletConnect). * Sign the Message: You'll be asked to sign a message confirming your login. This message typically includes the domain of Zipwire, a "nonce" (a random number to prevent "replay" attacks), and other details. * Enjoy Seamless Access: After signing, you'll be logged in, and you can manage your attestations or any other features Zipwire offers. {% hint style="info" %} **Important** - When you login on another device, you'll need your wallet available (extension or mobile app) and to remember which of your accounts you used, else Zipwire will treat you as a brand new user. {% endhint %} ## Security Considerations * Always Check the Message: Before signing, ensure the message is from Zipwire and contains the expected details to prevent phishing. * Manage Your Wallet Keys: Keep your wallet's private keys secure. If compromised, anyone could sign in as you. * Revoking Access: If you ever lose trust in an application or suspect foul play, you can always disconnect your wallet, revoking the app's permission to use your signature for authentication. ## Troubleshooting SIWE * Reload (F5) the Zipwire page as a first step.\\ * Wallet Not Connecting: Ensure your wallet extension is up to date and properly installed. Also, check if Zipwire supports your specific wallet version. * Signature Issues: If signing doesn't work, try clearing your cache or using a different browser. Sometimes, network issues can interfere. If you run into any problems or have further questions about using SIWE with Zipwire, please contact our support team for assistance. # Attestations Introduction to Attestations via Ethereum Attestation Service (EAS) Attestations are a powerful concept in blockchain technology, allowing one entity to make verified claims about another or about specific data on the blockchain. The Ethereum Attestation Service (EAS) is an open-source, permissionless platform that enables the creation, verification, and management of these attestations on or off-chain (see [Crypto & Blockchain Basics](/fundamentals/security/crypto-and-blockchain-basics) if those terms are new to you). ## What are Attestations? Attestations are essentially digital signatures that vouch for certain attributes or facts. They can be used for: * Identity Verification * Reputation Systems * Compliance Checks * Ownership Proofs * And much more! ## Types of Attestations in Zipwire ### Basic Attestations: "IsAHuman" A simple boolean attestation that verifies a wallet belongs to a real person. [Learn more about IsAHuman →](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) ### Robust Attestations: Private Data A more secure attestation that uses Merkle root hashes to verify identity documents while preserving privacy. [Learn more about Private Data attestations →](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) ### E-Sign Attestations: Signer Identity Cross-Referencing When a respondent signs a document, their signing attestation can reference their existing identity attestations for extra context. [Learn more about signer identity cross-referencing →](/fundamentals/security/attestations/signer-identity-cross-referencing) ## Getting Attestations ### Self-Service Attestations {% content-ref url="" %} {% endcontent-ref %} Zipwire Attest is our self-service platform where individuals can register, connect their Ethereum wallet, and get blockchain attestations independently. This service allows you to: * **Register independently** - No business account required * **Connect your wallet** - Receive attestations directly to your wallet * **Complete ID verification** - Government-approved identity checks * **Get attested** - Claim IsAHuman and Private Data attestations * **Generate proofs** - Create selective disclosure proofs when needed {% hint style="info" %} **Self-Service vs. Business Use** Zipwire Attest is designed for individual users who want to build their digital identity. For business use cases (like employee verification), use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/tree/main/fundamentals/security/zipwire-collect/README.md) which integrates attestations into the document collection process. {% endhint %} ### Business Attestations For businesses and organizations, attestations can be obtained through Zipwire Collect when ID checks are included in document collections. This works as follows: * **ID check integration** - Collections can include ID verification items * **Wallet connection** - Users connect their Ethereum wallet to the collection * **Free attestations** - Users can claim attestations for free (business pays for ID check) * **Same verification** - Uses the same Yoti ID verification as Zipwire Attest * **Same attestations** - Users receive the same IsAHuman and Private Data attestations {% hint style="info" %} **Overlap with Zipwire Attest** Zipwire Collect and Zipwire Attest overlap when it comes to ID checks. If a collection includes an ID check item and the user has connected their wallet, they can claim attestations for free since the business paid for the ID verification through Zipwire Collect. {% endhint %} ## How Do Attestations Work? ### The Process 1. Verification: An attester (like Zipwire) verifies your information 2. Recording: The attestation is recorded on the blockchain 3. Verification: You can later prove specific attributes without revealing the underlying data ### Privacy and Security * The blockchain only stores the attestation and its Merkle root hash, not your actual data * You can selectively reveal specific attributes using cryptographic proofs * The system maintains your privacy while ensuring verifiability ## Why Use Attestations? ### For Users * Privacy: Share only what you need to share * Control: You decide what information to reveal * Portability: Use your attestations across different platforms * Security: Cryptographic proofs ensure your data hasn't been tampered with ### For Platforms * Trust: Verify user information without storing sensitive data * Compliance: Meet regulatory requirements while respecting privacy * Efficiency: Reduce the need for repeated identity checks * Security: Prevent fraud and identity theft ## How to Get Started ### For Individual Users 1. **Visit Zipwire Attest**: Go to our self-service platform 2. **Connect Your Wallet**: Link your Ethereum wallet (must be done before verification) 3. **Complete ID Check**: Verify your identity using government-approved methods 4. **Claim Attestations**: Add IsAHuman and Private Data attestations to your wallet 5. **Generate Proofs**: Create selective disclosure proofs when needed {% content-ref url="" %} {% endcontent-ref %} ### For Businesses 1. **Set up Zipwire Collect**: Configure your document collection process 2. **Add ID check items**: Include ID verification in your collections 3. **Users connect wallets**: Users link their Ethereum wallets to the collection 4. **Complete verification**: Users complete ID checks as part of the collection 5. **Claim attestations**: Users can claim free attestations to their wallets {% content-ref url="" %} {% endcontent-ref %} ## Learn More * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) * [Verifying Attested Wallets](/fundamentals/security/wallet-verification-guide/verifying-attested-wallets) * [The Ethereum Attestation Service](https://docs.attest.org/docs/welcome) * [EAS Scan for the Base Ethereum blockchain](https://base.easscan.org/) # IsDelegate: Agent Delegation & Authorization Authorize agents and bots to act on your behalf with IsDelegate attestations IsDelegate is a blockchain attestation that proves one wallet is authorized to act on behalf of another. In the context of the agent economy, it answers a critical question: **"Is this bot actually working for a real human?"** ## The Problem It Solves When an AI agent makes a request to a service, how does that service know: * Is this a real person's agent, or just a bot? * Does the human actually authorize this agent? * Can I trust the agent's claims about who it represents? Without IsDelegate, agents are indistinguishable from malicious bots. With IsDelegate, agents carry cryptographic proof of human authorization. ## How IsDelegate Works ### The Basic Concept An **IsDelegate attestation** is a signed, on-chain statement: > "I (wallet A) authorize wallet B to act on my behalf." **Wallet A** = the human or authorizing entity **Wallet B** = the agent or bot being authorized Once created, this attestation is: * **Immutable** - Written to the blockchain (EAS on Base) * **Verifiable** - Anyone can check it without asking the issuer * **Chainable** - The agent (wallet B) can create IsDelegate attestations to sub-agents * **Revocable** - The human can revoke it if the agent is compromised ### Delegation Chains Humans can delegate to primary agents, and those agents can delegate to sub-agents, creating verifiable chains: ``` Human Wallet ↓ IsDelegate attestation Primary Agent Wallet ↓ IsDelegate attestation Sub-Agent Wallet ↓ (can delegate further) Sub-Sub-Agent Wallet ``` Each link is cryptographically signed and on-chain. ProofPack can walk this entire chain to verify that the sub-agent is ultimately authorized by a real human. **Minting proofs for sub-agents:** When you use the [ProofPack Mint API](https://github.com/zipwireapp/gbk-tz-docs/blob/main/fundamentals/api/proofpack-mint-api.md), you call it with your (the human’s) API key and pass the **agent wallet** in the request. You can pass a direct delegate’s wallet or a sub-agent’s wallet several hops down the chain (e.g. Human → Agent1 → Agent2 → Agent3). The API walks the chain back to your human attestation and mints a ProofPack for that wallet. So you can mint a proof for any delegated wallet in the chain, not only your immediate delegate. ## The Three-Step Process ### Step 1: Human Attestation (Root of Trust) First, the human must be attested as human via Zipwire or another provider: * Use [Zipwire Attest](https://zipwire.io/attest) to verify your identity * Complete a Yoti ID check (liveness + government ID) * Receive an **IsAHuman** attestation tied to your wallet * Your wallet is now cryptographically linked to verified identity data This becomes the **root** of all future delegations. ### Step 2: Create an IsDelegate Attestation Now authorize an agent. Go directly to the IsDelegate schema: [**Create IsDelegate on EAS Base →**](https://base.easscan.org/schema/view/0xc4f37c5cb76ba597c66323e399a435e4c7d46ea741588945eacae69ec2d81b97) Or manually create an attestation using the **IsDelegate** schema: 3. Set: * **Attester** = your human-attested wallet * **Recipient** = the agent's wallet address * **refUID** = reference to your IsAHuman attestation (links the chain) 4. Sign and submit the attestation to the blockchain The agent's wallet is now authorized to act for you. ### Step 3: Agent Presents Proof When the agent makes requests, it can: **Option A: Present a specific claim** * Generate a ProofPack JWS with a specific identity claim (e.g., "nationality = UK") * The ProofPack includes the delegation chain and Merkle proofs * Service verifies the JWS, attestation, delegation chain, and Merkle root **Option B: Just prove delegation** * Provide its wallet address * Service uses ProofPack's `verifyByWallet()` method * ProofPack queries EAS, finds IsDelegate attestations for that wallet, and walks the chain to your IsAHuman * Service gets a yes/no: "Is this agent authorized by a verified human?" ## Key Concepts ### The Delegation Chain (refUID Linking) Each IsDelegate attestation includes a **refUID** that points to its parent: * **Primary agent's IsDelegate** has `refUID` pointing to the human's **IsAHuman** attestation * **Sub-agent's IsDelegate** has `refUID` pointing to the primary agent's **IsDelegate** attestation This creates an unbroken chain that ProofPack can validate: ``` Sub-agent IsDelegate ↓ refUID Primary agent IsDelegate ↓ refUID Human IsAHuman attestation ``` ### Authority Continuity When verifying, ProofPack ensures: * Each attestation in the chain is valid (not revoked, not expired) * The recipient of one attestation matches the attester of the next * The chain eventually reaches a trusted root (e.g., IsAHuman) This prevents **authority hijacking** — even if an attestation is forged, the chain won't validate. ### Privacy with Delegation The human's **full identity data** never travels with the agent. Instead: * The human's wallet attests to data via Zipwire (Merkle root only stored on-chain) * The IsDelegate proves authorization * The agent presents a **ProofPack** that selectively reveals only needed claims * The service verifies without ever seeing the human's full ID ## Real-World Example ### Scenario: AI Agent Managing Contractor's Timesheets 1. **Alice (contractor)** attests as human via Zipwire * Alice's wallet = `0xAlice...` * Receives IsAHuman attestation on Base * Zipwire creates a Merkle tree from her identity (name, nationality, etc.) 2. **Alice authorizes Claude Code** to manage time tracking * Creates IsDelegate with: * Attester = `0xAlice...` (her wallet) * Recipient = `0xClaudeAgent...` (Claude's wallet) * refUID = her IsAHuman attestation UID * Submits to EAS on Base 3. **Claude Code logs time entries** * Makes request to Zipwire API: "Log 8 hours for Alice" * Includes a JWS ProofPack with: * IsDelegate attestation pointing to the delegation * Merkle proof of the delegation chain back to Alice's IsAHuman * Timestamp and signature 4. **Zipwire backend verifies** * Calls ProofPack library: `await verifyAsync(jws, verificationContext)` * ProofPack walks the delegation chain: * Claude's IsDelegate is valid ✓ * Points (via refUID) to Alice's IsAHuman ✓ * Merkle root matches ✓ * Chain reaches a trusted root (Zipwire's attester) ✓ * **Result:** Service accepts the request as authorized by a real human ## For End Users: Authorizing Your Agent If you're looking to authorize an AI agent to act on your behalf, follow the complete step-by-step guide: {% content-ref url="" %} {% endcontent-ref %} That guide walks you through: 1. Getting your IsAHuman attestation via Zipwire Attest 2. Creating your IsDelegate attestation on EAS 3. What your agent can do once authorized ## Setting Up IsDelegate for Your Agent ### Prerequisites * A **human-attested wallet** (get one via [Zipwire Attest](https://zipwire.io/attest)) * Your **agent's wallet address** * Access to [EAS on Base](https://base.easscan.org) or [Base Sepolia](https://base-sepolia.easscan.org) ### Steps 1. **Navigate to the IsDelegate Schema** * Click [this link to EAS Base IsDelegate schema](https://base.easscan.org/schema/view/0xc4f37c5cb76ba597c66323e399a435e4c7d46ea741588945eacae69ec2d81b97) (mainnet) * Or go to [base-sepolia.easscan.org](https://base-sepolia.easscan.org) for testnet and search for IsDelegate 2. **Create Attestation** * You'll be on the IsDelegate schema page * Click "Create Attestation" 3. **Fill in Details** * **Recipient Address** = your agent's wallet * **Ref UID** = your IsAHuman attestation UID (find it in your Zipwire attestations) * Any additional fields the schema requires 4. **Sign & Submit** * Connect your human-attested wallet * Review the transaction * Sign and submit to the blockchain 5. **Wait for Confirmation** * The attestation will appear on-chain within a few blocks * Your agent is now authorized! ## Verifying IsDelegate in Your Backend ### Quick Check: Simple REST API For a quick check without integrating a library: ```bash GET https://zipwire.io/api/v1/is-delegate/{walletAddress} ``` **Note:** This requires trusting Zipwire's validation. For cryptographic verification, use the ProofPack library below. {% content-ref url="/pages/VaHzry5Re9S3JdXzQ1iF" %} [IsDelegate REST API](/fundamentals/security/attestations/is-delegate-rest-api) {% endcontent-ref %} ### Cryptographic Verification To verify in code that a wallet is delegated from a human (wallet-only check), or to validate a full ProofPack JWS with claims, use the ProofPack library. The main guide and all verification examples live in one place: {% content-ref url="/pages/yTRncn59sC3kqKG8cFaH" %} [ProofPack & Agent Delegation](/tools-and-integrations/proofpack-agent-delegation) {% endcontent-ref %} For copy-paste code (Path 1, Path 2, Express, ASP.NET Core, setup): [ProofPack Examples](/tools-and-integrations/proofpack-agent-delegation/proofpack-examples). ## Revocation & Updates ### Revoking an Agent's Authorization If an agent is compromised or no longer needed: 1. Return to [EAS](https://base.easscan.org) 2. Find the IsDelegate attestation you created 3. Click "Revoke" and sign the transaction 4. The agent is immediately no longer authorized Any backend verifying the delegation chain will reject requests from that wallet. ### Updating Authorization You can't edit an attestation, but you can: * Revoke the old IsDelegate * Create a new IsDelegate with updated parameters * This creates a new, valid chain while the old one becomes invalid ## Privacy Considerations ### What's Stored On-Chain * The attestation that wallet A authorizes wallet B * A hash of the human's identity data (Merkle root) * Not: full name, address, ID number, or any sensitive data ### What the Agent Never Sees * The human's full identity data * Other claims the human might have attested to * Only the specific claims needed for each request ### What Services Never See * The human's full identity (only verified claims) * Which agent is involved (if using wallet-only verification) * A central log of all requests (each verification is independent) ## The Bigger Picture IsDelegate is part of a larger ecosystem: * **Zipwire Attest** = Human attestation (proof of personhood) * **IsDelegate** = Agent authorization (proof of delegation) * **ProofPack** = Selective disclosure (proof of specific claims) * **EAS on Base** = Decentralized storage (verification anchors) Together, they enable **agent economy infrastructure** where: * Humans authorize agents * Agents can act autonomously * Services can verify agent authorization * Privacy is preserved throughout *** ## Related Documentation * [How ProofPack Works: Agent-Bot-Human Problem](/tools-and-integrations/proofpack-agent-delegation) * [Wallet Connections](/fundamentals/security/wallet-connections) * [Passkeys](/fundamentals/security/passkeys) * [ProofPack on GitHub](https://github.com/zipwireapp/ProofPack) * [EAS Documentation](https://docs.attest.sh/) *** **Need help?** Check the [ProofPack GitHub](https://github.com/zipwireapp/ProofPack) or reach out to Zipwire support. # IsDelegate REST API Simple REST API for checking if a wallet is authorized by a human A simple public API for checking if a wallet has valid IsDelegate attestations. ## When to Use Use this API for: * Quick authorization checks with minimal code * Simple bot detection * Verifying agent status without cryptographic validation **Important:** This API requires trusting Zipwire's validation. For maximum security and cryptographic verification, use the [ProofPack library](/tools-and-integrations/proofpack-agent-delegation) instead. ## Endpoint ``` GET https://zipwire.io/api/v1/is-delegate/{walletAddress} ``` ## Request | Parameter | Type | Description | | --------------- | ------ | ------------------------------------- | | `walletAddress` | string | Ethereum wallet address (0x-prefixed) | ## Response (Success) ```json { "success": true, "message": "IsDelegate attestation verified successfully", "walletAddress": "0x775d3B494d98f123BecA7b186D7F472026EdCeA2", "attestations": [ { "attestationUid": "0x7e08febe71e51acbdcb1d2c6175fb36958594074bed0f1e85b12adc6274eb8b2", "attestationExplorerUrl": "https://base.easscan.org/attestation/0x7e08febe71e51acbdcb1d2c6175fb36958594074bed0f1e85b12adc6274eb8b2", "valid": true, "pointsToHuman": true } ] } ``` ## Response (No Attestations) ```json { "success": false, "message": "No delegation attestations found for wallet", "code": "NoAttestationsFound", "walletAddress": null, "attestations": null } ``` ## Example Usage **JavaScript:** ```javascript const response = await fetch('https://zipwire.io/api/v1/is-delegate/0x775d3B494d98f123BecA7b186D7F472026EdCeA2'); const result = await response.json(); if (result.success) { console.log('Agent is authorized by a human'); } else { console.log('Agent is not authorized'); } ``` **cURL:** ```bash curl https://zipwire.io/api/v1/is-delegate/0x775d3B494d98f123BecA7b186D7F472026EdCeA2 ``` ## Notes * No authentication required (public endpoint) * Always returns HTTP 200 OK * Validation includes revocation and expiration checks * Walks the full delegation chain back to Zipwire's trusted root ## For Maximum Security For cryptographic verification that doesn't require trusting Zipwire's API, use the [ProofPack library](/tools-and-integrations/proofpack-agent-delegation) instead. ProofPack allows you to verify attestations independently on-chain. *** **Related:** * [ProofPack Developer Guide](/tools-and-integrations/proofpack-agent-delegation) * [IsDelegate Attestations](/fundamentals/security/attestations/isdelegate-agent-delegation) # The "IsAHuman" Attestation: Purpose and Limitations
## Overview The "IsAHuman" attestation is a simple verification tool that helps distinguish between human users and bots in the Ethereum ecosystem. While it provides basic protection against automated systems, it's important to understand both its benefits and limitations. ## How It Works #### The Process 1. Wallet Connection: A user connects their Ethereum wallet to Zipwire 2. Verification: The user completes a Yoti ID check to verify their identity and liveness 3. Issuance: Upon successful verification, Zipwire offers the option to claim an "IsAHuman" attestation to the user's wallet 4. Recording: The attestation is recorded on the Base blockchain, viewable via EAS Scan 5. Other wallet-connected apps can see this attestation and that it was made by trusted issuer Zipwire #### Privacy Features * The attestation is issued directly from Zipwire's Ethereum account to your wallet * No personal data is stored on the blockchain * No direct link is created between you and your employer or other entities * AI agents cannot access your personal information ## How to Get IsAHuman Attestations ### Self-Service Option {% content-ref url="/pages/kzmdzG6x7y91vzCPFJMX" %} [Your Digital Identity on the Blockchain](/zipwire-attest/zipwire-attest) {% endcontent-ref %} You can obtain IsAHuman attestations through our self-service platform, Zipwire Attest: * **Independent registration** - No business account required * **Direct wallet connection** - Connect your Ethereum wallet and get attested * **Government-approved verification** - Same Yoti ID checks used by banks * **Immediate attestation** - Claim your attestation right after verification ### Business Integration Option IsAHuman attestations can also be obtained through Zipwire Collect when businesses include ID checks in their document collections: * **Free attestations** - Users can claim attestations for free (business pays for ID check) * **Same verification process** - Uses the same Yoti ID verification * **Wallet connection required** - Users must connect their wallet to the collection {% hint style="info" %} **Choose Your Path** For individual users wanting to build their digital identity, use **Zipwire Attest**. For users completing business document collections that include ID checks, use **Zipwire Collect** and claim free attestations. {% endhint %} ## Use Cases #### Combatting Bots * Filter out automated systems from dApps * Protect social platforms from bot manipulation * Ensure genuine human interaction in decentralized systems #### Trust Building * Add a basic layer of trust for platforms * Enable quick verification of user authenticity * Provide a foundation for more complex trust systems ## Limitations #### Security Concerns 1. No Identity Linkage: The boolean value (true) doesn't tie to specific identity details, i.e. no individual living person 2. Limited Proof Mechanism: Unlike attestations with Merkle root hashes, it offers no way to verify specific attributes 3. Transfer Vulnerability: If a wallet is sold or stolen, the attestation remains, potentially misleading others ## Best Practices #### For Users * Don't rely solely on IsAHuman for critical verifications * Consider combining it with other security measures * Be aware of its limitations when using it for trust #### For Platforms * Use IsAHuman as a first layer of verification * Implement additional checks for sensitive operations * Consider more robust attestations for critical functions ## Comparison to Robust Attestations Contrast "IsAHuman" with an attestation of a passport: * **Passport Attestation**: Includes a Merkle root hash of document details (e.g., name, passport number). The holder can provide a Merkle proof to verify specific data without revealing everything, ensuring privacy and trust. * **Stronger Verification**: Such attestations link to verifiable identity data, making them harder to misuse. ## Why It Matters The "IsAHuman" attestation is a lightweight tool for initial trust but shouldn't be relied upon alone. Platforms and users must combine it with other checks, like transaction history or additional attestations, to ensure a wallet's legitimacy. ## Related Resources * [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs) * [Verifying Attested Wallets](/fundamentals/security/wallet-verification-guide/verifying-attested-wallets) * [EAS Explorer on Base](https://base.easscan.org/) # The "IsThirteen" Attestation: Purpose and Limitations ## Overview The "IsThirteen" attestation is a statement of fact that confirms a wallet holder is at least 13 years old. This attestation is useful for platforms and services that require age verification for COPPA compliance and general age-gating. ## How It Works The process follows the standard attestation workflow: 1. **Wallet Connection**: Connect your Ethereum wallet to Zipwire 2. **Age Verification**: Complete a Yoti ID check that verifies your date of birth 3. **Age Calculation**: Zipwire calculates your age from the verified date of birth 4. **Attestation Issuance**: If you're 13 or older, claim the "IsThirteen" attestation 5. **Blockchain Recording**: The attestation is recorded on the Base blockchain {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} ## Privacy Features * The attestation only confirms the age threshold (13+) without revealing your exact date of birth * No personal data is stored on the blockchain * The attestation can be verified without exposing additional personal information ## How to Get IsThirteen Attestations {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} You can obtain IsThirteen attestations through: * **Self-service**: Use [Zipwire Attest](/zipwire-attest/zipwire-attest) for independent registration * **Business integration**: Use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/blob/main/zipwire-collect/README.md) when businesses include ID checks ## Use Cases * **COPPA compliance** - Verify users are 13+ for data collection * **Social media platforms** - Age-gate access to social networking features * **Educational services** - Ensure students meet minimum age requirements * **Gaming platforms** - Verify age for age-appropriate content ## Limitations * **Age Threshold Only**: Confirms you're 13+, not your exact age * **Transfer Vulnerability**: If a wallet is sold or stolen, the attestation remains * **Age Revealing**: Unlike some attestations, this does reveal that you're at least 13 * **Permanent Record**: Once issued, the attestation is permanent on the blockchain ## Best Practices {% content-ref url="/pages/PZjzFvpzqEOo6tndL4Oz" %} [Attestations & Privacy: Timing Your Claims & Data Deletion](/fundamentals/security/attestations-privacy-timing-data-deletion) {% endcontent-ref %} * **Consider timing**: Space out age attestation claims to avoid linking wallet addresses * **Understand permanence**: Age attestations are permanent once issued * **Use appropriately**: Only require age attestations when necessary for your service ## Comparison to Other Attestations * **IsAHuman**: Confirms the wallet belongs to a real person (no age information) * **IsThirteen**: Confirms the user is at least 13 years old * **Private Data Attestations**: Allow selective disclosure of specific age information {% content-ref url="/pages/uKh9zVF06YZtly50dFyc" %} [The "IsAHuman" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) {% endcontent-ref %} {% content-ref url="/pages/UgJwIIVTljJ5n8pkWDKi" %} [The "Private Data" Attestation: Merkle Roots](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) {% endcontent-ref %} # The "IsFourteen" Attestation: Purpose and Limitations ## Overview The "IsFourteen" attestation is a statement of fact that confirms a wallet holder is at least 14 years old. This attestation is useful for platforms and services that require age verification for specific age-gating requirements. ## How It Works The process follows the standard attestation workflow: 1. **Wallet Connection**: Connect your Ethereum wallet to Zipwire 2. **Age Verification**: Complete a Yoti ID check that verifies your date of birth 3. **Age Calculation**: Zipwire calculates your age from the verified date of birth 4. **Attestation Issuance**: If you're 14 or older, claim the "IsFourteen" attestation 5. **Blockchain Recording**: The attestation is recorded on the Base blockchain {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} ## Privacy Features * The attestation only confirms the age threshold (14+) without revealing your exact date of birth * No personal data is stored on the blockchain * The attestation can be verified without exposing additional personal information ## How to Get IsFourteen Attestations {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} You can obtain IsFourteen attestations through: * **Self-service**: Use [Zipwire Attest](/zipwire-attest/zipwire-attest) for independent registration * **Business integration**: Use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/blob/main/zipwire-collect/README.md) when businesses include ID checks ## Use Cases * **Platform age requirements** - Verify users meet 14+ age thresholds * **Content filtering** - Age-gate access to age-appropriate content * **Service eligibility** - Ensure users meet minimum age requirements * **Compliance verification** - Meet specific age-based regulatory requirements ## Limitations * **Age Threshold Only**: Confirms you're 14+, not your exact age * **Transfer Vulnerability**: If a wallet is sold or stolen, the attestation remains * **Age Revealing**: Unlike some attestations, this does reveal that you're at least 14 * **Permanent Record**: Once issued, the attestation is permanent on the blockchain ## Best Practices {% content-ref url="/pages/PZjzFvpzqEOo6tndL4Oz" %} [Attestations & Privacy: Timing Your Claims & Data Deletion](/fundamentals/security/attestations-privacy-timing-data-deletion) {% endcontent-ref %} * **Consider timing**: Space out age attestation claims to avoid linking wallet addresses * **Understand permanence**: Age attestations are permanent once issued * **Use appropriately**: Only require age attestations when necessary for your service ## Comparison to Other Attestations * **IsAHuman**: Confirms the wallet belongs to a real person (no age information) * **IsFourteen**: Confirms the user is at least 14 years old * **Private Data Attestations**: Allow selective disclosure of specific age information {% content-ref url="/pages/uKh9zVF06YZtly50dFyc" %} [The "IsAHuman" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) {% endcontent-ref %} {% content-ref url="/pages/UgJwIIVTljJ5n8pkWDKi" %} [The "Private Data" Attestation: Merkle Roots](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) {% endcontent-ref %} # The "IsSixteen" Attestation: Purpose and Limitations ## Overview The "IsSixteen" attestation is a statement of fact that confirms a wallet holder is at least 16 years old. This attestation is useful for platforms and services that require age verification for employment, driving, and other age-restricted activities. ## How It Works The process follows the standard attestation workflow: 1. **Wallet Connection**: Connect your Ethereum wallet to Zipwire 2. **Age Verification**: Complete a Yoti ID check that verifies your date of birth 3. **Age Calculation**: Zipwire calculates your age from the verified date of birth 4. **Attestation Issuance**: If you're 16 or older, claim the "IsSixteen" attestation 5. **Blockchain Recording**: The attestation is recorded on the Base blockchain {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} ## Privacy Features * The attestation only confirms the age threshold (16+) without revealing your exact date of birth * No personal data is stored on the blockchain * The attestation can be verified without exposing additional personal information ## How to Get IsSixteen Attestations {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} You can obtain IsSixteen attestations through: * **Self-service**: Use [Zipwire Attest](/zipwire-attest/zipwire-attest) for independent registration * **Business integration**: Use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/blob/main/zipwire-collect/README.md) when businesses include ID checks ## Use Cases * **Employment verification** - Verify workers are 16+ for legal employment * **Driving services** - Age-gate access to driving-related platforms * **Financial services** - Some services require users to be 16+ * **Platform age requirements** - Verify users meet 16+ age thresholds ## Limitations * **Age Threshold Only**: Confirms you're 16+, not your exact age * **Transfer Vulnerability**: If a wallet is sold or stolen, the attestation remains * **Age Revealing**: Unlike some attestations, this does reveal that you're at least 16 * **Permanent Record**: Once issued, the attestation is permanent on the blockchain ## Best Practices {% content-ref url="/pages/PZjzFvpzqEOo6tndL4Oz" %} [Attestations & Privacy: Timing Your Claims & Data Deletion](/fundamentals/security/attestations-privacy-timing-data-deletion) {% endcontent-ref %} * **Consider timing**: Space out age attestation claims to avoid linking wallet addresses * **Understand permanence**: Age attestations are permanent once issued * **Use appropriately**: Only require age attestations when necessary for your service ## Comparison to Other Attestations * **IsAHuman**: Confirms the wallet belongs to a real person (no age information) * **IsSixteen**: Confirms the user is at least 16 years old * **Private Data Attestations**: Allow selective disclosure of specific age information {% content-ref url="/pages/uKh9zVF06YZtly50dFyc" %} [The "IsAHuman" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) {% endcontent-ref %} {% content-ref url="/pages/UgJwIIVTljJ5n8pkWDKi" %} [The "Private Data" Attestation: Merkle Roots](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) {% endcontent-ref %} # The "IsEighteen" Attestation: Purpose and Limitations ## Overview The "IsEighteen" attestation is a statement of fact that confirms a wallet holder is at least 18 years old. This attestation is useful for platforms and services that require age verification for adult services, legal contracts, and other age-restricted activities. ## How It Works The process follows the standard attestation workflow: 1. **Wallet Connection**: Connect your Ethereum wallet to Zipwire 2. **Age Verification**: Complete a Yoti ID check that verifies your date of birth 3. **Age Calculation**: Zipwire calculates your age from the verified date of birth 4. **Attestation Issuance**: If you're 18 or older, claim the "IsEighteen" attestation 5. **Blockchain Recording**: The attestation is recorded on the Base blockchain {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} ## Privacy Features * The attestation only confirms the age threshold (18+) without revealing your exact date of birth * No personal data is stored on the blockchain * The attestation can be verified without exposing additional personal information ## How to Get IsEighteen Attestations {% content-ref url="/pages/TfrUK5pGnJhSthL5TLjm" %} [Attestations](/fundamentals/security/attestations) {% endcontent-ref %} You can obtain IsEighteen attestations through: * **Self-service**: Use [Zipwire Attest](/zipwire-attest/zipwire-attest) for independent registration * **Business integration**: Use [Zipwire Collect](https://github.com/zipwireapp/gbk-tz-docs/blob/main/zipwire-collect/README.md) when businesses include ID checks ## Use Cases * **Adult services** - Verify users are 18+ for age-restricted content * **Legal contracts** - Ensure users can enter into binding agreements * **Financial services** - Many services require users to be 18+ * **Employment verification** - Verify workers are legally adults * **Platform age requirements** - Age-gate access to adult-oriented platforms ## Limitations * **Age Threshold Only**: Confirms you're 18+, not your exact age * **Transfer Vulnerability**: If a wallet is sold or stolen, the attestation remains * **Age Revealing**: Unlike some attestations, this does reveal that you're at least 18 * **Permanent Record**: Once issued, the attestation is permanent on the blockchain ## Best Practices {% content-ref url="/pages/PZjzFvpzqEOo6tndL4Oz" %} [Attestations & Privacy: Timing Your Claims & Data Deletion](/fundamentals/security/attestations-privacy-timing-data-deletion) {% endcontent-ref %} * **Consider timing**: Space out age attestation claims to avoid linking wallet addresses * **Understand permanence**: Age attestations are permanent once issued * **Use appropriately**: Only require age attestations when necessary for your service ## Comparison to Other Attestations * **IsAHuman**: Confirms the wallet belongs to a real person (no age information) * **IsEighteen**: Confirms the user is at least 18 years old * **Private Data Attestations**: Allow selective disclosure of specific age information {% content-ref url="/pages/uKh9zVF06YZtly50dFyc" %} [The "IsAHuman" Attestation: Purpose and Limitations](/fundamentals/security/attestations/the-isahuman-attestation-purpose-and-limitations) {% endcontent-ref %} {% content-ref url="/pages/UgJwIIVTljJ5n8pkWDKi" %} [The "Private Data" Attestation: Merkle Roots](/fundamentals/security/attestations/the-private-data-attestation-merkle-roots) {% endcontent-ref %} --- [Next Page](/llms-full.txt/1)