The future of digital agreements: Why we built Filosign
When you sign with a traditional e-signature platform, you trust two parties: the counterparty and the vendor. The vendor stores your documents, hosts your audit trail, and controls whether you can export verifiable proof years later.
That is platform risk, and it shows up in ways legal teams actually worry about:
- Data exposure: Centralized document stores are high-value breach targets.
- Vendor lock-in: Leaving often means losing verification context, not just UI.
- Fragile proof: If the vendor's database disappears, your "signed" status may become hard to defend.
- Privacy by policy, not math: The platform can technically read everything you upload.
We built Filosign to shrink that trust surface: your documents stay encrypted, your signing keys stay client-side, and your proof is anchored on-chain, while day-to-day UX still feels like a modern web app.
What Filosign does differently
Filosign is not "blockchain e-sign" as a gimmick. It is a deliberate split between what must be private, what must be permanent, and what should stay optional.
| Traditional e-sign | Filosign | |
|---|---|---|
| Document storage | Vendor-controlled cloud | Encrypted on private storage; archived to Filecoin |
| Proof of signing | Vendor database + PDF certificate | FSEnvelopeRegistry on Base + exportable compliance bundle |
| Privacy | Vendor can read uploads | End-to-end encryption in the browser |
| Cryptography | Platform-managed keys | Wallet-bound client keys (Kyber + Dilithium) |
| Authentication | Email + password | Wallet identity; social login provisions an embedded wallet |
| Payments | Separate invoicing / escrow products | Attached FSPaymentValidator payout rules, non-custodial |
You get familiar flows (upload, place fields, collect signatures) backed by evidence that does not require Filosign to stay online forever.
On-chain vs off-chain (on purpose)
Our v1 contracts are intentionally small: FSEnvelopeRegistry and FSPaymentValidator, deployed on Base. No upgrade proxies. Identity, key material, and sharing approvals live off-chain in Postgres and your browser.
| Lives on-chain | Lives off-chain |
|---|---|
| File registration commitments (document ID hash, placement hash, participant commitments) | Encrypted document bytes |
| Signature attestations per signer | Kyber/Dilithium key seeds and wraps |
| Attached payout rules and payout execution | Contact graph, org settings, UX state |
The chain stores commitments and attestations, not your PDF. That is how you get permanent proof without publishing sensitive content.
How it feels to use
- Sign in with a wallet or social account (we create an embedded wallet when needed).
- Encrypt and send a document; recipients decrypt only with keys shared to their wallet.
- Collect signatures on placed fields; each completion is validated and relayed to
FSEnvelopeRegistry. - Export proof as a compliance bundle or proof packet PDF whenever you need an audit trail.
- Attach payouts so signing conditions can trigger a direct transfer. No custodial escrow.
We cover gas for relayed writes during beta so users are not forced to manage ETH just to sign a document.
Optional programmable payout
Because settlement runs through FSPaymentValidator, agreements can connect to real outcomes without Filosign holding funds:
- A freelancer signs a final delivery doc and receives payment in the same ceremony.
- A grantor attaches a rule that pays when a milestone signature is recorded on-chain.
The payer registers the rule and approves funds from their wallet. When conditions are met, payout execution is permissionless. Our server relays it for convenience, but the chain enforces the rule.
Why this matters
Digital agreements should not expire when a SaaS vendor changes pricing, gets acquired, or shuts down. Filosign treats cryptography and chain attestations as the source of truth, with our product as a convenience layer on top, not the other way around.
Your documents stay yours. Your signatures stay provably yours. And anyone can verify that, with math and a public RPC node.