Sia Storage SDK (Dart) v0.4.0 gives applications more control over access and storage workflows. Create read-only sharing keys for selected objects, let recipients connect through Sia.sharedSdk without an account or approval flow, and revoke keys or remove individual objects later. Programs can also connect noninteractively with Builder.connectPreAuthorized, upload native files through Sdk.uploadPath or PackedUpload.addPath, overwrite ranges with UploadOptions.startOffset, and shorten objects with PinnedObject.truncate. Path uploads throw on web, and modified or truncated objects must be re-pinned. Use Sdk.pruneSlabs(before:) to set a cutoff, or pass before: null to let the indexer protect recently pinned slabs.

Transfers can finish with greater WebTransport parallelism and less repeated connection setup. Active RPCs are no longer stopped by fixed deadlines while they continue making progress, and slabs rejected as too old are reuploaded automatically. Recovery flows can check Builder.matchesExistingAppKey and Builder.reconnecting; registration with a different recovery phrase now creates a new app key instead of failing.

Existing integrations require migration. Add the required version field when constructing Slab or containing SealedObject values, and remove uses of Sdk.slab and PinnedSlab. Replace AppKey.export_() with AppKey.save(). For share URLs, replace Sdk.shareObject with Sdk.objectShareUrl and Sdk.sharedObject with Sdk.objectFromShareUrl; Sdk.shareObject now attaches an object to a sharing key.

Read the developer documentation at https://devs.sia.storage.

Sia Storage SDK (JS) v0.1.5 keeps long Firefox streams running to completion instead of silently cutting off after about 30 seconds. Downloads streamed through the service worker now complete rather than being saved as truncated files; in the reported case, a 4 GB download previously produced only about 120 MB.

Firefox video streams can also continue reading beyond 30 seconds without requiring another request. While serving downloads or video, the page messages the service worker every 10 seconds to keep it active. Existing integrations require no migration.

Explore Sia Storage JavaScript SDK at https://devs.sia.storage.

Sia coin s3d cost 50 gb free and 500gb like costs 7.99 and 5tb costs lie 14.99 and 10 tb cost 19.99 is there any way to lower the cost . The onchain dos it cost less. I am building a siacoin based file cloud storage app.

https://drive.huntbits.com

https://drive.huntbits.com/s/EmOQR_nGTY4TRnW297UiIA

Saicoin storage sample.

Sia Storage SDK (JS) v0.1.4 gives applications more direct control over storage and playback behavior. Call StreamedFile.warm() when playback becomes likely to move several seconds of host connection setup ahead of Play. Use sharedSdk.objectSummaries(offset, limit) to page through shared objects without loading their slabs, then call sharedSdk.object(id) when you need a downloadable object. You can also pass before to sdk.pruneSlabs(before?) to restrict pruning by age; existing calls without it keep the indexer-selected cutoff.

Shared streams now reuse the file record already fetched by the page, removing a repeated indexer lookup that normally added about 0.2 seconds before the first byte and reached up to 7 seconds under load. Closing a stream manager also releases the copied app key created by Sdk.openStreams instead of retaining it until the page unloads.

Update integrations that call sdk.slab(id) or reference PinnedSlab: both APIs have been removed, with no replacement lookup. Leaving these references in TypeScript code can break compilation or declaration generation. Calls to encodedSize with zero data shards now throw a catchable JavaScript error instead of terminating the process.

Explore Sia Storage SDK (JS) at https://devs.sia.storage.

s3d v0.2.1 makes transfer activity, pipeline pressure, and upload progress visible while the service runs. The status command now shows ingress and Sia upload rates, queued work, active uploads, and remaining local buffer capacity, helping operators assess throughput and staging pressure from one view.

S3 clients now work more reliably with bucket locations, percent-encoded copy sources, object key counts, and missing lifecycle configuration errors.

Commands also continue past unreadable configuration locations instead of aborting before finding the intended file. The upgrade restores database validation for global settings and may warn that the indexer URL was backfilled; operators using a custom indexer should re-login if prompted.

Download s3d v0.2.1 from https://sia.tech/software-downloads

