# Safecafe: an open-source, IPFS-hosted SAFE staking interface for the community
Hi Safe community,
I would like to share a project I have been building for Safenet Beta staking:
**Safecafe**
- Live app: https://safe-staking.eth.limo/
- GitHub: GitHub - ioplustech/safecafe: standalone non-custodial interface for Safenet staking · GitHub
- Latest IPFS release: `ipfs://bafybeiakbd3huvun24mlh7saqbyc74bq3s4ogjoeezxoitpwwxhdsdn4xa`
## Background
SEP-55 introduced Safenet Beta as a concrete SAFE token utility initiative, with SAFE staking, validator delegation, and reward distribution as core parts of the design. The proposal also highlighted that relying on a single staking interface creates centralisation risk, operational dependency, and a single point of failure.
The later Safenet Beta Staking UI RFP made this even more explicit. Track A asked for permissionless, non-custodial interfaces, open-source frontend code, direct interaction with Safenet staking contracts, wallet support, staking, unstaking, and reward claiming. It also listed IPFS / ENS hosting, better UX, validator insights, and simulations as useful additions.
I applied to that RFP, but my proposal was not selected. That is okay. I had already done a meaningful amount of work, and I still believe the output can be useful to SAFE holders and to the broader Safe ecosystem.
So I am publishing Safecafe openly, for free, with no grant attached, as a community contribution.
## What Safecafe is
Safecafe is a standalone, non-custodial interface for Safenet Beta staking.
It is designed around a simple principle:
> SAFE holders should have more than one way to inspect staking state, claim rewards, stake, unstake, and verify the frontend they are using.
Current focus areas include:
- SAFE balance and staking overview
- Validator discovery and validator-level position display
- Stake / unstake / withdrawal claim / reward claim flows
- Reward proof loading and Merkle root checks
- Transaction simulation and clearer pre-signing review
- Safe multisig-aware proposal, confirmation, and execution flows
- CLI tooling for users who prefer scripts or terminal workflows
- A Staking Agent for managing SAFE staking through natural-language instructions
- User-configurable RPC, Safe API, and LLM API settings
- Open-source code
- IPFS release publishing
- ENS/IPFS access through `safe-staking.eth.limo`
This is not an official Safe Foundation product. It is an independent community project.
## Staking Agent
One feature I especially want to highlight is the **Staking Agent**.
Instead of forcing users to manually translate every staking intent into form fields, validator selections, and transaction steps, the Agent lets users describe what they want in natural language.
For example, a user can ask about their current staking position, claim rewards, restake rewards, stake SAFE to a validator, prepare an unstake flow, or reason through validator moves. The app still keeps the user in control: every on-chain action is prepared for review and must be explicitly confirmed in the user’s wallet.
The current Agent focuses on SAFE staking, but the same pattern could later extend to other Safe workflows. A natural-language interface can make complex Safe operations easier to understand, while still preserving non-custodial execution and wallet confirmation.
Because Safecafe is currently a free and public community service, the live Agent endpoint has some abuse-prevention limits:
- Each eligible user can call the Agent up to 100 times per day.
- Live Agent access requires the connected account to hold SAFE or have an existing SAFE staking position.
Users who prefer not to rely on the public Agent service can also configure their own compatible LLM API from the app side.
## Why IPFS and ENS?
One of the goals of the RFP was interface resilience. For a staking frontend, I think this matters a lot.
Safecafe publishes immutable IPFS builds and keeps release records so users can compare:
- the GitHub source
- the build / release manifest
- the IPFS CID
- the ENS contenthash
- the deployed frontend
The goal is not only to provide another URL. The goal is to make the frontend more inspectable and harder to silently mutate.
The ENS/IPFS route is a static, verifiable frontend. Optional hosted APIs are used for convenience features such as live reads, Safe Transaction Service sync, and the public Staking Agent.
Current public route:
GitHub repository:
## Why I am sharing it now
Safenet Beta rewards are already being distributed, and reward posts point users to compatible UIs or direct contract interaction for claiming. In practice, that means users benefit from having multiple independent access paths.
Even if Safecafe is not part of the funded RFP cohort, I think it can still serve three useful purposes:
1. **A fallback interface**
If one frontend is unavailable or degraded, users should have other ways to read their staking state and interact with the contracts.
2. **A transparent implementation for review**
The code is public, the release process is documented, and IPFS builds can be verified.
3. **A place to experiment with UX**
Validator insights, transaction simulation, CLI workflows, and agent-assisted staking are areas where I think SAFE staking can become easier and safer for more users.
## Current status
Safecafe is actively being hardened. I would appreciate feedback from SAFE holders, delegates, validators, and builders, especially around:
- transaction review clarity
- Safe multisig flows
- reward claiming UX
- validator information display
- IPFS / ENS verification
- CLI workflows
- security assumptions
Please treat it as an independent community interface and review transactions carefully before signing.
## Closing
I want to thank the Safe community, SEF, and the teams working on Safenet Beta. The RFP process made the need for multiple staking access points very clear, and even though Safecafe was not selected for funding, I still want the work to be available to the ecosystem.
If this helps even a small number of SAFE holders access staking more reliably or understand the staking flow better, it is worth publishing.
Feedback, issues, reviews, and contributions are welcome.
## References
- SEP-55: [SEP 55] [Phase 2] Fund Safenet Beta for SAFE Token Utility
- Safenet Beta Staking UI RFP: [RFP] Safenet Beta Staking UI - Call for Operators
- Safenet Beta rewards distribution, Period 1: Safenet Beta Rewards Distribution - Period 1