Six kinds of gift: an experience you arrange, an invitation, help, a promise, something tangible, or a sum of money — plus a custom option where you describe it yourself.

Each kind asks for its own details. An invitation asks for a date and a place; a promise asks for its terms. You never see fields that do not apply.

A gift record is created with the status Published, and you get a link. Nothing is emailed on your behalf — you send the link however you like.

You can keep editing the design before publishing, and preview the whole page as the recipient sees it.

You can cancel a gift from My gifts. The link then stops working, and the cancellation is recorded in the gift timeline.

A gift that has been accepted cannot be quietly edited — the recipient has already seen it, so the honest option is to make a new one.

No. The gift page is readable from the link alone, with no sign-up and no wallet.

Accepting is a button on the page. If you restricted the link to a recipient email, only that person should be given the link.

Published — the link exists but has not been opened. Sent — shared with the recipient. Opened — they have looked at it. Accepted or Declined — their answer.

Statuses describe what actually happened. A decline is recorded honestly rather than hidden, so you are not guessing.

You need one to sign in and to pay, but not to look around. Sign-in uses Sign-In with Ethereum (EIP-4361), and the only thing your wallet is ever asked to sign is a message bound to this domain — which cannot move funds.

Nothing in this repository ever asks for a seed phrase or a private key.

You connect, the server issues a single-use nonce, and you sign a message bound to this domain, your address, the nonce and an expiry. The server verifies all of it before creating a session.

Signing in never moves funds and never requires a paid signature. A connected wallet and a signed-in session are two different states.

Creating a gift. Kindred charges one fee per gift — a creation fee plus the network cost of minting the gift's token — and that is the only thing it charges.

It does not collect or forward the gift itself. A money gift states an amount the author promises you, and that amount is never part of the payment: the author pays to create the gift, not to fund it.

Once its creation fee is confirmed. Until then the gift is a draft and its link is not shareable.

The fee is fixed on the server before your wallet is involved, and is the same for every kind of gift — a promise of a weekend away costs exactly what a promise of money costs.

The author, entirely. Kindred records the promise and gives you the link; it does not guarantee fulfilment, cannot enforce it, and has no way to make it happen — it never holds the gift's value and so cannot hand it over.

For a money gift this means the money moves between the two of you, outside Kindred, if and when the author sends it. If someone keeps their promise, that is to their credit, not to ours.

The server creates the payment record, your wallet sends the transfer, and the server then verifies the network, the official token contract, the sender, the recipient, the exact amount, the receipt and finality.

A transaction hash alone is never treated as proof of payment. Until that verification passes, the payment stays unconfirmed.

A confirmed ERC-20 transfer cannot be undone by changing a database row. A refund is a separate operation, and a plain transfer provides no escrow or conditional payout.

Refunds are therefore only contemplated for platform failures — a confirmed fee for a gift that was never published, say. The policy itself is still an open product decision recorded in the specification, not a behaviour that exists today.