In 2018, uploading ~5 TB could take nearly a week and still stall before finishing. Today, the new SDKs can upload 5 TB in just over 8 hours, with consistent throughput and every file completing—all without routing user data through a centralized gateway.

Learn more about what changed and how we got here 🔗 https://sia.tech/blog/the-new-sia-sdks

Browser apps can stream stored objects by URL instead of loading whole files first. In Sia Storage SDK (JS) v0.1.1, openStreams(sdk, credentials) and openStreams(sharedSdk, credentials) return ordinary URLs for object data, so video, audio, fetch, and other URL consumers can read incrementally. In browsers with service workers, those URLs support ranged reads, which lets large media start sooner and seek on demand. For Sdk, pass { indexerUrl, appMeta }; for SharedSdk, pass { indexerUrl, seed }, and the credentials type follows the SDK instance you pass.

Large browser downloads also no longer need to sit entirely in page memory. streams.download(object, { name }) can hand the transfer to the browser's download manager instead of buffering the whole file in the page, which changes big saves from an in-memory page operation into a browser-managed download flow. The same openStreams(...) integration still works where service workers are unavailable, falling back to reading the object in the page rather than forcing a separate browser code path.

Safari-targeting apps can now call detectPrivateRelay() to detect when a visitor is using iCloud Private Relay, which the SDK does not work through. That gives your integration a way to recognize that unsupported network path before or while deciding how to proceed.

Try our quickstart at devs.sia.storage

Hi

I just sent my SC to my Nano X I can see the balance but can't send any out?

I followed the hardfork V2 instructions and added my seed to wallet.siacentral.com Then sent them to my ledger, after installing walletd.

I can see my SC on the ledger. I even removed the ledger and added it again to the wallet and the coins are still there.

When trying to send, first it says "Blind singning is temporarily disabled until ledger supports V2 transactions".

After turning on "Use blind singing" and clicking on "sign" I get an error:

"failed to select siacoin elements: insufficient funds"

The walletd version shows v2.15.2

I'm on Ubuntu 24.04.5 LTS

My Ledger is running V2.7.1

Any help would be really appricated. Thanks.

Sector pruning blocks the database for much less time in hostd v2.11.0. Prune sweeps no longer scan every stored sector to find candidates. Unreferenced sectors are tracked through per-sector contract and temp-storage reference counts, and only writes lock a sector location. On a 100 TiB host, the old prune sweep held the database for about six seconds every five minutes. The upgrade now computes counts for existing sectors and rewrites the sector table, which takes about a minute at that size.

Sector reads and pruning also avoid the overhead of bloated sector rows. The stored sectors table no longer keeps the inline Merkle cache that had been adding 32 KiB of subtree roots to every sector row and slowing sector reads, pruning, and contract root lookups. Cached roots are discarded during upgrade and rebuilt on the next read. This database migration can take a long time on large hosts, so plan maintenance time accordingly. Memory also no longer leaks from cached roots of resolved, renewed, and rejected contracts, which reduces ongoing memory growth on long-running hosts.

More database reads can proceed in parallel again, and hot paths that read before writing now use a writer transaction mode intended to reduce database retries. Idle pruning also uses much less CPU on hosts with nothing to delete by avoiding the previous full-table scan in that case. Sector moves no longer hold the database lock during long copy operations, and the sectorCacheSize setting is now ignored.

Download hostd v2.11.0 from https://sia.tech/software-downloads.

I need to update my wallet due to the v2 fork of over a year ago. My current wallet - SiaUI - no longer appears to download the blockchain.

Can you please confirm that the procedure is as simple as this:

a) Go to https://wallet.siacentral.com/ and "Recover Wallet" and enter my 29 word seed phrase.

b) This will then import all my coins into that web wallet.

c) I can then setup a local wallet (walletd) and have the coins from the web wallet sent to that local wallet (after downloading the blockchain locally).

Is this correct? Many thanks.

I have been hosting a sia node (running hostd) for over a year, and I've noticed four things:

