If you're playing Splinterlands with more than one or two accounts, you already
know the drill. Log in, claim rewards, collect SPS, stake, check the season
pass, do it again tomorrow. It's not gameplay — it's maintenance. And the more
accounts you run, the more of your day it eats.
ShardWorks automates all of that. We're looking for a handful of early
players to try it, tell us what works, and help us shape what comes next.
What it does
ShardWorks handles the repetitive account maintenance that has nothing to do
with actually playing the game:
- Claim daily rewards across all your accounts
- Collect SPS from regular accounts into a central bank account
- Stake SPS on the bank
- Swap SPS to DEC when you need it
- Distribute DEC to accounts that need it for season passes — smartly,
prioritising accounts that need it most - Buy season passes automatically when they run out
- Claim staking rewards and frontier draws
- Harvest land and add liquidity to pools
You set it up once through a browser UI. The system runs the jobs on schedule
while you focus on the actual game.
How much access does it need? You decide.
This is the question everyone rightly asks first, and the honest answer is:
it depends on which features you want to use.
ShardWorks respects Hive's key hierarchy. Different operations need different
keys, and we enforce that boundary strictly.
Posting key is enough for:
- Claiming daily rewards
- Buying season passes
- Claiming frontier draws
- Staking SPS
- Delegating SPS
- Land harvesting and liquidity
- VOUCHER pool management
Active key is only needed if you want:
- SPS transfers from accounts to your bank
- SPS → DEC swaps on Hive Engine
- DEC distribution from bank to accounts
- Rental bid placement
- Staking rewards claiming
That means you can run a fully useful setup — claims, season passes, staking,
land — with nothing but posting keys. The active key unlocks the token-flow
features. You choose how far you go. Nothing in the system forces you to add an
active key, and the UI makes the distinction visible before you submit anything.
How keys are protected
We understand that handing private keys to any system is a real trust decision.
Here is exactly what we do with them.
Keys never leave your server in plaintext. When you submit a key through the
browser, it travels over HTTPS to the API, is validated, immediately encrypted,
and stored. The plaintext is gone from memory at the end of that request. It is
never returned to the browser — not on key list pages, not anywhere.
Encryption uses HashiCorp Vault with envelope encryption. Each key is
encrypted with a unique data key. That data key is itself wrapped by Vault's
Transit engine. The database only ever stores encrypted payloads. Even someone
with a full database backup cannot read a stored private key without also having
access to a running, unsealed Vault instance.
Active keys require explicit confirmation. The API requires a separate
confirmation flag when submitting an active key. You cannot accidentally store
one while intending to store a posting key.
The browser is deliberately kept out of the secret loop. The UI collects the
key once and submits it. It receives back only a status (stored / revoked). Key
material never lives in browser storage, cookies, or local state.
Login uses Hive Keychain. You never type a password into ShardWorks. Login
is a Keychain-signed challenge — the same pattern a hardware wallet would use.
No password, no master credential, no account takeover from a leaked session.
The worker decrypts only what it needs, only when it needs it. When a
scheduled job runs, the worker fetches and decrypts the specific key for that
specific operation at that moment. It does not hold decrypted keys in a cache
between runs.
You can audit the code
We are asking for your trust, and we think that trust should be earnable rather
than assumed. If you want to read the code before deciding, we welcome that.
Early adopters who reach out will be given access to review the source directly.
You can verify how keys are stored, how the worker handles them, and how the
Vault integration works — end to end.
This offer is genuine. If something in the code makes you uncomfortable, we want
to hear it.
Who this is for right now
ShardWorks is early. It works, and we run it ourselves, but it is not yet a
polished product with a support desk. We are looking for players who:
- Run multiple Splinterlands accounts and feel the maintenance burden
- Are comfortable with self-hosted tools (a Linux server, Python, basic
configuration) - Are willing to share feedback when something is confusing or broken
- Understand this is a work in progress
If that sounds like you, get in touch. Early users get direct access to the
developer, input on what gets built next, and the knowledge that the tooling
they are shaping will be used by real players.
ShardWorks — less time on maintenance, more time on the game.