# Sign and respond > How invited parties, declarants, co-notarizers, and witnesses review and respond to a record. Audiences: users, agents Kind: guide Updated: 2026-07-12 An invitation asks you to review the current version of an Agreebase record. Agreebase supports full agreement review and amendment ("red-lining"), but you cannot accidentally sign a non-current version as safeguards prevent that. ## Open and identify yourself Use the invitation link in the email or the record's confirmation route. This email is like a password, which allows you to review and either accept/reject or propose changes to a proposed agreement, so do not share it with anyone. ## Review the exact text Read the complete current agreement text, participants, witness role, expiry, and publication settings. Pay particular attention to whether full text or verified party details will be written to the public blockchain - Agreebase's web interface will ask you to acknowledge when any blockchain record would include either the full agreement text and/or the parties' confirmed details in plain text. It's not possible to accidentally consent to publication without confirming this via the acknowledgments. If the text or settings are not acceptable, do not finalize the signature and either decline it or contact the initiator with your concerns. ## Choose and complete signature methods The record requires one, two, or three distinct methods, set by the initiator when the record was created. Email OTP is always one of them: Agreebase sends a short-lived code to your signing email address, and entering it proves you control that address. See [Signing methods](/docs/concepts/signing-methods) for the full list and what each one captures. Depending on availability, you may also be offered a public proof-post method: GitHub gist, X post, or Reddit post. These work the same way in each case. Agreebase generates a block of proof text tied to this exact record and version, and asks you to publish it somewhere only you control; a gist under your GitHub account, a post from your X account, a profile post on Reddit. You paste the URL back in once it's live. Agreebase then fetches that URL and checks that the page actually contains the generated text (Reddit strips formatting from post bodies, so for Reddit it checks the post title instead, which is generated to carry the same proof in a shorter form). That's the whole mechanism: nobody but the account holder can make GitHub, X, or Reddit show Agreebase's generated text under their name, so a successful check is evidence you controlled that account at that moment. Because the proof has to be public to be checked, it's also visible to anyone who can view that platform; see [Privacy and publication](/docs/concepts/privacy#public-proof-methods) before choosing one. Telegram works similarly but privately: opening a link from Agreebase in the Agreebase Telegram bot and completing the challenge there proves control of that chat, without anything being posted publicly. A passkey signs a cryptographic challenge through your browser's WebAuthn prompt, which has to happen in the Agreebase browser origin itself; an agent working on your behalf cannot complete this step for you. Whichever methods you use, each one is tied to the current record version. If the text changes under you (see counter-proposals below), a method you already completed no longer counts and you'll need to redo it against the new version. When verified party publication is enabled, Agreebase separately asks you to acknowledge that your entered name and verified signing email may be included in the public blockchain record. That acknowledgement is distinct from completing a signature method; you can complete every method and still decline that specific disclosure by not finalizing until you're comfortable with it. ## Finalize After the required signing methods are verified, review the final text again and take the explicit sign/finalize action. Depending on the lifecycle, finalization may invite the next participant, invite witnesses, or seal the record. Do not treat a typed name, an authentication OTP, or an agent's statement as a signature. The record is signed only when Agreebase reports a finalized signature execution for the current version. ## Other responses If you do not accept the current text, you may be able to: - Submit a counter-proposal. You can do this by describing the changes you'd like to see and then reviewing the difference ("diff") between the proposed version and your proposed version, or by directly editing the text to demonstrate your proposed changes. - Decline participation with an optional reason. Only the initiator of the agreement will see your provided reason. Only one counter-proposal can be under review at a time, so if you submit one while the record is pending, the other parties see the record pause in `counter_under_review` until the initiator responds. The initiator can accept it outright, reject it, or accept part of it with a resolved body of their own. If the resulting body is actually different from what was sealed before, every signature already completed for the earlier text, including the initiator's own, is cleared, the version number goes up, and everyone is invited to sign the new text from scratch. If the initiator rejects the proposal, or accepts it without any real change to the body, nothing is reset and the record simply returns to normal pending signing. Witnesses cannot submit counter-proposals. A witness can sign the attestation, or decline to witness the current version. ## If a party declines or a witness can't complete A decline doesn't automatically kill the record. If the initiator declines, that's treated as rescinding the whole record rather than an ordinary decline. If a non-initiator signing party declines and there's no other active recipient left to sign, the record moves to `declined` and cannot continue. If other active participants remain, the initiator can choose to remove the declining party (if they haven't signed yet) and proceed without them, subject to the record's own rules about who must sign. A declined or unresponsive witness is more flexible: the initiator can waive that witness and complete the record without their attestation, or replace them with a different witness invitation entirely. Waiving records, in the final metadata, that the named witness did not sign; it doesn't pretend they did. See [Manage a record](/docs/users/manage-record) for how these actions look from the initiator's side, and [Lifecycle and versions](/docs/concepts/lifecycle-and-versions) for the full state model.