1. hostd.sqlite3 is very large, about 164GB
2. consensus db is large, about 84GB
3. it takes a LONG time to even refresh the web dashboard -- Like over 60 seconds. Refreshing includes a bunch of read activity from the SSD the database these files are installed on.
4. hostd.log was also large, about 30GB.

Are there any good ways to manage these files to make them take up less space or have less of a dire impact on things like starting the node or just updating dashboard stats?

s3d v0.1.4 makes it easier to expose data safely and interoperate with more S3 clients. You can now serve public downloads and listings from selected buckets with bucket policies, and you can accept presigned URLs for time-limited access without handing credentials to the downloader. Public-read policies are limited on purpose: they can grant s3:GetObject, s3:GetObjectVersion, s3:ListBucket, and s3:ListBucketVersions to *, and other policy shapes are rejected.

This release also smooths out client compatibility around bucket and service probes. Clients that send an initial unsigned HEAD / before authenticating can now connect successfully because non-GET requests to the service root return an S3-style 405 with Allow: GET instead of a plain 404. HeadBucket now also works when the caller has s3:ListBucket, matching expected S3 authorization for bucket existence checks.

If you rely on upload throughput or want to limit resource use, review your upload thread setting after upgrading. Upload parallelism is now configurable, and the default drops from 8 threads to 4 unless you set it explicitly.

Download s3d v0.1.4 at https://sia.tech/software-downloads.

Permanently unrecoverable slabs stop consuming repair retries in indexd v0.5.0. If a reconstructed shard does not hash to its pinned root during migration, the slab is now marked unrecoverable with a reason and removed from the repair rotation instead of being retried indefinitely. That root mismatch also no longer aborts the whole migration pass, so the slab's other remaining shards can still finish migrating. To make repair health easier to operate, GET /stats/sectors now includes indexd_num_unrecoverable_slabs and indexd_num_stuck_slabs, with the latter counting slabs that have failed more than one consecutive repair attempt and are still being retried.

Expired temporary uploads are rejected before they become dead data. indexd now rejects sectors whose provided upload time is older than the temporary storage duration, and out-of-range upload times return an error so the slab can be re-uploaded instead of being pinned with data that is already likely expired.

Large contracts now get higher funding targets during refresh and renew. Funding calculations raise the contract growth-rate bounds from 32 GiB to 256 GiB at the low end and from 256 GiB to 1 TiB at the high end. indexd also removes exponential backoff and pauses between productive remote migration passes, so remote migration work is no longer intentionally slowed by that retry logic when there is work to do.

Download indexd v0.5.0 at https://sia.tech/software-downloads.

I am new to Sia hostd and I have Windows 11.

My current version is v2.10.2.

Version v2.10.3 was released.

How can I update hostd?

The instructions say to just restart hostd, but it doesn't update.

Opening large videos no longer crashes the app. In this release, videos stay as thumbnails until you press play instead of spinning up players while you browse, which also keeps memory use down before playback starts. On Android, leaving fullscreen video no longer crashes the app either.

Clearing local files now removes all backed-up local copies, not just files that happened to meet the app's cleanup thresholds. Files that have not uploaded yet are still kept, and removed local copies now show as no longer downloaded right away.

Sign-in now recovers when the saved account no longer exists on the indexer, so it can continue to the recovery phrase flow instead of stopping on an error that reinstalling the app could not clear. And if sign-in or sync gets stuck before the library loads, every pre-library screen now gives you a settings menu where you can clear local data and back out. This release also fixes the Support button on Android so it opens your email app, and the settings screen now shows the installed app version at the top.

If video browsing or sign-in has blocked you before, install v1.14.1 from the App Store or Google Play.

Dear group,

Many months ago, I made a post describing what it was like to run a Sia host from my first 6 months:

My notes from first six months running a Sia host : r/siacoin

