I think we'd need to know
much more about your specific application scenario to give you more focused advice here. Whether "threading" is required, and used (the issue discussed by SAK above), for example.
"Static classes" can be used as "libraries" of function calls that are used across all classes: several .NET objects themselves have exactly this structure and purpose by design: consider "String," for example.
Whether or not to use a static class, or a singleton class, can depend on the nature of the relatively changing, or fixed, data that needs to be communicated across selected classes, shared among all classes, or exposed only by some special means (such as an interface).
Complicating the variety of choices you have here is the fact that static members (fields, methods, properties, etc.) can be implemented within Classes that are dynamically instantiated via 'new.
imho, that is a technique of choice (via using a static Property) in exposing one object, or datum, from a dynamically instantiated Class to outside "consumers" of said object, or datum. But note, there are those who really don't like this approach and have fervent beliefs that this should be done only via Interfaces !
Those ... static whatevers defined inside a dynamically instantiated class ... will be "visible/accessible" to any other Class by specifying the full "design-time path" to the static entity ...
and not visible/accessible to any instance of the Class you have created using 'new: for example:
SomeOtherNamespace.SomeClassname.SpecificStaticWhatEverName
You could have created many instances of 'SomeClassName using 'new, and none of them will "expose" the internal static 'SpecificStaticWhatEverName.