(Those notes are still relevant, especially if you're starting out)

Well, I've still been hosting continuously since then, so it's been about 17 months total. I still haven't ever used Sia from the client-side, so this is only my host related experience:

Collateral = ¯_(ツ)_/¯

As the host data grew, I needed to deposit more sia funds into my wallet in order to have enough collateral to back new contracts. I probably deposits around $120 or $150 total from real cash.

The thing is, the sia coin is a generally depreciating asset. Lockup times for contracts can be up to 6 months. By the time you're finally paid, the sia coin is worth less than the beginning of the contract.

So I've nominally "earned" $135 over my 17 months of hosting, per the web dashboard, but my wallet balance is only $130 with another $30 locked up in collateral.

In other words: hosting for that time has been basically a breakeven proposition. Which is silly.

I've responded by reducing my collateral multiplier (from 3x to 2x) and by shortening my contract time from 6 months to 2 months. Both of these things will reduce my host score and may make my host less desirable to clients. (update: I tried dropping collateral multiplier to 1.5x and it seemed to turn my hostscore to zero, so I bumped it back up to 2x to get at least some traffic)

Wild data swings

The universe of hosted data and large clients is small enough to where there can be some really wild swings in the usage of the node, which may hinge on just a few "whale" contracts.

My highest data stored was after about 12 months of hosting and it was 27TB.

3 months later it had dropped to 4TB.

Over 4 months it built up to 19TB. Then it just recently dropped to 14TB.

Also, there was a month or two where someone was using my bandwidth HARD. I had over 1TB per day of egress data happening. (my host is configured to charge for egress, but it's fairly cheap).

Other misc notes

After running the host for a while, the database gets big and it takes a long time to refresh the web dashboard. Last time I did it took 50 full seconds.

I had a hard drive I thought was failing so I used the build in volume control to resize and shrink the drive as small as possible. It took more than one attempt because of hard drive errors, so it shrank a little each time and data was sent to other drives, and then I'd try again. At the end there was a small amount of 33GB which I couldn't move and I had to delete the volume. So that was considered "lost" data.

Pruning large accounts finishes much faster in indexd v0.4.3. For large-account prune workloads, the provided benchmark for 15,000 slabs improved from 24.040726443 s/op to 3.542584632 s/op. That should reduce the chance of prune runs hitting existing client-side time limits on larger accounts. Object event pages also load much faster on large accounts, with the supplied 500-row example dropping from 227.293 ms to 0.428 ms by using a more efficient index scan and avoiding the expensive filter step.

Host management is more flexible through the admin API. You can now add a host manually to the hosts table so it will be scanned even when discovery has not found it yet, which is useful for instant-sync and multi-indexer workflows where hosts may exist out of band. You can also force a host scan on demand instead of waiting for the normal internal scanning path.

Host ranking is also more consistent when RPCs keep timing out at the deadline. Those hosts now get an implied throughput sample instead of being treated like unsampled hosts after failure decay, so chronically stalling hosts are deprioritized more reliably instead of resurfacing as if they were faster options.

Download indexd v0.4.3 from https://sia.tech/software-downloads.

You can manage imports from a dedicated Imports screen. It lists imports most recently active first, so the work that is still moving stays easy to find. Each import now opens to details that can search files, show plain-language failure reasons, let you retry failed files, and let you cancel or remove an import from history. When a photo import is still open but has nothing left to copy, it now reads Watching instead of Importing.

Imports also appear immediately and resume after the app is closed. Picked or shared files show up in the imports list right away, without creating placeholder files in your library first, and the app reads each file only when its turn comes. If the app is killed during an import, it resumes where it left off the next time you open it.

The status sheet now also includes an Uploads view, so you can see the current upload queue with each file's thumbnail, size, added date, and live progress. Imports now tell you why they are waiting, including low space, upload backlog, and retry countdowns.

Long uploads use less battery and generate less heat. On iOS, photo picks now import directly from the photo library without temporary copies, skip photos already imported into the same destination, and show a clearer permission result when a photo is outside a limited access selection.

On Android, photo picks now use the system Photo Picker and start importing without temporary copies, so large selections begin immediately and do not use extra storage before processing starts. The status sheet also adds an Uploads view for queued and active uploads, and upload speed is now shown while files are uploading.

Visit sia.storage to get the app on iOS and Android!

Downloads get first bytes sooner and run about 69% faster on slow or uneven networks in Sia Storage SDK (Go) v0.2.0. Upload and download racing now derives its timeout from observed network throughput instead of a fixed timer, and racing is held back when it would steal capacity from more important work: uploads only race after every shard has an attempt in flight, and downloads only race chunks near the read head. In the 10 GiB benchmark used for this release, download throughput went from 540 Mbps to 911 Mbps, time to first byte improved from 608 ms to 439 ms, and max latency dropped from 2.18 s to 1.54 s.

Uploads also finish much faster for the same data. The upload path now reads whole slabs and moves encryption and erasure coding off the upload read loop into per-slab goroutines. In the provided 256 MB benchmark on Zeus, upload throughput increased from 273 MB/s to 462 MB/s while download throughput stayed roughly flat at 2593 MB/s versus 2569 MB/s. Downloads separately now start at 32 KiB and ramp chunk sizes up to 1 MiB, while each chunk launches 1.5× as many initial reads as needed and uses the first successful responses, so a single slow host is less likely to hold up recovery.

This release also changes integration points you may need to touch. Object data is now encrypted per slab, and Slab has a version byte to support the new encoding; if your code persists or exchanges encoded SealedObject values, you need to handle the new versioned slab format. You can now read an object's key with (*Object).UnsafeDataKey() [32]byte and build one directly with NewUnsafeObject(dataKey [32]byte, ss []slabs.SlabSlice) Object. SlabReader, NewSlabReader, and ReadSlab were removed.

Sia Storage SDK (Rust) v0.11.0 release

Rewrite part of an object without reuploading the whole thing. In Sia Storage SDK (Rust) v0.11.0, UploadOptions now includes start_offset, so you can rewrite an object from a byte offset instead of sending the entire object again. The original object is not replaced, so both versions can be pinned at the same time. This works at slab granularity, so it is most useful when the changed range avoids re-uploading whole slabs; small packed objects benefit less.

Disk-backed uploads also get a simpler path behind the non-default fs feature. Sdk::upload_path and PackedUpload::add_path now open a file and read it to EOF inside Sia Storage SDK (Rust), so callers uploading from disk no longer have to stream every chunk through a caller-managed reader. This feature is unavailable on wasm32. This can reduce FFI overhead substantially when reading large files.

Uploads are also less likely to hang forever when hosts stop making progress. They now fail after bounded retries and a default timeout of 1.5 minutes per shard per attempt, with at most 3 attempts per host per slab. If you use the less-safe-crypto feature, you can now export an object's data key with Object::data_key and reconstruct an object with Object::less_safe_new, taking responsibility for the invariants the normal upload path enforces.

Visit devs.sia.storage to try our quickstart!

We just released sia_reed_solomon, a fast, SIMD-accelerated Reed-Solomon erasure-coding library for Rust. It was built to bring high-performance data encoding and reconstruction to x86, ARM, and even browser-based Sia applications through WebAssembly. Our latest blog explains why we built it, how the SIMD implementation works, and how it performs against other libraries.

Learn more at 🔗 https://sia.tech/blog/reed-solomon-rust

Sia Storage SDK (Rust) 0.10.0 makes transfers adapt to the connection instead of forcing you to guess a fixed concurrency limit. Uploads and downloads now adjust parallelism automatically based on network conditions, which lets fast links use more of the available bandwidth while slower links scale down and finish reliably. The same release also improves host selection, ramps download chunk sizes to reduce round trips on large reads, overprovisions shard downloads to cut slow-host tail latency, and makes racing yield to higher-priority work instead of consuming those slots.

This changes the transfer options API. max_inflight has been removed from upload, download, and language-binding option types. Memory is now controlled directly with UploadOptions::max_buffered_slabs and DownloadOptions::max_buffered_chunks; if you leave them unset, each defaults to roughly 10% of system memory.

For WASM users, large downloads are also more reliable. QUIC streams are now closed explicitly when dropped, so download memory is released promptly instead of waiting on garbage collection.

Visit 🔗 devs.sia.storage to try the updated SDK!